Pruebas de GTS (GtsSafetyCenterTestCases
)
Las pruebas de GTS imponen restricciones en el archivo de configuración. Consulta Actualiza el archivo de configuración. Un dispositivo está exento de estas pruebas si no es compatible con Safety Center.
Las restricciones son las siguientes:
- Debería haber al menos siete grupos de fuentes del Centro de seguridad, que deben permanecer en el estado predeterminado o sin modificar. Algunos campos específicos, como los títulos de las fuentes, el estado de visualización inicial y el resumen, a veces se respaldan con cadenas superpuestas y se pueden modificar.
Para
GoogleAppSecuritySources
:- No quites ni modifiques la fuente de seguridad
GooglePlayProtect
. - Puedes quitar o cambiar la fuente de seguridad de
GoogleAppProtectionService
. Si está presente, haz lo siguiente:- Debe admitir el registro.
- Si el nombre del paquete no se modifica, debe tener
initialDisplayState="hidden"
en Android 13; en Android 14, debe serissue-only-safety-source
ydeduplicationGroup
debe permanecer sin cambios. - Si se cambia el nombre del paquete, debe contener la función
"android.app.role.SYSTEM_APP_PROTECTION_SERVICE"
. Además, en Android 14, no debe tener undeduplicationGroup
.
- No quites ni modifiques la fuente de seguridad
Para
AndroidLockScreenSources
:- La instancia
summary
del grupo es obligatoria y puedes modificarla, incluso con una superposición de cadenas. - Debe haber al menos una fuente de seguridad.
- La primera fuente de seguridad está diseñada para ser la fuente que controla la configuración de la pantalla de bloqueo y no debería poder enviar problemas o entradas más graves que
SEVERITY_LEVEL_RECOMMENDATION
(maxSeverityLevel="300"
o hasta tarjetas de advertencia o entrada amarillas). En Android 14,deduplicationGroup
no debe cambiar. - El propósito de las otras fuentes de seguridad es ser fuentes relacionadas con los mecanismos de desbloqueo biométrico y deben tener
maxSeverityLevel="0"
.
- La instancia
En Android 13, no modifiques
GoogleAccountSources
,GoogleDeviceFinderSources
niAndroidAdvancedSources
. En Android 14, puedes quitar algunas de las fuentes nuevas que se introdujeron en estos grupos (p. ej., copia de seguridad y restablecimiento). También puedes agregar fuentes estáticas nuevas al grupoAndroidAdvancedSources
.Para
GoogleUpdateSources
:- Puedes cambiar
intentAction
porGoogleSecurityUpdates
y modificarlo con una superposición de cadenas. - No modifiques
GooglePlaySystemUpdate
.
- Puedes cambiar
Para
AndroidPrivacySources
:- Puedes agregar, quitar o modificar algunas fuentes, siempre que sean
issue-only
. - Debe mantener
packageName="com.google.android.permissioncontroller"
. - No modifiques el resto de las fuentes
AndroidPrivacySources
.
- Puedes agregar, quitar o modificar algunas fuentes, siempre que sean
Para el resto de los grupos de fuentes de seguridad (si los hay):
- Los grupos no deben tener
summary
nistatelessIconType
, lo que genera un grupoSAFETY_SOURCES_GROUP_TYPE_RIGID
(SAFETY_SOURCES_GROUP_TYPE_STATELESS
en Android 14). - Cada fuente dentro de cada grupo debe ser estática o tener
maxSeverityLevel="0"
, por ejemplo, para permitir el envío de entradas grises o verdes, pero sin problemas.
- Los grupos no deben tener
Pruebas de CTS (CtsSafetyCenterTestCases
)
A partir de Android 13, las pruebas de CTS se aplican a todos los OEMs que admiten PermissionController
.
Pruebas de archivos de configuración (XmlConfigTest
)
Estas pruebas garantizan lo siguiente:
- El archivo de configuración XML analizado coincide con la configuración que Safety Center analizó y expuso, y que el análisis se realizó correctamente.
- Si la acción de intent
android.settings.PRIVACY_ADVANCED_SETTINGS
está presente en el archivo en formato XML, se debe resolver esta acción. - Si la acción de intent
android.settings.PRIVACY_CONTROLS
está presente en el archivo XML, esta acción debe resolverse.
Pruebas de la IU (SafetyCenterActivityTest
)
Estas pruebas garantizan lo siguiente:
- La acción de intent
android.intent.action.SAFETY_CENTER
resuelve y abre la pantalla de configuración de Seguridad y privacidad cuando el Centro de seguridad está habilitado y la pantalla de Configuración cuando el Centro de seguridad está inhabilitado.
Pruebas de API (SafetyCenterManagerTest
)
El objetivo de las pruebas de la API de SafetyCenterManagerTest es garantizar que las APIs de Safety Center funcionen según lo previsto.
Estas pruebas garantizan lo siguiente:
- La marca
DeviceConfig
asociada controlaSafetyCenterManager.isSafetyCenterEnabled
. - Cuando se inhabilita, las APIs del Centro de seguridad no funcionan.
- Las APIs de Safety Center solo se pueden usar cuando se tienen los permisos asociados.
- Los datos solo se pueden proporcionar a Safety Center de acuerdo con la configuración subyacente.
- Cuando se proporcionan datos a Safety Center, estos se muestran según corresponda.
- Las APIs coinciden con las especificaciones que se describen en Cómo usar las APIs de fuente de Safety Center, por ejemplo, el comportamiento de actualización o restablecimiento del análisis, la configuración o eliminación de datos, y el informe de errores.
- Las APIs internas expuestas a la IU funcionan correctamente. Por ejemplo, Safety Center combina los datos de forma adecuada y se pueden actualizar.
Prueba no admitida de Safety Center (SafetyCenterUnsupportedTest
)
Esta prueba garantiza que el Centro de seguridad esté inhabilitado cuando el dispositivo no lo admita cuando la compatibilidad esté inhabilitada en el archivo de configuración XML del framework.
Si el dispositivo es compatible con Safety Center, no se ejecutará esta prueba. Si el dispositivo no es compatible con Safety Center, solo se ejecutarán esta prueba y las pruebas de clases de datos.
Esta prueba garantiza lo siguiente:
- La acción de intent
android.intent.action.SAFETY_CENTER
abre la pantalla Configuración. SafetyCenterManager.isSafetyCenterEnabled
muestrafalse
.- La mayoría de las APIs de Safety Center no responden cuando se las llama.
Pruebas de clases de datos (SafetySourceDataTest
, SafetySourceIssueTest
, etc.)
Las pruebas de clases de datos, como SafetySourceDataTest
y SafetySourceIssueTest
,
garantizan que las clases de datos que expone Safety Center funcionen según lo previsto,
por ejemplo, SafetySourceData
, SafetySourceIssue
y otras clases internas relacionadas.
Pruebas de MTS (SafetyCenterFunctionalTestCases
y otras)
Estas pruebas se ejecutan en las actualizaciones principales y se aplican a todos los OEMs que admiten PermissionController
. Los requisitos que aplican estas pruebas pueden cambiar en las actualizaciones de la línea principal.
Pruebas de API (SafetyCenterManagerTest
)
Estas pruebas son similares a la prueba SafetyCenterManagerTest
de CTS. Sin embargo, prueban requisitos que podrían cambiar en las actualizaciones de la línea principal, por ejemplo:
- Verificar el contenido real de los datos que devuelven las APIs internas expuestas a la IU
Pruebas de la IU (SafetyCenterActivityTest
, SafetyCenterStatusCardTest
, SafetyCenterQsActivityTest
, etcétera)
Estas pruebas garantizan lo siguiente:
- El redireccionamiento al Centro de seguridad con parámetros específicos funciona según lo previsto, por ejemplo, redirecciona a un problema específico. Consulta Cómo redireccionar a Safety Center.
- La IU muestra el estado de seguridad subyacente correcto.
- La IU permite navegar a pantallas separadas.
- La IU permite resolver problemas de seguridad directamente desde la pantalla del Centro de seguridad cuando
SafetySourceIssue
lo especifica. - La IU contrae varias tarjetas de advertencia en un elemento y permite expandirlas nuevamente en varias tarjetas de advertencia.
- Los datos se actualizan cuando se abre la página de Safety Center para las fuentes relevantes de Safety Center.
- El botón para volver a analizar solo aparece en circunstancias específicas.
- Si presionas el botón para volver a analizar, se recuperarán datos nuevos.
Se realizan pruebas similares para Safety Center. Consulta Cómo crear tarjetas de Configuración rápida personalizadas para tu app.
Casos extremos adicionales, como estados de error y estados pendientes
Pruebas de varios usuarios (SafetyCenterMultiUsersTest
)
El objetivo de estas pruebas es garantizar que la API funcione correctamente cuando se proporcionan datos para varios usuarios o perfiles. Consulta Cómo proporcionar datos para varios usuarios y perfiles. Esta configuración se logra con una biblioteca interna que facilita la configuración de usuarios y perfiles separados en el dispositivo con Bedstead.
Esta prueba garantiza lo siguiente:
- Los datos que pertenecen a un usuario se combinan con su perfil administrado asociado, si existe.
- Solo las fuentes marcadas con
profile="all_profiles"
pueden proporcionar datos en el perfil administrado del usuario. - Se crea una entrada nueva para cada perfil administrado asociado a un usuario.
- Los datos que pertenecen a un usuario no se filtran a otro usuario no relacionado.