Estou tentando aprender a desenvolver Android e inicialmente estou confuso com as diferentes estruturas de projeto entre Eclipse e Android Studio. Isso torna difícil seguir os tutoriais projetados para o Eclipse. Alguém poderia me dizer por que essas diferenças existem? Eles deveriam existir?

Por exemplo, se eu localizasse o arquivo R.java nos dois IDEs diferentes, os caminhos seriam assim:

Eclipse: app \ gen \ com.example.app \ R.java

Android Studio: app \ build \ source \ r \ debug \ com.example.app \ R.java

Por que esses caminhos são diferentes? Por que meu R.java está localizado em uma pasta de depuração no Android Studio? Isso levou a alguns erros no início e, se alguém tiver alguma ideia dessas diferenças, eu os agradeceria.

O mistério: Estrutura do projeto e sistema de compilação do Android Studio

Não sei se é por causa do Gradle Build System (aposto que é), mas direi o que entendi até agora.

Atualização 4: 2014/09/11 Adicionada folha de referências para BuildTypes, Flavorse Variants(finalmente me sinto confiante para escrever isto: D)
Atualização 3: 2014/09/11 Atualizado os espaços de trabalho e projetos de comparação para ser preciso
Atualização 2: 2014/04/17 Adicionados mais detalhes à estrutura
do projeto AS Atualização 1: 2013/07/29 Adicionada a estrutura do projeto IntelliJ

A estrutura do projeto do IntelliJ (mostrada no final) é para IntelliJ com o plugin do Android. O Android Studio, entretanto, possui uma estrutura de projeto dividida da seguinte forma:

Estrutura: Projetos e Módulos

módulo no Android Studio é como um projeto no Eclipse

projeto no Android Studio é como um espaço de trabalho no Eclipse (para ser preciso, um espaço de trabalho com projetos interdependentes)

Da documentação (o Android Studio é baseado no Intellij IDEA):

O que quer que você faça no IntelliJ IDEA, você o faz no contexto de um projeto. Um projeto é uma unidade organizacional que representa uma solução de software completa.

Seu produto acabado pode ser decomposto em uma série de módulos discretos e isolados, mas é uma definição de projeto que os reúne e os liga em um todo maior.

Para Android, significa um projeto por aplicativo e um módulo por biblioteca e por aplicativo de teste.

Existem vários problemas se você tentar construir vários aplicativos dentro do mesmo projeto. É possível, mas se você tentar (como eu fiz), verá que quase tudo foi projetado para funcionar com um único aplicativo por projeto.

Por exemplo, há uma opção para "reconstruir o projeto", o que não faz sentido com vários aplicativos, muitas outras configurações do projeto seriam inúteis e o sistema VCS integrado não é ótimo quando você tem vários repositórios.

Estrutura: Estrutura da Pasta

Pastas de nível superior

1. Projeto Principal

Isso seria todo o contexto do projeto ( Eclipse Land: como sua área de trabalho, mas limitado ao que é relevante para seu projeto). Ex: HelloWorldProjectse o nome do aplicativo que você deu eraHelloWorld

2. ideia

É onde os metadados específicos do projeto são armazenados pelo Android Studio (AS). ( Eclipse Land: project.properties arquivo)

3. Módulo de Projeto

Este é o projeto real. ex: HelloWorldse o nome do aplicativo que você forneceu foi HelloWorld

4. gradle

É aqui que está o invólucro jar do sistema de compilação do gradle, ou seja, esse jar é como o AS se comunica com o gradle instalado no Windows (o sistema operacional no meu caso).

5. Bibliotecas externas

Esta não é realmente uma pasta, mas um local onde Bibliotecas Referenciadas ( Eclipse Land: Bibliotecas Referenciadas) são mostradas. É aqui que a plataforma direcionada é exibida, etc.

[ Nota lateral: aqui é onde muitos de nós em Eclipse Land costumávamos excluir as bibliotecas referenciadas e Corrigir propriedades do projeto para corrigir erros de referência, lembra?]

Pasta do projeto em detalhes

Este é o número # 3 na lista acima. Tem os seguintes sub dirs

1. construir

Isso tem toda a saída completa do makeprocesso, ou seja, classes.dex, classes e recursos compilados, etc.

Na GUI do Android Studio, apenas algumas pastas são mostradas. O importante é que seu R.java se encontra aqui sobbuild/source/<flavor>/r/<build type(optional)>/<package>/R.java

2. libs

Esta é a pasta libs padrão que você vê no Eclipse Land também

3. src

Aqui, você só vê a pasta javae resque correspondem à srcpasta e à respasta no Eclipse Land . Isso é IMHO simplificação muito bem-vinda.

Nota sobre os módulos:

Módulos são como projetos Eclipse Land . Aqui, a ideia é que você tenha um projeto de aplicativo (Módulo # 3 na lista acima) e vários projetos de biblioteca (como Módulos separados na pasta de projeto global (# 1 na lista acima)) dos quais o projeto de aplicativo depende. Ainda não descobri como esses projetos de biblioteca podem ser reutilizados em outros aplicativos.

[ Nota lateral: toda a reorganização tem alguns benefícios, como simplificações na pasta src, mas muitas complicações. As complicações são principalmente devido à documentação MUITO, MUITO fina sobre este novo layout de projeto.]

O novo sistema de compilação

Guia do usuário para o novo Build System

Explicação de sabores e buildTypes, etc - Sobre o que é essa confusão?

CheatSheet para sabores e buildTypes

BuildType: debug e releaseestão buildTypesdisponíveis por padrão em todos os projetos. Eles são para construir / compilar o MESMO CÓDIGO para gerar APKs diferentes. Por exemplo, em releaseAPKs que você deseja executar o proguard (para ofuscação), assine-o com sua chave (em oposição à chave de depuração), execute otimizações (talvez via proguard ou outras ferramentas), use um pouco diferente packageNames(usamos com.company.productpara releasee com.company.product.debugpara debug), etc. Também usamos um sinalizador de depuração ( BuildConfig.DEBUG) para desligar o log para logcat (uma vez que torna o aplicativo lento) em releasecompilações. Isso torna a debugcompilação mais rápida durante o desenvolvimento, mas também otimizada releasepara colocar na Play Store.

Sabor do produto: Não há sabores padrão disponíveis (ou para ser preciso, o sabor padrão é em branco / sem nome). Flavorspode ser uma versão gratuita ou uma versão paga onde eles têm CÓDIGO DIFERENTE . Eles compartilham o mesmo Maincódigo, mas versões diferentes (ou nenhuma versão) de alguns arquivos de código-fonte ou recursos.

BuildVariant: A buildVarianté a que um APK gerado realmente corresponde. Eles são nomeados assim (na ordem) Product Flavor+ Build Type=Build Variant .
Exemplo 1: se você tem freee paidcomo dois sabores. As variantes de compilação que você obteria são:
Grátis - depuração
grátis - liberação
paga - depuração
paga - liberação São
4 configurações possíveis de APK. Algumas configurações podem não fazer sentido em um projeto específico, mas estão disponíveis.

Exemplo 2: (para novos projetos / sem variações) você tem 2 buildVariantsou APKs disponíveis, uma vez que a variação padrão é sem nome / em branco: versão de
depuração

Compare isso com a Estrutura do Projeto do Intellij se isso ajudar:

A pasta .idea (1) contém várias subpastas, principalmente com informações internas do IntelliJ IDEA.

A pasta src (2) contém o código-fonte do arquivo MyActivity.java (3) que implementa a funcionalidade do seu aplicativo. O arquivo pertence ao pacote com.example.

A pasta res (4) contém vários recursos visuais.

O arquivo layout / main.xml (5) define a aparência da aplicação constituída de recursos de vários tipos.

A pasta de valores (6) destina-se a armazenar arquivos .xml que descrevem recursos de vários tipos. Atualmente, a pasta contém um arquivo strings.xml com definições de recursos de String. Como você verá na seção Adicionando uma cor, a pasta de layout também pode conter, por exemplo, um descritor de cores.

A pasta drawable (7) contém imagens.

A pasta gen (8) contém o arquivo R.java (9) que vincula os recursos visuais e o código-fonte Java. Como você verá nas seções abaixo, o IntelliJ IDEA oferece suporte à integração estreita entre recursos estáticos e R.java. Assim que quaisquer recursos são adicionados ou removidos, as classes e campos de classe correspondentes em R.java são gerados automaticamente ou removidos de acordo. O arquivo R.java também pertence ao pacote com.example.

Android Studio: app \ build \ source \ r \ debug \ com.example.app \ R.java

Por que esses caminhos são diferentes? Por que meu R.java está localizado em uma pasta de depuração no Android Studio? Isso levou a alguns erros no início e, se alguém tiver alguma ideia dessas diferenças, eu os agradeceria.

Simplificando, o Android Studio está configurado para construir um tipo de compilação de depuração em seu sistema.

Eclipse / ADT é projetado para oferecer suporte a uma única construção por vez (pelo que posso dizer). Um dos principais objetivos do novo sistema de compilação ( do guia do usuário ):

Make it easy to create several variants of an application, 
either for multi-apk distribution or for different flavors of an application

Então, enquanto o Eclipse / ADT pode gerar um R.javaarquivo, o Android Studio oferece suporte a vários. O gerado R.javaestá localizado na debugpasta porque, por padrão, o novo sistema de compilação suporta debuge releasetipos de compilação imediatamente. Se você alterou sua variante de compilação (botão, canto inferior esquerdo do AS) para liberar o AS gerará R.javanorelease diretório.

Isso pode não significar nada para projetos simples, mas o suporte de Build Variants significa uma drástica simplificação do processo de build para muitos desenvolvedores, incluindo o projeto no qual estou trabalhando.

Nosso projeto suporta 4 sabores com 2 tipos de compilação (depuração e lançamento), para suportar um total de 8 combinações diferentes de APK. E cada uma dessas combinações tem configurações ligeiramente diferentes, então este sistema de construção realmente funcionou para nós. Meu android studio está instalado em uma máquina diferente, mas se a memória funcionar corretamente, o R.javaarquivo existe em build/source/<flavor>/r/<build type>/package/R.java. Quando nosso servidor de CI cria os arquivos APK, ele usa cada um desses R.javaarquivos para gerar pacotes separados.

O Google descontinuar o suporte para Android Developer Tools (ADT) no Eclipse está terminando, de acordo com nosso anúncio. Você deve migrar seus projetos de desenvolvimento de aplicativos para o Android Studio o mais rápido possível. Para obter mais informações sobre a transição para o Android Studio, consulte Migrando para o Android Studio.

Portanto, melhor para a ferramenta de desenvolvimento Android para Android Studio apenas para todo o suporte futuro do Android M ---

Para android Studio 3.0.1 e todos os recursos selecionados:

• Android O mais recente
• Android Auto
• Coisas Android
• Android wear
• Android TV
• Suporte C ++
• Suporte Kotlin

A estrutura na versão 3.0.1 não se parece em nada com todas as outras respostas.

A estrutura recente é a exibida em 2018, Android Studio 3.0.1 01/2018.

Novato encontrou algo parecido com utilizável na subpasta de recursos:

Atualize seu Android Studio 3.0.1 01_2018:

Dica de ferramenta: