En Android 6.0 y versiones posteriores, el modelo de permisos de apps de Android está diseñado para que los permisos sean más comprensibles, útiles y seguros para los usuarios. El modelo trasladó las apps para Android que requieren permisos peligrosos (consulta Permisos afectados) de un modelo de permisos de instalación a un modelo de permisos de tiempo de ejecución:
- Permisos en el momento de la instalación
(Android 5.1 y versiones anteriores) Los usuarios otorgan permisos peligrosos a una app cuando la instalan o actualizan. Los fabricantes y operadores de dispositivos pueden preinstalar apps con permisos otorgados de antemano sin notificar al usuario.
- Permisos de tiempo de ejecución
(Android 6.0 a 9) Los usuarios otorgan permisos peligrosos a una app cuando esta se está ejecutando. El momento en que se solicitan los permisos (por ejemplo, cuando se inicia la app o cuando el usuario accede a una función específica) depende de la app, pero el usuario otorga o niega el acceso de la app a grupos de permisos específicos. Los OEM o operadores pueden preinstalar apps, pero no pueden otorgar permisos por adelantado, a menos que realicen el proceso de excepción. (consulta Cómo crear excepciones).
(Android 10) Los usuarios ven una mayor transparencia y tienen control sobre qué apps tienen permisos de tiempo de ejecución de reconocimiento de actividades (AR). El diálogo de permisos de tiempo de ejecución les solicita a los usuarios que siempre permitan los permisos, que los permitan mientras se usan o que los rechacen. Cuando se actualiza el SO a Android 10, se conservan los permisos otorgados a las apps, pero los usuarios pueden ir a Configuración y cambiarlos.
Los permisos de tiempo de ejecución evitan que las apps obtengan acceso a datos privados sin el consentimiento del usuario y les proporcionan contexto y visibilidad adicionales sobre los tipos de permisos que las apps solicitan o se les otorgaron. El modelo de tiempo de ejecución alienta a los desarrolladores a ayudar a los usuarios a comprender por qué las apps requieren los permisos solicitados y proporciona una mayor transparencia para que los usuarios puedan tomar mejores decisiones sobre si otorgarlos o rechazarlos.
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 apps 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, ejecuta el siguiente comando:
adb shell pm list permissions -g -d
Android 6.0 y versiones posteriores no cambian 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 apps solicitantes acceso a funciones aisladas a nivel de la app con un riesgo mínimo para otras apps, el sistema o el usuario. Al igual que en Android 5.1 y versiones anteriores, el sistema otorga automáticamente permisos normales a una app solicitante durante la instalación y no le solicita aprobación al usuario. Para obtener detalles sobre los permisos, consulta la documentación del elemento<permission>.
Restricciones estrictas y flexibles en Android 10
Además de ser peligroso, un permiso puede tener una restricción estricta o una restricción flexible. En cualquier caso, el permiso restringido también debe estar en la lista de entidades permitidas. Las restricciones estrictas que no están en la lista de entidades permitidas se comportan de manera diferente a las restricciones flexibles que no están en la lista de entidades permitidas:
- (restricciones estrictas) No se pueden otorgar permisos a las apps que no están en la lista de entidades permitidas.
- (Restricciones flexibles) Las apps sin listas de entidades permitidas se comportan según el permiso específico que solicitan. El comportamiento se describe en la documentación pública del permiso solicitado.
Cuando se instala una app, el instalador (como Google Play Store) puede seleccionar no incluir en la lista de entidades permitidas los permisos restringidos de la app. La plataforma restringe los permisos y solo se pueden otorgar si una app cumple con criterios especiales según la política de la plataforma. Algunos ejemplos de tipos de permisos con restricciones estrictas son los permisos de SMS y Registro de llamadas.
La lista de entidades permitidas se realiza durante la instalación y cuando
- ya se instaló una app durante una actualización de Android 9 a 10.
- Se otorga un permiso de forma previa o se preinstala una app.
- Se requiere un permiso para un rol que ya está definido para incluirlo en la lista de entidades permitidas.
- El instalador (como Google Play Store) marca el permiso como permitido.
Los usuarios no pueden incluir permisos en la lista de entidades permitidas de forma manual.
Requisitos
El modelo de permisos del entorno de ejecución se aplica a todas las apps, incluidas las preinstaladas y las que se entregan al dispositivo como parte del proceso de configuración. Entre los requisitos de software de la app, se incluyen los siguientes:
- El modelo de permisos de tiempo de ejecución debe ser coherente en todos los dispositivos que ejecutan Android 6.0 y versiones posteriores. Esto se aplica mediante las pruebas del conjunto de pruebas de compatibilidad (CTS) de Android.
- Las apps deben solicitarles a los usuarios que otorguen permisos durante el tiempo de ejecución. Para obtener más información, consulta Cómo actualizar apps. Se pueden otorgar excepciones limitadas a las apps y los controladores predeterminados que proporcionan funciones básicas del dispositivo fundamentales para el funcionamiento esperado del dispositivo.
(por ejemplo, la app de Teléfono predeterminada del dispositivo para controlar
ACTION_CALLpuede tener acceso al permiso de Teléfono). Para obtener más información, consulta Cómo crear excepciones. - Las apps precargadas que tienen permisos peligrosos deben orientarse al nivel de API 23 y mantener el modelo de permisos de tiempo de ejecución. Es decir, el flujo de la IU durante la instalación de la app no debe desviarse de la implementación de PermissionController de AOSP, los usuarios pueden revocar permisos peligrosos de apps preinstaladas, etcétera.
- Las apps sin cabezal deben usar una actividad para solicitar permisos o compartir un UID con otra app que tenga los permisos necesarios. Para obtener más información, consulta Apps sin interfaz.
Migración de permisos
Los permisos otorgados a las apps en Android 5.x se mantienen después de actualizar a Android 6.0 o versiones posteriores, pero los usuarios pueden revocarlos en cualquier momento.
En una actualización de Android 9 a 10, todos los permisos con restricciones duras se incluyen en la lista de entidades permitidas. Para obtener detalles sobre la implementación de los permisos de división en primer y segundo plano, consulta el Cambio de privacidad de Android 10, que comienza con Cómo solicitar la ubicación en segundo plano.
Integración
Cuando integres el modelo de permisos de tiempo de ejecución de la app para Android 6.0 y versiones posteriores, debes actualizar las apps preinstaladas para que funcionen con el nuevo modelo. También puedes definir excepciones para las apps que son los controladores o proveedores predeterminados de la funcionalidad principal, definir permisos personalizados y personalizar el tema que se usa en la app de PermissionController.
Cómo actualizar apps
Las apps de la imagen del sistema y las preinstaladas no reciben permisos preotorgados automáticamente. Te recomendamos que trabajes con desarrolladores de apps preinstaladas (OEM, operador y terceros) para realizar las modificaciones necesarias en la app según los lineamientos para desarrolladores. Específicamente, debes asegurarte de que las apps preinstaladas se modifiquen para evitar fallas y otros problemas cuando los usuarios revoquen permisos.
Apps precargadas
En Android 9 y versiones anteriores, las apps precargadas que usan permisos peligrosos deben orientarse al nivel de API 23 o versiones posteriores, y mantener el modelo de permisos de AOSP de Android 6.0 y versiones posteriores. Por ejemplo, el flujo de la IU durante la instalación de una app no debe desviarse de la implementación de AOSP de PermissionController. Los usuarios incluso pueden revocar los permisos peligrosos de las apps preinstaladas.
En Android 6.0 a 9, se otorgan algunos permisos durante el flujo de instalación. Sin embargo, a partir de Android 10, el flujo de instalación (que realiza la app Package
Installer) es una función independiente de la concesión de permisos (en la app Permission Controller).
Apps sin interfaz gráfica
Solo las actividades pueden solicitar permisos. Los servicios no pueden solicitar permisos directamente.
- En Android 5.1 y versiones anteriores, las apps sin cabeza pueden solicitar permisos cuando se instalan o si se preinstalaron sin usar una actividad.
- En Android 6.0 y versiones posteriores, las apps sin cabeza deben usar uno de los siguientes métodos para solicitar permisos:
- Agrega una actividad para solicitar permisos. (Este es el método preferido).
- Compartir un UID con otra app que tenga los permisos necesarios Usa este método solo cuando necesites que la plataforma controle varios APKs como una sola app.
El objetivo es evitar confundir a los usuarios con solicitudes de permisos que aparecen fuera de contexto.
Cómo personalizar la IU de PackageInstaller
Si lo deseas, puedes personalizar el tema de la IU de Permissions actualizando los temas predeterminados del dispositivo (Theme.DeviceDefault.Settings y Theme.DeviceDefault.Light.Dialog.NoActionBar) que usa PackageInstaller. Sin embargo, como la coherencia es fundamental para los desarrolladores de apps,
no puedes personalizar la ubicación, la posición ni las reglas de cuándo aparece la IU de permisos.
Para incluir cadenas para idiomas adicionales, envía las cadenas a AOSP.
Cómo crear excepciones
Puedes otorgar permisos por adelantado a las apps que son controladores o proveedores predeterminados para la funcionalidad principal del SO con la clase DefaultPermissionGrantPolicy.java en PackageManager. Ejemplos:
ACTION_CALL (Dialer) Default Phone, Contacts, SMS, Microphone
SMS_DELIVER_ACTION (SMS/MMS) Default Phone, Contacts, SMS
Cómo definir permisos personalizados
Puedes definir permisos y grupos personalizados como normales o peligrosos, y agregar permisos específicos del OEM o operador a los grupos de permisos existentes, tal como lo hacías en Android 5.x y versiones anteriores.
En Android 6.0 y versiones posteriores, si agregas un nuevo permiso riesgoso, se debe controlar de la misma manera que otros permisos riesgosos (se solicita durante el tiempo de ejecución de la app y los usuarios pueden revocarlo). Más precisamente:
- Puedes agregar permisos nuevos a un grupo actual, pero no puedes modificar la asignación de AOSP de permisos peligrosos y grupos de permisos peligrosos. (en otras palabras, no puedes quitar un permiso de un grupo y asignarlo a otro).
- Puedes agregar grupos de permisos nuevos en las apps instaladas en el dispositivo, pero no puedes agregar grupos de permisos nuevos en el manifiesto de la plataforma.
Prueba los permisos
Android incluye pruebas del Conjunto de pruebas de compatibilidad (CTS) que verifican que los permisos individuales se asignen a los grupos correctos. Pasar estas pruebas es un requisito para la compatibilidad con CTS de Android 6.0 y versiones posteriores.
Cómo revocar permisos
En Android 13 y versiones posteriores, puedes revocar tus propios permisos de tiempo de ejecución otorgados con Context.revokeSelfPermissionsOnKill().
La revocación se realiza de forma asíncrona y se activa cuando es seguro hacerlo sin interrumpir al usuario. Cuando se activa la revocación, se finalizan todos los procesos que se ejecutan en el UID de llamada.
Es importante comprender que la revocación de un solo permiso puede no reflejarse en la IU de configuración, que trata los permisos por grupo. Por lo general, un grupo de permisos se muestra como otorgado, siempre que se otorgue al menos uno de los permisos de ese grupo. Si es importante para ti garantizar que los usuarios puedan confirmar la revocación en la configuración, asegúrate de revocar todos los permisos del grupo de permisos. Para saber qué permisos pertenecen a un grupo determinado, puedes usar PackageManager.getGroupOfPlatformPermission y PackageManager.getPlatformPermissionsForGroup.
Cuando el sistema revoca los permisos solicitados, también revoca los permisos en segundo plano correspondientes si aún no se otorga ninguno de sus permisos en primer plano correspondientes.
La revocación no se activa mientras el proceso permanezca en primer plano, pero también se puede activar de inmediato si se finalizan manualmente todos los procesos que se ejecutan en el UID actual, por ejemplo, con System.exit().
Sin embargo, se recomienda permitir que el sistema decida cuándo activarlo.
Una vez que se aplica una revocación de permiso, puedes volver a solicitarlo, y se le solicita al usuario que otorgue o rechace la solicitud. No es posible solicitar un permiso que el usuario rechazó anteriormente. Si bien te recomendamos que revoques los permisos que tienes actualmente, pero que ya no son necesarios, debes tener cuidado de no informar al usuario sobre la revocación hasta que esté vigente.