Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Android Studio AndroidManifest.xml vs build.gradle

Si alguien me puede ayudar a entender algunas cosas con respecto a Android Studio, sería más esclarecedor.

Por lo tanto, he cambiado de Eclipse a Android Studio hace un mes y hasta ahora sólo han estado trabajando en mi aplicaciones migradas. Como tal, he estado jugando con sólo el archivo AndroidManifest.xml como era habitual en Eclipse.

Sin embargo, recientemente, he comenzado a crear un nuevo proyecto en aras de aprender las diferencias de Android Studio de Eclipse desde la base. Aparte de las muy irritantes appcompat_v7 problemas que he encontrado, también estoy confundido con algunas cosas con respecto a build.gradle.

A continuación se muestra un bloque de código gradle de una aplicación creada en Android Studio:

apply plugin: 'com.android.application' android { compileSdkVersion 22 buildToolsVersion '22.0.1' defaultConfig { applicationId "com.myapp" minSdkVersion 15 targetSdkVersion 22 versionCode 1 versionName "1.0" } buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } } dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.android.support:support-v4:22.2.0' compile 'com.android.support:appcompat-v7:22.2.0' compile 'com.android.support:mediarouter-v7:22.2.0' } 

Por otro lado, a continuación se muestra un bloque de código de build.gradle de un proyecto Eclipse migrado:

 apply plugin: 'android' dependencies { compile fileTree(dir: 'libs', include: '*.jar') compile project(':google-play-services_lib') } android { compileSdkVersion 21 buildToolsVersion '22.0.1' sourceSets { main { manifest.srcFile 'AndroidManifest.xml' java.srcDirs = ['src'] resources.srcDirs = ['src'] aidl.srcDirs = ['src'] renderscript.srcDirs = ['src'] res.srcDirs = ['res'] assets.srcDirs = ['assets'] } // Move the tests to tests/java, tests/res, etc... instrumentTest.setRoot('tests') // Move the build types to build-types/<type> // For instance, build-types/debug/java, build-types/debug/AndroidManifest.xml, ... // This moves them out of them default location under src/<type>/... which would // conflict with src/ being used by the main source set. // Adding new build types or product flavors should be accompanied // by a similar customization. debug.setRoot('build-types/debug') release.setRoot('build-types/release') } } 

¿Tengo razón en algunos de los supuestos que he tomado de la lectura?

  1. CompileSdkVersion – siempre debe utilizar el más alto para la máxima compatibilidad con los teléfonos más nuevos?

  2. TargetedSdkVersion – mi propia preferencia en las condiciones óptimas de ejecución de mi aplicación?

  3. BuildToolsVersion – He leído esto siempre debe estar utilizando la última versión. ¿Puede alguien explicar por qué?

Ahora a mis preguntas con respecto al manifiesto vs gradle:

  1. ¿La compilación y la versión buildtools tienen que ser iguales? ¿Pueden ser diferentes?

  2. Si tengo un AndroidManifest.xml y un build.gradle, ¿cómo sabe Android Studio que usar para las versiones compiladas, min, orientadas, buildtools?

  3. Como una extensión de la pregunta 1, ¿qué sucede cuando hay una discrepancia entre los dos archivos (si alguien se olvidó por alguna razón y decidió agregar cosas en uno de ellos?)

  4. Dado que hay atributos duplicados entre los 2, esto significa que a partir de las aplicaciones generadas desde Android Studio, no necesito tocar AndroidManifest.xml en absoluto?

    ¿Qué pasa con la <activity></activity> para que la aplicación no fuerza cerrar cuando no puede encontrar la actividad? ¿Build.gradle se encarga de eso automáticamente? O controlar la orientación y otras características más finas (¿estoy atascado con la modificación de sólo los archivos java en Android Studio?)

    (Si no lo hace, entonces tener 2 archivos para controlar la aplicación es un poco redundante y tal vez debería haber pegado a AndroidManifest.xml?)

Lo siento por las preguntas largas, tal vez sinuosas, pero realmente es bastante confuso para mí.

Gracias por adelantado.

Actualizar:

Después de leer ¿Qué es Gradle en Android Studio? Y http://developer.android.com/tools/studio/index.html , mis nuevas preguntas:

  1. AndroidManifest.xml sigue siendo necesario, build.gradle sólo anula la configuración si tiene los mismos atributos.

    Pregunta : Así que AMBOS todavía se necesitan en Android Studio, ¿correcto?

  2. Compile & buildtools versión NO tiene que ser el mismo, pero buildtools siempre debe ser superior a compileSdkVersion.

    Pregunta : ¿Es esto porque Google crea una nueva versión de buildtools para cada nuevo Sdk y la versión superior son compatibles con versiones anteriores? Por lo tanto, buildtools más alto construirá compileSdkVersion más bajo mientras que el revés no es cierto, ¿correcto?

  • Atributos XML del diseño de combinación a RelativeLayout a través de inflar
  • BackgroundTint de Lollipop no tiene efecto en un botón
  • Cómo alinear el botón de acción flotante al centro
  • La vinculación de datos de Android pasa los argumentos al método onClick
  • Error al crear un proyecto de Android con Maven
  • Selector xml de Android para diseños
  • Errores de procesamiento XML Vista previa de Android N
  • Escapar de soportes de ángulo en XML en Eclipse / Android
  • 3 Solutions collect form web for “Android Studio AndroidManifest.xml vs build.gradle”

    Intentaré tratar tantas preguntas como sea posible, pero comenzaré sugiriendo que usted no utilice el build.gradle generado de la migración de eclipse. Cree un nuevo proyecto en Android Studio y utilice el build.gradle que genera como una plantilla para lo que debe utilizar, es decir, copie su contenido a su proyecto real y cambie los valores que tengan sentido. Pase el tiempo entendiendo y obteniendo el derecho build.gradle, le ahorrará tiempo en el futuro. También imitar la estructura de archivos del nuevo proyecto lo mejor posible. La gran cosa sobre gradle es que (generalmente) le da errores significativos.

    CompileSdkVersion – siempre debe utilizar el más alto para la máxima compatibilidad con los teléfonos más nuevos?

    TargetedSdkVersion – mi propia preferencia en las condiciones óptimas de ejecución de mi aplicación?

    En la mayoría de los casos, sean los mismos. El valor de compilación obviamente le dice al compilador qué versión compilar y la versión de destino le dice al tiempo de ejecución qué características de compatibilidad usar. Por ejemplo, si está orientando v21 y la aplicación se ejecuta en un teléfono que ejecuta v23, habilitará algunas funciones de compatibilidad para permitir que su aplicación se ejecute un poco mejor.

    BuildToolsVersion – He leído esto siempre debe estar utilizando la última versión. ¿Puede alguien explicar por qué?

    Las herramientas de construcción que puede pensar como el compilador. Si ha configurado compileSdkVersion 23, entonces necesitará la versión 23. + de las herramientas de compilación. Pero, para responder a su pregunta, digamos que había un error con la versión 23.0 de las herramientas de construcción (por ejemplo, no era la construcción de código nativo correctamente), entonces Google lanzaría 23.1 de las herramientas de construcción. Ahora si su código no compila código nativo, entonces la actualización no se aplica realmente a usted – usted no lo necesita, pero bueno, siempre es bueno actualizar en caso de que lo haga. Por otra parte, si su compileSdkVersion es 23 y tiene la versión de herramientas de construcción 24, bien la versión 24 de las herramientas de construcción es bastante capaz de construir la versión 23.

    ¿La compilación y la versión buildtools tienen que ser iguales? ¿Pueden ser diferentes?

    Esperemos que esto se responde anteriormente, pero la respuesta es sí que pueden ser diferentes, pero la versión de compilación de las herramientas principales siempre debe ser mayor que la compileSdkVersion.

    Si tengo un AndroidManifest.xml y un build.gradle, ¿cómo sabe Android Studio que usar para las versiones compiladas, min, orientadas, buildtools?

    Como una extensión de la pregunta 1, ¿qué sucede cuando hay una discrepancia entre los dos archivos (si alguien se olvidó por alguna razón y decidió agregar cosas en uno de ellos?)

    El build.gradle reemplazará los valores en el archivo AndroidManifest.xml, pero para evitar confusión, pondría todos los valores mencionados anteriormente en build.gradle y los eliminaría del manifiesto. Ahí es donde pertenecen. El build.gradle puede hacer cosas realmente geniales, puede anular valores en el manifiesto e incluso fusionar dos archivos de manifiesto.

    Dado que hay atributos duplicados entre los 2, esto significa que a partir de las aplicaciones generadas desde Android Studio, no necesito tocar AndroidManifest.xml en absoluto?

    ¿Qué pasa con lo que la aplicación no fuerza cerrar cuando no puede encontrar la actividad? ¿Build.gradle se encarga de eso automáticamente? O controlar la orientación y otras características más finas (¿estoy atascado con la modificación de sólo los archivos java en Android Studio?)

    (Si no lo hace, entonces tener 2 archivos para controlar la aplicación es un poco redundante y tal vez debería haber pegado a AndroidManifest.xml?)

    Definitivamente no. Simplemente significa que tienes que hacer algunas cosas en build.gradle y algunas en AndroidManifest.xml. Por ejemplo, si agrega una actividad, debe editar el archivo AndroidManifest.xml como de costumbre. Si desea modificar las propiedades de la actividad (rotación, tema, etc) esto también se hace en AndroidManifest.xml. Si desea comenzar a usar una nueva biblioteca de Maven Central, tendrá que añadirla a build.gradle. Si desea cambiar las claves que utiliza para firmar la aplicación cuando crea una versión de lanzamiento o cambie el nombre de versión de su aplicación: build.gradle. Básicamente el build.gradle le da un mayor grado de control sobre sus compilaciones, realmente recomiendo revisar lo que puede hacer aquí: http://developer.android.com/tools/building/configuring-gradle.html

    AndroidManifest.xml sigue siendo necesario, build.gradle sólo anula la configuración si tiene los mismos atributos.

    Pregunta: Así que AMBOS todavía se necesitan en Android Studio, ¿correcto?

    Correcto. Todavía necesitas los dos.

    Compile & buildtools versión NO tiene que ser el mismo, pero buildtools siempre debe ser superior a compileSdkVersion.

    Pregunta: ¿Es esto porque Google crea una nueva versión de buildtools para cada nuevo Sdk y la versión superior son compatibles con versiones anteriores? Por lo tanto, buildtools más alto construirá compileSdkVersion más bajo mientras que el revés no es cierto, ¿correcto?

    También correcto!

    El archivo de manifiesto de Android es útil para la actividad, los permisos necesarios y los servicios de declaración en las aplicaciones de Android, pero build.gradle es útil para la declaración de la biblioteca, etc.

    Gradle VS Menifest como a continuación … Gradle anula los valores de manifiesto y prefiero actualizar el archivo build.gradle en el estudio de Android y el archivo menifest en android eclipse. Gradle soporta la aplicación que puede ser controlada a través del marco de estudio de Android. Código de versión, nombre de versión, SDK de destino y muchas otras libs refrence. Cambiar o actualizar con un solo clic en Android Studio, después de eso podemos construir proyecto y gentrar nuevo apk.

    Para Android Studio:

    Aplique el complemento: 'com.android.application'

    Android {compileSdkVersion 23 buildToolsVersion "23.0.3"

     defaultConfig { applicationId "com.android.demo" minSdkVersion 18 targetSdkVersion 23 versionCode 1 versionName "1.0" } buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } 

    }

    Dependencias {compilar fileTree (include: ['* .jar'], dir: 'libs') testCompile 'junit: junit: 4.12' compilar 'com.android.support:appcompat-v7:23.4.0' compilar 'com.android .support: diseño: 23.4.0 'compilar' com.google.firebase: firebase-core: 9.4.0 'compilar' com.google.firebase: firebase-messaging: 9.4.0 'compilar' com.android.volley: volley : 1.0.0 'compilar' com.google.code.gson: gson: 2.6.1 '

    } Aplique el complemento: 'com.google.gms.google-services'

    Para Android Eclipse:

    Xmlns: android = "http://schemas.android.com/apk/res/android&quot;

      package="com.android.app" android:versionCode="1" android:versionName="1.0" >` 
    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.