En Android 6.0 y versiones posteriores, el modelo de permisos de aplicaciones de Android está diseñado para que los permisos sean más comprensibles, útiles y seguros para los usuarios. El modelo movió las aplicaciones de Android que requieren permisos peligrosos (consulte Permisos afectados ) de un modelo de permisos de tiempo de instalación a un modelo de permisos de tiempo de ejecución :
- Permisos de tiempo de instalación
( Android 5.1 y versiones anteriores ) Los usuarios otorgan permisos peligrosos a una aplicación cuando instalan o actualizan la aplicación. Los fabricantes de dispositivos y los operadores pueden preinstalar aplicaciones con permisos otorgados previamente sin notificar al usuario.
- Permisos de tiempo de ejecución
( Android 6.0 – 9 ) Los usuarios otorgan permisos peligrosos a una aplicación cuando la aplicación se está ejecutando. El momento en que se solicitan los permisos (como cuando se inicia la aplicación o cuando el usuario accede a una función específica) depende de la aplicación, pero el usuario otorga o deniega el acceso de la aplicación a grupos de permisos específicos. Los OEM/operadores pueden preinstalar aplicaciones, pero no pueden otorgar permisos a menos que pasen por el proceso de excepción. (Consulte Creación de excepciones ).
( Android 10 ) Los usuarios ven una mayor transparencia y tienen control sobre qué aplicaciones tienen permisos de tiempo de ejecución de reconocimiento de actividad (AR). El cuadro de diálogo de permisos de tiempo de ejecución solicita a los usuarios que permitan siempre, permitan mientras están en uso o nieguen los permisos. En una actualización del sistema operativo a Android 10, los permisos otorgados a las aplicaciones se conservan, pero los usuarios pueden ingresar a Configuración y cambiarlos.
Los permisos de tiempo de ejecución evitan que las aplicaciones obtengan acceso a datos privados sin el consentimiento de un usuario y les brindan contexto adicional y visibilidad sobre los tipos de permisos que las aplicaciones buscan o se les han otorgado. El modelo de tiempo de ejecución alienta a los desarrolladores a ayudar a los usuarios a comprender por qué las aplicaciones requieren los permisos solicitados y proporciona una mayor transparencia para que los usuarios puedan tomar mejores decisiones sobre otorgarlos o denegarlos.
Permisos afectados
Android 6.0 y versiones posteriores requieren permisos peligrosos para usar un modelo de permisos de tiempo de ejecución. Los permisos peligrosos son permisos de mayor riesgo (como READ_CALENDAR ) que otorgan a las aplicaciones solicitantes acceso a datos privados del usuario o control sobre un dispositivo, lo que puede afectar negativamente al usuario. Para ver una lista de permisos peligrosos, ejecute el comando:
adb shell pm list permissions -g -d
Android 6.0 y superior no cambia el comportamiento de los permisos normales . Todos estos son permisos no peligrosos, incluidos los permisos normales, del sistema y de firma. Los permisos normales son permisos de menor riesgo (como SET_WALLPAPER ) que otorgan a las aplicaciones solicitantes acceso a funciones aisladas de nivel de aplicación con un riesgo mínimo para otras aplicaciones, el sistema o el usuario. Al igual que en Android 5.1 y versiones anteriores, el sistema otorga automáticamente permisos normales a una aplicación solicitante durante la instalación y no solicita la aprobación del usuario. Para obtener detalles sobre los permisos, consulte la documentación del elemento <permission> .
Restricciones duras y blandas en Android 10
Además de ser peligroso, un permiso puede tener restricciones estrictas o suaves. En cualquier caso, el permiso restringido también debe incluirse en la lista de permitidos. Las restricciones duras no permitidas se comportan de manera diferente a las restricciones blandas no permitidas:
- ( Restricciones estrictas) No se pueden otorgar permisos a aplicaciones que no estén en la lista de permitidos.
- ( Restricciones blandas ) Las aplicaciones sin lista de permitidos se comportan de acuerdo con el permiso específico que solicitan. El comportamiento se describe en la documentación pública para el permiso solicitado.
Al instalar una aplicación, el instalador (como Google Play Store) puede seleccionar no permitir los permisos restringidos para la aplicación. Los permisos están restringidos por la plataforma y solo se pueden otorgar si una aplicación cumple con los criterios especiales de la política de la plataforma. Ejemplos de tipos de permisos con restricciones estrictas incluyen SMS y permisos de registro de llamadas.
La inclusión en la lista blanca ocurre durante la instalación y cuando
- una aplicación ya está instalada durante una actualización de Android 9 a 10.
- un permiso está preconcedido o una aplicación está preinstalada.
- se requiere un permiso para un rol que ya está definido para incluir el permiso en la lista de permitidos.
- el instalador (como Google Play Store) marca el permiso como permitido.
Los usuarios no pueden incluir manualmente los permisos en la lista de permitidos.
Requisitos
El modelo de permiso de tiempo de ejecución se aplica a todas las aplicaciones, incluidas las aplicaciones preinstaladas y las aplicaciones enviadas al dispositivo como parte del proceso de configuración. Los requisitos del software de aplicación incluyen:
- El modelo de permisos de tiempo de ejecución debe ser coherente en todos los dispositivos con Android 6.0 y versiones posteriores. Esto se aplica mediante las pruebas de Android Compatibility Test Suite (CTS).
- Las aplicaciones deben solicitar a los usuarios que concedan permisos de aplicación en tiempo de ejecución. Para obtener más información, consulte Actualización de aplicaciones . Se pueden otorgar excepciones limitadas a aplicaciones y controladores predeterminados que brindan una funcionalidad básica del dispositivo fundamental para la operación esperada del dispositivo. (Por ejemplo, la aplicación Marcador predeterminada del dispositivo para manejar
ACTION_CALLpuede tener acceso de permiso de Teléfono). Para obtener más información, consulte Creación de excepciones . - Las aplicaciones precargadas que tienen permisos peligrosos deben apuntar al nivel de API 23 y mantener el modelo de permisos de tiempo de ejecución. Es decir, el flujo de la interfaz de usuario durante la instalación de la aplicación no debe desviarse de la implementación AOSP de PermissionController, los usuarios pueden revocar permisos peligrosos de aplicaciones preinstaladas, etc.
- Las aplicaciones sin cabeza deben utilizar una actividad para solicitar permisos o compartir un UID con otra aplicación que tenga los permisos necesarios. Para obtener más información, consulte Aplicaciones sin periféricos .
Migración de permisos
Los permisos otorgados a las aplicaciones en Android 5.x permanecen otorgados después de actualizar a Android 6.0 o superior, pero los usuarios pueden revocar esos permisos en cualquier momento.
En una actualización de Android 9 a 10, todos los permisos restringidos se incluyen en la lista de permitidos. Para obtener detalles sobre la implementación de los permisos de división de primer plano/fondo, consulte Cambio de privacidad de Android 10 , comenzando con Solicitar ubicación en segundo plano .
Integración
Al integrar el modelo de permisos de tiempo de ejecución de aplicaciones para Android 6.0 y versiones posteriores, debe actualizar las aplicaciones preinstaladas para que funcionen con el nuevo modelo. También puede definir excepciones para aplicaciones que son los controladores/proveedores predeterminados para la funcionalidad principal, definir permisos personalizados y personalizar el tema utilizado en la aplicación PermissionController .
Actualización de aplicaciones
Las aplicaciones en la imagen del sistema y las aplicaciones preinstaladas no obtienen permisos automáticamente. Lo alentamos a que trabaje con los desarrolladores de aplicaciones preinstaladas (OEM, operadores y terceros) para realizar las modificaciones necesarias de la aplicación utilizando las pautas para desarrolladores . Específicamente, debe asegurarse de que las aplicaciones preinstaladas se modifiquen para evitar bloqueos y otros problemas cuando los usuarios revocan permisos.
Aplicaciones precargadas
En Android 9 y versiones anteriores, las aplicaciones precargadas que usan permisos peligrosos deben apuntar al nivel de API 23 o superior, y mantener el modelo de permisos AOSP de Android 6.0 y versiones posteriores. Por ejemplo, el flujo de la interfaz de usuario durante la instalación de una aplicación no debe desviarse de la implementación AOSP de PermissionController . Los usuarios pueden incluso revocar los peligrosos permisos de las aplicaciones preinstaladas.
En Android 6.0 a 9, se otorgan algunos permisos durante el flujo de instalación. Sin embargo, a partir de 10, el flujo de instalación (realizado por la aplicación Package Installer ) es una función independiente de la concesión de permisos (en la aplicación Permission Controller ).
Aplicaciones sin cabeza
Solo las actividades pueden solicitar permisos. Los servicios no pueden solicitar permisos directamente.
- En Android 5.1 y versiones anteriores, las aplicaciones autónomas pueden solicitar permisos cuando se instalan o si se instalaron previamente sin el uso de una actividad.
- En Android 6.0 y versiones posteriores, las aplicaciones autónomas deben usar uno de los siguientes métodos para solicitar permisos:
- Agregue una actividad para solicitar permisos. (Este es el método preferido.)
- Comparta un UID con otra aplicación que tenga los permisos necesarios. Use este método solo cuando necesite que la plataforma maneje múltiples APK como una sola aplicación.
El objetivo es evitar confundir a los usuarios con solicitudes de permiso que aparecen fuera de contexto.
Personalización de la interfaz de usuario de PackageInstaller
Si lo desea, puede personalizar el tema de la interfaz de usuario de permisos actualizando los temas predeterminados del dispositivo ( Theme.DeviceDefault.Settings y Theme.DeviceDefault.Light.Dialog.NoActionBar ) utilizados por PackageInstaller. Sin embargo, debido a que la coherencia es fundamental para los desarrolladores de aplicaciones, no puede personalizar la ubicación, la posición y las reglas de cuándo aparece la interfaz de usuario de Permisos.
Para incluir cadenas para idiomas adicionales, aporte las cadenas a AOSP.
Creando excepciones
Puede otorgar permisos previamente a las aplicaciones que son controladores o proveedores predeterminados para la funcionalidad central del sistema operativo utilizando la clase DefaultPermissionGrantPolicy.java en PackageManager. Ejemplos:
ACTION_CALL (Dialer) Default Phone, Contacts, SMS, Microphone
SMS_DELIVER_ACTION (SMS/MMS) Default Phone, Contacts, SMS
Definición de permisos personalizados
Puede definir permisos y grupos personalizados como normales o peligrosos y agregar permisos específicos de OEM/operadores a los grupos de permisos existentes, tal como podía hacerlo en Android 5.x y versiones anteriores.
En Android 6.0 y versiones posteriores, si agrega un nuevo permiso peligroso, debe manejarse de la misma manera que otros permisos peligrosos (solicitados durante el tiempo de ejecución de la aplicación y revocables por los usuarios). Específicamente:
- Puede agregar nuevos permisos a un grupo actual, pero no puede modificar la asignación AOSP de permisos peligrosos y grupos de permisos peligrosos. (En otras palabras, no puede eliminar un permiso de un grupo y asignarlo a otro grupo).
- Puede agregar nuevos grupos de permisos en las aplicaciones instaladas en el dispositivo, pero no puede agregar nuevos grupos de permisos en el manifiesto de la plataforma.
Permisos de prueba
Android incluye pruebas de Compatibility Test Suite (CTS) que verifican que los permisos individuales estén asignados a los grupos correctos. Pasar estas pruebas es un requisito para la compatibilidad con Android 6.0 y versiones posteriores de CTS.