Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Configuración de construcción simple

Cada nuevo módulo de prueba debe tener un archivo de configuración para dirigir el sistema de compilación con metadatos del módulo, dependencias en tiempo de compilación e instrucciones de empaquetado. Android ahora usa el sistema de compilación Soong para una configuración de prueba más simple.

Soong usa archivos Blueprint o .bp , que son descripciones declarativas simples similares a JSON de los módulos para construir. Este formato reemplaza el sistema basado en Make utilizado en versiones anteriores. Consulte los archivos de referencia de Soong en el Panel de integración continua para obtener detalles completos.

Para adaptarse a las pruebas personalizadas o utilizar el conjunto de pruebas de compatibilidad de Android (CTS), siga la configuración de prueba compleja .

Ejemplo

Las entradas a continuación provienen de este ejemplo de archivo de configuración de Blueprint: /platform_testing/tests/example/instrumentation/Android.bp

Aquí se incluye una instantánea para mayor comodidad:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["android-support-test"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

Tenga en cuenta que la declaración android_test al principio indica que se trata de una prueba. Incluir android_app , a la inversa, indicaría que se trata de un paquete de compilación.

Configuraciones

La siguiente configuración obtiene una explicación:

    name: "HelloWorldTests",

La configuración del name es necesaria cuando se especifica el tipo de módulo android_test (al comienzo del bloque). Le da un nombre a su módulo, y el APK resultante tendrá el mismo nombre y un sufijo .apk , por ejemplo, en este caso, el apk de prueba resultante se llamará HelloWorldTests.apk . Además, esto también define un nombre de destino de make para su módulo, de modo que pueda usar make [options] <HelloWorldTests> para construir su módulo de prueba y todas sus dependencias.

    static_libs: ["android-support-test"],

La configuración static_libs indica al sistema de compilación que incorpore el contenido de los módulos nombrados en el apk resultante del módulo actual. Esto significa que se espera que cada módulo con nombre produzca un archivo .jar , y su contenido se utilizará para resolver referencias a classpath durante el tiempo de compilación, así como también se incorporará en el apk resultante.

En este ejemplo, cosas que podrían ser útiles para las pruebas:

android-support-test es una versión prediseñada de la biblioteca de compatibilidad de pruebas de Android, que incluye el nuevo AndroidJUnitRunner pruebas AndroidJUnitRunner : un reemplazo del InstrumentationTestRunner integrado ahora obsoleto, con soporte para el marco de pruebas JUnit4. Obtenga más información en Prueba de aplicaciones en Android .

Si está creando un nuevo módulo de instrumentación, siempre debe comenzar con la biblioteca android-support-test como su ejecutor de pruebas. El árbol de origen de la plataforma también incluye otros marcos de prueba útiles como ub-uiautomator mockito-target , mockito-target , easymock y más.

    certificate: "platform",

La configuración del certificate indica al sistema de compilación que firme el apk con el mismo certificado que la plataforma principal. Esto es necesario si su prueba utiliza un permiso de firma protegida o una API. Tenga en cuenta que esto es adecuado para las pruebas continuas de la plataforma, pero no debe usarse en los módulos de prueba CTS. Tenga en cuenta que este ejemplo utiliza esta configuración de certificado solo con fines ilustrativos: el código de prueba del ejemplo no necesita en realidad que el apk de prueba esté firmado con el certificado de plataforma especial.

Si está escribiendo una instrumentación para su componente que vive fuera del servidor del sistema, es decir, está empaquetada más o menos como una aplicación apk normal, excepto que está integrada en la imagen del sistema y puede ser una aplicación privilegiada, es probable que su instrumentación lo haga. apuntar al paquete de la aplicación (consulte la sección a continuación sobre el manifiesto) de su componente. En este caso, el archivo MAKE de su aplicación puede tener su propia configuración de certificate , y su módulo de instrumentación debe conservar la misma configuración. Esto se debe a que para orientar su instrumentación en la aplicación bajo prueba, su apk de prueba y el apk de la aplicación deben estar firmados con el mismo certificado.

En otros casos, no es necesario tener esta configuración en absoluto: el sistema de compilación simplemente lo firmará con un certificado integrado predeterminado, basado en la variante de compilación, y normalmente se llama dev-keys .

    test_suites: ["device-tests"],

La configuración test_suites hace que la prueba sea fácilmente test_suites por el arnés de prueba de la Federación de Comercio. Aquí se pueden agregar otras suites, como CTS, para que esta prueba se pueda compartir.

${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk

Configuraciones opcionales

Los siguientes ajustes opcionales obtienen una explicación:

    test_config: "path/to/hello_world_test.xml"

La configuración test_config indica al sistema de compilación que su objetivo de prueba necesita una configuración específica. De forma predeterminada, un AndroidTest.xml junto a Android.bp está asociado con el Android.bp config.

    auto_gen_config: true

La configuración auto_gen_config indica si se debe crear o no la configuración de prueba automáticamente. Si AndroidTest.xml no existe junto a Android.bp , este atributo no necesita establecerse explícitamente como verdadero.

    require_root: true

La configuración require_root indica al sistema de compilación que agregue RootTargetPreparer a la configuración de prueba generada automáticamente. Esto garantiza que la prueba se ejecute con permisos de root.

    test_min_api_level: 29

La configuración test_min_api_level indica al sistema de compilación que agregue MinApiLevelModuleController a la configuración de prueba generada automáticamente. Cuando Trade Federation ejecuta la configuración de prueba, la prueba se omitirá si la propiedad del dispositivo de ro.product.first_api_level < test_min_api_level .