El misterio: Android Studio's Project Structure and Build System

No sé si esto se debe al sistema de compilación Gradle (apuesto a que sí), pero os contaré lo que he entendido hasta ahora. Actualización 4: 2014/09/11 Añadida Hoja de trucos para BuildTypes, Flavors y Variants(por fin me siento con confianza para escribir esto :D) Actualización 3: 2014/09/11 Actualizados los espacios de trabajo y proyectos de comparación para ser precisos. Actualización 2: 2014/04/17 Añadido más detalles a la estructura del proyecto AS Actualización 1: 2013/07/29 Añadido IntelliJ estructura del proyecto La estructura de proyecto de IntelliJ's (mostrada al final) es para IntelliJ con el plugin android. El Android Studio, sin embargo, tiene una estructura de proyecto dividido así:

Estructura: Proyectos y Módulos

module en Android Studio es como un project en Eclipse. un proyecto en Android Studio es como un espacio de trabajo en Eclipse (para ser precisos, un espacio de trabajo con proyectos interdependientes) De [la documentación][1] (Android Studio está basado en Intellij IDEA) :

Cualquier cosa que hagas en IntelliJ IDEA, la haces en el contexto de un proyecto. Un proyecto es una unidad organizativa que representa una solución de software completa. ; Su producto final puede ser descompuesto en una serie de discretos, módulos aislados, pero es una definición de proyecto lo que los reúne juntos y los une en un todo mayor. Para Android, significa un proyecto por aplicación, y un módulo por biblioteca y por aplicación de prueba. Existen múltiples problemas si intentas crear varias aplicaciones dentro del mismo proyecto. Es posible, pero si lo intentas (como hice yo), verás que casi todo está diseñado para funcionar con una sola app por proyecto.
Por ejemplo, hay una opción para "reconstruir el proyecto", que no tiene sentido con múltiples apps, muchos otros ajustes del proyecto serían inútiles, y el sistema VCS incorporado no es'genial cuando tienes múltiples repositorios.

Estructura: Estructura de carpetas

Carpetas de nivel superior

1. Proyecto Principal

Esto sería todo el contexto del proyecto (Eclipse Land: Como tu espacio de trabajo pero limitado a lo que es relevante para tu proyecto). Ej: HelloWorldProject si el nombre de la aplicación que diste fue HelloWorld.

2. .idea

Aquí es donde los metadatos específicos del proyecto son almacenados por Android Studio (AS). (Eclipse Land: archivo project.properties)

3. Módulo de Proyecto

Este es el proyecto real. ex: HelloWorld si el nombre de la aplicación que diste fue HelloWorld

4. gradle

Aquí es donde el gradle build system's jar wrapper es decir, este jar es como AS se comunica con gradle instalado en Windows (el SO en mi caso).

5. Bibliotecas externas

Esto no es realmente una carpeta, sino un lugar donde se muestran las Bibliotecas Referenciadas (Eclipse Land: Referenced Libraries). Aquí es donde se muestra la Plataforma de destino, etc. [Nota al margen: Aquí es donde muchos de nosotros en Eclipse Land solíamos borrar las librerías referenciadas y Fix Project Properties para corregir errores de referencia, ¿recuerdas?]

Carpeta del Proyecto en Detalle

Este es el número #3 en la lista anterior. Tiene los siguientes subdirectorios

1. build

Contiene todos los resultados del proceso make, es decir, classes.dex, clases compiladas y recursos, etc. En la interfaz gráfica de Android Studio, sólo se muestran algunas carpetas. La parte importante es que tu R.java se encuentra aquí bajo build/source//r///R.java.

2. libs

Esta es la carpeta libs estándar que se ve en eclipse land también

3. src

Aquí, sólo ves las carpetas java y res que corresponden a las carpetas src y res en Eclipse Land. Esta es una simplificación muy bienvenida IMHO.

Nota sobre Módulos:

Los módulos son como los proyectos de Eclipse Land. Aquí la idea es que usted tiene un proyecto de aplicación (Módulo # 3 en la lista anterior) y varios proyectos de biblioteca (como módulos separados en la carpeta del proyecto global (# 1 en la lista anterior)) que el proyecto de aplicación depende. Todavía no he averiguado cómo se pueden reutilizar estos proyectos de biblioteca en otras aplicaciones. [Nota al margen: La reorganización tiene algunos beneficios como simplificaciones en la carpeta src, pero muchas complicaciones. Las complicaciones son principalmente debido MUY MUY** escasa documentación sobre este nuevo diseño del proyecto].

El nuevo sistema de compilación

Guía del usuario para el nuevo sistema de compilación

Explicación de flavors y buildTypes, etc - ¿A qué viene tanto alboroto?

Hoja de trucos para flavors y buildTypes

BuildType: debug y release son buildTypes disponibles por defecto en todos los proyectos. Son para construir / compilar el código SAME CODE para generar diferentes APKs. Por ejemplo, en los APKs release querrás ejecutar proguard (para la ofuscación), firmarlo con tu clave (frente a la clave debug), ejecutar optimizaciones (quizás mediante proguard u otras herramientas), usar packageNames ligeramente diferentes (usamos com.company.product para release y com.company.product.debug para debug), etc. También utilizamos un indicador de depuración (BuildConfig.DEBUG) para desactivar el registro en logcat (ya que ralentiza la aplicación) en las compilaciones release. Esto hace que para una construcción debug más rápido durante el desarrollo, sino también una construcción release optimizado para poner en play store. Sabor del producto: No hay sabores por defecto disponibles (o para ser precisos, el sabor por defecto está en blanco / sin nombre). Los "sabores" pueden ser versión gratuita o versión de pago donde tienen CODIFICACIÓN DIFERENTE. Comparten el mismo Código Principal pero diferentes versiones (o ninguna versión) de algunos archivos de código fuente o recursos. BuildVariant: Una buildVariant es lo que realmente corresponde a un APK generado. Se denominan así (en orden) Product Flavor + Build Type = Build Variant.
Ejemplo 1: si tienes free y paid como dos sabores. Las variantes de construcción que obtendría son:
Gratis - depuración Free - release De pago - depuración De pago - versión Así que hay 4 posibles configuraciones APK. Algunas configuraciones pueden no tener sentido en un proyecto en particular, pero están disponibles. Ejemplo 2: (para proyectos nuevos/sin sabores) Tienes 2 buildVariants o APKs disponibles, ya que el sabor por defecto es nameless/blank: debug release

Compare esto con Intellij's Project Structure si eso ayuda:

Intellij Project Structure Snapshot La carpeta .idea (1) contiene una serie de subcarpetas, principalmente con información interna de IntelliJ IDEA. La carpeta src (2) contiene el código fuente del archivo MyActivity.java (3) que implementa la funcionalidad de tu aplicación. El archivo pertenece al paquete com.example. La carpeta res (4) contiene varios recursos visuales. El archivo layout/main.xml (5) define la apariencia de la aplicación constituida por recursos de varios tipos. La carpeta values (6) está destinada a almacenar archivos .xml que describen recursos de diversos tipos. Actualmente, la carpeta contiene un archivo strings.xml con definiciones de recursos String. Como se verá en la sección Añadir un color, la carpeta layout también puede contener, por ejemplo, un descriptor de colores. La carpeta drawable (7) contiene imágenes. La carpeta gen (8) contiene el archivo R.java (9) que enlaza los recursos visuales y el código fuente Java. Como verás en las secciones siguientes, IntelliJ IDEA soporta una estrecha integración entre los recursos estáticos y R.java. En cuanto se añaden o eliminan recursos, se generan o eliminan automáticamente las clases y campos de clase correspondientes en R.java. El archivo R.java también pertenece al paquete com.example.

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

¿Por qué estas rutas son diferentes? ¿Por qué mi R.java se encuentra en una carpeta de depuración en Android Studio? Esto llevó a algunos errores al principio, y si alguien tiene alguna idea de estas diferencias se lo agradecería.

En pocas palabras, Android Studio está configurado para construir una depuración Build Type en su sistema.

Eclipse/ADT está diseñado para soportar una sola compilación a la vez (por lo que puedo decir). Uno de los principales objetivos del nuevo sistema de construcción (de la guía del usuario):

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

Así que mientras Eclipse/ADT podría generar un archivo R.java, Android Studio soporta múltiples. El R.java generado se encuentra en la carpeta debug porque por defecto el nuevo sistema de compilación soporta los tipos de compilación debug y release. Si cambiaste tu variante de compilación (botón, esquina inferior izquierda de AS) a release AS generará R.java en el directorio release.

Esto puede no significar nada para proyectos simples, pero el soporte de Build Variants significa una simplificación drástica del proceso de compilación para muchos desarrolladores, incluyendo el proyecto en el que estoy trabajando.

Nuestro proyecto soporta 4 sabores con 2 tipos de compilación (debug y release), para soportar un total de 8 combinaciones diferentes de APK. Y cada una de esas combinaciones tienen configuraciones ligeramente diferentes, por lo que este sistema de construcción realmente funcionó para nosotros. Mi android studio está instalado en una máquina diferente, pero si la memoria no me falla el archivo R.java existe en build/source//r//package/R.java. Cuando nuestro servidor CI construye los archivos APK utiliza cada uno de estos archivos R.java para generar paquetes separados.

Google Descontinuar el apoyo para el Android Developer Tools (ADT) en Eclipse está terminando, según nuestro anuncio. Usted debe migrar sus proyectos de desarrollo de aplicaciones a Android Studio tan pronto como sea posible. Para obtener más información sobre la transición a Android Studio, consulte Migración a Android Studio. a Android Studio.

Así que lo mejor para la herramienta de desarrollo de Android para Android Studio sólo para todo el futuro apoyo de Android M ---