En la versión de Android 12, se incluyen algunos cambios en los ITS de la cámara. En esta página, se resumen los cambios que se dividen en cuatro categorías generales:
- Refactorización a Python 3
- Adopción del framework de pruebas de Mobly
- Prueba los cambios
- Nuevas pruebas
Refactorización a Python 3
Debido a la baja de Python 2.7 en enero de 2020, toda la base de código de ITS de la cámara se refactorizó a Python 3. Las siguientes versiones y bibliotecas de Python son obligatorias en Android 12:
- Python 3.7.9 o Python 3.7.10
- OpenCV 3.4.2
- Numpy 1.19.2
- Matplotlib 3.3.2
- Scipy 1.5.2
- pySerial 3.5
- Pillow 8.1.0
- PyYAML 5.3.1
El selector de pruebas principal, tools/run_all_tests.py, sigue siendo el mismo que las versiones de Android 11 o anteriores y se refactoriza a Python 3.
Todas las pruebas individuales se refactorizan y usan la nueva clase de configuración de prueba definida en tests/its_base_test.py. La mayoría de los nombres y la funcionalidad de las pruebas siguen siendo los mismos.
En Android 12, todas las pruebas individuales ahora cargan sus escenas. Si bien la carga de escenas para cada prueba
aumenta el tiempo de prueba general, permite depurar pruebas individuales.
Para obtener más información sobre los cambios de prueba individuales, consulta Cambios de prueba.
Los siguientes módulos de Python se refactorizan con un cambio de nombre:
pymodules/its/caps.py→utils/camera_properties_utils.pypymodules/its/cv2image.py→utils/opencv_processing_utils.pypymodules/its/device.py→utils/its_session_utils.pypymodules/its/error.py→utils/error_util.pypymodules/its/image.py→utils/image_processing_utils.pypymodules/its/objects.py→utils/capture_request_utils.pypymodules/its/target.py→utils/target_exposure_utils.pytools/hw.py→utils/sensor_fusion_utils.py
Adopción del framework de pruebas de Mobly
Mobly es un framework de pruebas basado en Python que admite casos de prueba que requieren varios dispositivos con configuraciones de hardware personalizadas. El ITS de la cámara usa la infraestructura de pruebas de Mobly para permitir un mejor control y registro de las pruebas.
El ITS de la cámara usa la infraestructura de pruebas de Mobly para permitir un mejor control y registro de las pruebas. Mobly es un framework de pruebas basado en Python que admite casos de prueba que requieren varios dispositivos con configuraciones de hardware personalizadas. Para obtener más información sobre Mobly, consulta google/mobly.
Archivos config.yml
Con el framework de Mobly, puedes configurar un dispositivo en prueba (DUT) y una tabla en la clase its_base_test. Se usa un archivo config.yml (YAML) para crear un campo de pruebas de Mobly. Se pueden configurar varios bancos de pruebas dentro de este archivo de configuración, por ejemplo, una tablet y un banco de pruebas de fusión de sensores. Dentro de la sección del controlador de cada plataforma de pruebas, puedes especificar device_ids para identificar los dispositivos Android adecuados para el ejecutor de pruebas. Además de los IDs de dispositivos, se pasan otros parámetros, como brightness, chart_distance, debug_mode, camera_id y scene_id de la tablet en la clase de prueba. Los valores comunes de los parámetros de prueba son los siguientes:
brightness: 192 (all tablets except Pixel C)
chart_distance: 31.0 (rev1/rev1a box for FoV < 90° cameras)
chart_distance: 22.0 (rev2 test rig for FoV > 90° cameras)
Pruebas basadas en tablets
Para las pruebas basadas en tablets, la palabra clave TABLET debe estar presente en el nombre del campo de pruebas. Durante la inicialización, el ejecutor de pruebas de Mobly inicializa TestParams y lo pasa a las pruebas individuales.
El siguiente es un archivo config.yml de ejemplo para ejecuciones basadas en tablets.
TestBeds:
- Name: TEST_BED_TABLET_SCENES
# Test configuration for scenes[0:4, 6, _change]
Controllers:
AndroidDevice:
- serial: 8A9X0NS5Z
label: dut
- serial: 5B16001229
label: tablet
TestParams:
brightness: 192
chart_distance: 22.0
debug_mode: "False"
chart_loc_arg: ""
camera: 0
scene: <scene-name> # if <scene-name> runs all scenes
El entorno de pruebas se puede invocar con tools/run_all_tests.py. Si no hay valores de línea de comandos, las pruebas se ejecutan con los valores del archivo config.yml.
Además, puedes anular los valores del archivo de configuración camera y scene en la línea de comandos con comandos similares a los de Android 11 o versiones anteriores.
Por ejemplo:
python tools/run_all_tests.py
python tools/run_all_tests.py camera=1
python tools/run_all_tests.py scenes=2,1,0
python tools/run_all_tests.py camera=1 scenes=2,1,0
Pruebas de fusión de sensores
Para las pruebas de fusión de sensores, el nombre del entorno de pruebas debe incluir la palabra clave SENSOR_FUSION. Las escenas que se probaron determinan la plataforma de pruebas correcta. Android 12 admite controladores Arduino y Canakit para la fusión de sensores.
El siguiente es un archivo config.yml de ejemplo para ejecuciones de fusión de sensores.
Testbeds
- Name: TEST_BED_SENSOR_FUSION
# Test configuration for sensor_fusion/test_sensor_fusion.py
Controllers:
AndroidDevice:
- serial: 8A9X0NS5Z
label: dut
TestParams:
fps: 30
img_size: 640,480
test_length: 7
debug_mode: "False"
chart_distance: 25
rotator_cntl: arduino # cntl can be arduino or canakit
rotator_ch: 1
camera: 0
Para ejecutar pruebas de fusión de sensores con la plataforma de prueba de fusión de sensores, usa lo siguiente:
python tools/run_all_tests.py scenes=sensor_fusion
python tools/run_all_tests.py scenes=sensor_fusion camera=0
Varios bancos de pruebas
Se pueden incluir varios bancos de pruebas en el archivo de configuración. La combinación más común es tener una plataforma de pruebas de tablets y una plataforma de pruebas de fusión de sensores.
El siguiente es un archivo config.yml de muestra con pruebas de integración de fusión de sensores y tablets.
Testbeds
- Name: TEST_BED_TABLET_SCENES
# Test configuration for scenes[0:4, 6, _change]
Controllers:
AndroidDevice:
- serial: 8A9X0NS5Z
label: dut
- serial: 5B16001229
label: tablet
TestParams:
brightness: 192
chart_distance: 22.0
debug_mode: "False"
chart_loc_arg: ""
camera: 0
scene: <scene-name> # if <scene-name> runs all scenes
- Name: TEST_BED_SENSOR_FUSION
# Test configuration for sensor_fusion/test_sensor_fusion.py
Controllers:
AndroidDevice:
- serial: 8A9X0NS5Z
label: dut
TestParams:
fps: 30
img_size: 640,480
test_length: 7
debug_mode: "False"
chart_distance: 25
rotator_cntl: arduino # cntl can be arduino or canakit
rotator_ch: 1
camera: 0
Pruebas manuales
Las pruebas manuales siguen siendo compatibles con Android 12.
Sin embargo, el entorno de pruebas debe identificar las pruebas como tales con la palabra clave MANUAL en el nombre del entorno de pruebas. Además, la plataforma de pruebas no puede incluir un ID de tablet.
El siguiente es un archivo config.yml de ejemplo para pruebas manuales.
TestBeds:
- Name: TEST_BED_MANUAL
Controllers:
AndroidDevice:
- serial: 8A9X0NS5Z
label: dut
TestParams:
debug_mode: "False"
chart_distance: 31.0
camera: 0
scene: scene1
Cómo probar escenas sin tablets
Las pruebas de la escena 0 y la escena 5 se pueden realizar con TEST_BED_TABLET_SCENES o con TEST_BED_MANUAL. Sin embargo, si las pruebas se realizan con TEST_BED_TABLET_SCENES, la tablet debe estar conectada y el ID de serie de la tablet debe ser válido, aunque no se use, ya que la configuración de la clase de prueba asigna el valor del ID de serie de la tablet.
Ejecuta pruebas individuales
Las pruebas individuales solo se pueden ejecutar con fines de depuración, ya que sus resultados no se informan al verificador de CTS. Debido a que los archivos config.yml no se pueden reemplazar en la línea de comandos para camera y scene, estos parámetros deben ser correctos en el archivo config.yml para la prueba individual en cuestión. Además, si hay más de un campo de pruebas en el archivo de configuración, debes especificarlo con la marca --test_bed. Por ejemplo:
python tests/scene1_1/test_black_white.py --config config.yml --test_bed TEST_BED_TABLET_SCENES
Artefactos de prueba
En Android 12, los artefactos de prueba para ITS de la cámara se almacenan de manera similar a Android 11 o versiones anteriores, pero con los siguientes cambios:
- Para mayor claridad, el directorio
/tmpdel artefacto de prueba tieneCameraITS_al principio de la cadena aleatoria de 8 caracteres. - El resultado y los errores de la prueba se almacenan en
test_log.DEBUGpara cada prueba en lugar detest_name_stdout.txtytest_name_stderr.txt. - Los logcats del DUT y la tablet de cada prueba individual se almacenan en el directorio
/tmp/CameraITS_########, lo que simplifica la depuración, ya que se registra toda la información necesaria para depurar los problemas de 3A.
Prueba los cambios
En Android 12, las escenas de la tablet son archivos PNG en lugar de PDF. El uso de archivos PNG permite que más modelos de tablets muestren las escenas correctamente.
scene0/test_jitter.py
La prueba test_jitter se ejecuta en cámaras ocultas físicas en Android 12.
scene1_1/test_black_white.py
En Android 12, test_black_white tiene la funcionalidad de test_black_white y test_channel_saturation.
En la siguiente tabla, se describen las dos pruebas individuales en Android 11.
| Nombre de la prueba | Primer nivel de API | Afirmaciones |
|---|---|---|
| scene1_1/test_black_white.py | TODAS | Exposición corta, valores RGB de baja ganancia ~[0, 0, 0] Exposición larga, valores RGB de alta ganancia ~[255, 255, 255] |
| scene1_1/test_channel_saturation.py | 29 | Se redujo la tolerancia en las diferencias [255, 255, 255] para eliminar el tono de color en las imágenes en blanco. |
En la siguiente tabla, se describe la prueba combinada, scene1_1/test_black_white.py, en Android 12.
| Nombre de la prueba | Primer nivel de API | Afirmaciones |
|---|---|---|
| scene1_1/test_black_white.py | TODAS | Exposición corta, valores RGB de baja ganancia ~[0, 0, 0] Exposición larga, valores RGB de alta ganancia ~[255, 255, 255] y tolerancia reducida entre los valores para eliminar el tono de color en las imágenes en blanco. |
scene1_1/test_burst_sameness_manual.py
La prueba test_burst_sameness_manual se ejecuta en cámaras ocultas físicas en Android 12.
scene1_2/test_tonemap_sequence.py
La prueba test_tonemap_sequence se ejecuta en cámaras LIMITADAS en Android 12.
scene1_2/test_yuv_plus_raw.py
La prueba test_yuv_plus_raw se ejecuta en cámaras ocultas físicas en Android 12.
scene2_a/test_format_combos.py
La prueba test_format_combos se ejecuta en cámaras LIMITADAS en Android 12.
scene3/test_flip_mirror.py
La prueba test_flip_mirror se ejecuta en cámaras LIMITADAS en Android 12.
scene4/test_aspect_ratio_and_crop.py
La búsqueda de círculos en scene4/test_aspect_ratio_and_crop.py se refactorizó en Android 12.
Las versiones anteriores de Android usaban un método que implicaba encontrar un contorno secundario (el círculo) dentro del contorno superior (el cuadrado) con filtros de tamaño y color. Android 12 usa un método que implica encontrar todos los contornos y, luego, filtrar por encontrar los componentes más circulares. Para filtrar los círculos falsos en la pantalla, se requiere un área de contorno mínima, y el contorno del círculo debe ser negro.
Los contornos y sus criterios de selección se muestran en la siguiente imagen.
Figura 1: Dibujo conceptual de contornos y criterios de selección
El método de Android 12 es más sencillo y funciona para resolver el problema con el recorte del cuadro de límite en algunas tablets con pantalla. Todos los candidatos de círculo se registran para depurar.
En Android 12, la prueba de recorte se ejecuta para dispositivos FULL y LEVEL3. Android 11 o versiones anteriores omiten las aserciones de prueba de recorte para dispositivos FULL.
En la siguiente tabla, se enumeran las aserciones para test_aspect_ratio_and_crop.py que corresponden a un nivel de dispositivo y un primer nivel de API determinados.
| Nivel del dispositivo | Primer nivel de API | Afirmaciones |
|---|---|---|
| LIMITADA | TODAS | Relación de aspecto Campo de visión para formatos 4:3, 16:9 y 2:1 |
| COMPLETO | < 31 | Relación de aspecto Campo de visión para formatos 4:3, 16:9 y 2:1 |
| COMPLETO | ≥ 31 | Recorte Relación de aspecto Campo de visión para formatos 4:3, 16:9 y 2:1 |
| LEVEL3 | TODAS | Recorte Relación de aspecto Campo de visión para formatos 4:3, 16:9 y 2:1 |
scene4/test_multi_camera_alignment.py
Se refactorizó el método undo_zoom() para las capturas YUV en scene4/test_multi_camera_alignment.py para tener en cuenta con mayor precisión el recorte en sensores que no coinciden con la relación de aspecto de la captura.
Código de Python 2 de Android 11
zoom_ratio = min(1.0 * yuv_w / cr_w, 1.0 * yuv_h / cr_h)
circle[i]['x'] = cr['left'] + circle[i]['x'] / zoom_ratio
circle[i]['y'] = cr['top'] + circle[i]['y'] / zoom_ratio
circle[i]['r'] = circle[i]['r'] / zoom_ratio
Código de Python 3 de Android 12
yuv_aspect = yuv_w / yuv_h
relative_aspect = yuv_aspect / (cr_w/cr_h)
if relative_aspect > 1:
zoom_ratio = yuv_w / cr_w
yuv_x = 0
yuv_y = (cr_h - cr_w / yuv_aspect) / 2
else:
zoom_ratio = yuv_h / cr_h
yuv_x = (cr_w - cr_h * yuv_aspect) / 2
yuv_y = 0
circle['x'] = cr['left'] + yuv_x + circle['x'] / zoom_ratio
circle['y'] = cr['top'] + yuv_y + circle['y'] / zoom_ratio
circle['r'] = circle['r'] / zoom_ratio
sensor_fusion/test_sensor_fusion.py
En Android 12, se agregó un método para detectar características en las imágenes para la prueba de fusión de sensores.
En versiones anteriores a Android 12, se usa toda la imagen para encontrar los 240 mejores componentes, que luego se enmascaran en el 20% central para evitar los efectos del obturador enrollable, y el requisito mínimo de componentes es de 30.
Si las características que encuentra este método no son suficientes, Android 12 enmascara el área de detección de características en el 20% central primero y limita las características máximas a dos veces el requisito mínimo de características.
En la siguiente imagen, se muestra la diferencia entre la detección de funciones de Android 11 y Android 12. Aumentar el umbral de requisitos mínimos de las funciones genera la detección de funciones de baja calidad y afecta negativamente las mediciones.
Figura 2: Diferencia en la detección de componentes entre Android 11 y Android 12
Pruebas nuevas
scene0/test_solid_color_test_pattern.py
Se habilitó una prueba nueva, test_solid_color_test_pattern, para Android 12. Esta prueba está habilitada para todas las cámaras y se describe en la siguiente tabla.
| Scene | Nombre de la prueba | Primer nivel de API | Descripción |
|---|---|---|---|
| 0 | test_solid_color_test_pattern | 31 | Confirma la salida de imágenes de color sólido y la programabilidad del color de las imágenes. |
Se deben habilitar los patrones de prueba de color sólido para admitir el modo de privacidad de la cámara.
La prueba test_solid_color_test_pattern confirma la salida de imagen YUV de color sólido con el color definido por el patrón seleccionado, y el color de la imagen cambia según las especificaciones.
Parámetros
cameraPrivacyModeSupport: Determina si la cámara admite el modo de privacidad.android.sensor.testPatternMode: Establece el modo de patrón de prueba. En esta prueba, se usaSOLID_COLOR.android.sensor.testPatternData: Establece los valores de los patrones de prueba R, Gr, Gb y G para el modo de patrón de prueba.
Para obtener una descripción del patrón de prueba de color sólido, consulta SENSOR_TEST_PATTERN_MODE_SOLID_COLOR.
Método
Se capturan fotogramas YUV para los parámetros establecidos y se valida el contenido de la imagen. El patrón de prueba se envía directamente desde el sensor de imagen, por lo que no se requiere una escena en particular. Si se admite PER_FRAME_CONTROL, se captura un solo fotograma YUV para cada parámetro de configuración probado. Si no se admite PER_FRAME_CONTROL, se capturan cuatro fotogramas con solo el último fotograma analizado para maximizar la cobertura de pruebas en cámaras LIMITED.
Las capturas YUV se configuran en patrones de prueba BLACK, WHITE, RED, GREEN y BLUE completamente saturados. Como la definición del patrón de prueba se realiza según el patrón Bayer del sensor, los canales de color deben configurarse para cada color, como se muestra en la siguiente tabla.
| Color | testPatternData (RGGB) |
|---|---|
| NEGRO |
(0, 0, 0, 0)
|
| BLANCO |
(1, 1, 1, 1)
|
| RED |
(1, 0, 0, 0)
|
| VERDE |
(0, 1, 1, 0)
|
| AZUL |
(0, 0, 0, 1)
|
Tabla de aserciones
En la siguiente tabla, se describen las aserciones de prueba de test_solid_color_test_pattern.py.
| Cámara Primer nivel de API |
Tipo de cámara | Colores confirmados |
|---|---|---|
| 31 | Bayer | NEGRO, BLANCO, ROJO, VERDE, AZUL |
| 31 | MONO | NEGRO Y BLANCO |
| < 31 | Bayer/MONO | NEGRO |
Pruebas de clase de rendimiento
scene2_c/test_camera_launch_perf_class.py
Verifica que el inicio de la cámara sea inferior a 500 ms para las cámaras principales frontal y posterior con la escena de rostro scene2_c.
scene2_c/test_jpeg_capture_perf_class.py
Verifica que la latencia de captura de JPEG de 1080p sea inferior a 1 segundo para las cámaras principales frontal y posterior con la escena de rostro scene2_c.