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
Refactoriza a Python 3
Debido a la baja de Python 2.7 en enero de 2020, toda la base de código del ITS de la cámara se refactorizó a Python 3. Se requieren las siguientes versiones y bibliotecas de Python 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 escena para cada prueba aumenta el tiempo total de la prueba, habilita la depuración de 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 refactorizaron 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 tablet de gráficos en la clase its_base_test. Se usa un archivo config.yml (YAML) para crear un entorno 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 muestra 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
Se puede invocar testbed 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 de los archivos de configuración camera y scene en la línea de comandos con comandos similares a 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 la prueba de fusión de sensores, el nombre del banco de prueba debe incluir la palabra clave SENSOR_FUSION. Las escenas que se probaron determinan la plataforma de pruebas correcta. Android 12 admite los controladores para la fusión de sensores de Arduino y Canakit.
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 el equipo 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 prueba
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, el campo de pruebas no puede incluir un ID de tablet.
El siguiente es un archivo config.yml de muestra 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
Probar escenas sin tablets
Las pruebas de las escenas 0 y 5 se pueden hacer con TEST_BED_TABLET_SCENES o 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:
- El directorio
/tmpdel artefacto de prueba tieneCameraITS_antepuesto a la cadena aleatoria de 8 caracteres para mayor claridad. - 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.
Probar 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.
escena1_2/test_tonemap_seq.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 la búsqueda de los atributos 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 círculos candidatos 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 | Aserciones |
|---|---|---|
| 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 | Recortar Relación de aspecto FoV para formatos 4:3, 16:9, 2:1 |
| LEVEL3 | TODAS | Recorte Relación de aspecto Campo de visión para formatos 4:3, 16:9 y 2:1 |
escena4/prueba_multi_cámara_alineación.py
El método undo_zoom() para capturas de YUV en scene4/test_multi_camera_alignment.py se refactorizó para dar cuenta de forma más precisa del 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: Diferencias en la detección de funciones entre Android 11 y Android 12
Pruebas nuevas
scene0/test_solid_color_test_pattern.py
Se habilitó una nueva prueba, 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 colores sólidos 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. Esta prueba 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.
escena2_c/test_jpeg_capture_perf_class.py
Verifica que la latencia de captura JPEG de 1080p sea inferior a 1 segundo para la cámara principal frontal y posterior con la escena facial escena2_c.