En Android 6.0 y versiones posteriores, el modelo de permisos de aplicaciones de Android está diseñado para hacer que los permisos sean más comprensibles, útiles y seguros para los usuarios. El modelo movió aplicaciones de Android que requieren permisos peligrosos (consulte Permisos afectados ) de un modelo de permisos en tiempo de instalación a un modelo de permisos en 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 la instalan o actualizan. Los fabricantes de dispositivos y los operadores pueden preinstalar aplicaciones con permisos previamente concedidos sin notificar al usuario.
- Permisos de tiempo de ejecución
( Android 6.0 – 9 ) Los usuarios otorgan permisos peligrosos a una aplicación cuando se está ejecutando. Cuando se solicitan 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/niega el acceso a la aplicación a grupos de permisos específicos. Los OEM/operadores pueden preinstalar aplicaciones, pero no pueden otorgar permisos previamente 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 los permitan siempre, los permitan mientras están en uso o los denieguen. En una actualización del sistema operativo a Android 10, los permisos otorgados a las aplicaciones se conservan, pero los usuarios pueden acceder a Configuración y cambiarlos.
Los permisos de tiempo de ejecución impiden que las aplicaciones obtengan acceso a datos privados sin el consentimiento del usuario y les brindan contexto adicional y visibilidad de 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 mayor transparencia para que los usuarios puedan tomar mejores decisiones sobre concederlos o denegarlos.
Permisos afectados
Android 6.0 y versiones posteriores requieren permisos peligrosos para utilizar 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 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 aplicaciones solicitantes acceso a funciones aisladas a 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 inferiores, el sistema otorga automáticamente permisos normales a una aplicación que lo solicita 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 suaves en Android 10
Además de ser peligroso, un permiso puede tener restricciones estrictas o leves. En cualquier caso, el permiso restringido también debe estar incluido en la lista de permitidos. Las restricciones estrictas no permitidas se comportan de manera diferente a las restricciones suaves no permitidas:
- ( Restricciones estrictas ) No se pueden otorgar permisos a las aplicaciones que no estén incluidas en la lista de permitidos.
- ( Restricciones suaves ) Las aplicaciones sin lista blanca se comportan de acuerdo con el permiso específico que solicitan. El comportamiento se describe en la documentación pública del permiso solicitado.
Al instalar una aplicación, el instalador (como Google Play Store) puede seleccionar no incluir en la lista 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 criterios especiales según la política de la plataforma. Ejemplos de tipos de permisos estrictamente restringidos incluyen permisos de SMS y registro de llamadas.
La lista de permitidos ocurre durante la instalación y cuando
- Ya hay una aplicación instalada durante una actualización de Android 9 a 10.
- se concede previamente un permiso o se preinstala una aplicación.
- 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 permisos de tiempo de ejecución se aplica a todas las aplicaciones, incluidas las aplicaciones preinstaladas y las aplicaciones entregadas 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 que ejecutan Android 6.0 y versiones posteriores. Esto se aplica mediante las pruebas del conjunto de pruebas de compatibilidad de Android (CTS).
- Las aplicaciones deben solicitar a los usuarios que otorguen permisos a la 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 el funcionamiento esperado del dispositivo. (Por ejemplo, la aplicación Marcador predeterminada del dispositivo para manejar
ACTION_CALLpuede tener acceso con permiso de teléfono). Para obtener más información, consulte Creación de excepciones . - Las aplicaciones precargadas que tienen permisos peligrosos deben tener como objetivo el 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 headless 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 cabeza .
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 cómo implementar los permisos divididos en primer plano y en segundo plano, 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 .
Actualizando aplicaciones
A las aplicaciones en la imagen del sistema y a las aplicaciones preinstaladas no se les otorgan permisos automáticamente. Le recomendamos que trabaje con los desarrolladores de aplicaciones preinstaladas (OEM, operadores y terceros) para realizar las modificaciones necesarias en las aplicaciones siguiendo las pautas para desarrolladores . Específicamente, debe asegurarse de que las aplicaciones preinstaladas se modifiquen para evitar fallas y otros problemas cuando los usuarios revocan permisos.
Aplicaciones precargadas
En Android 9 y versiones anteriores, las aplicaciones precargadas que utilizan permisos peligrosos deben tener como objetivo el nivel API 23 o superior y mantener el modelo de permisos AOSP de Android 6.0 y superior. 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 separada de la concesión de permisos (en la aplicación Permission Controller ).
Aplicaciones sin cabeza
Sólo las actividades pueden solicitar permisos. Los servicios no pueden solicitar permisos directamente.
- En Android 5.1 y versiones anteriores, las aplicaciones sin cabeza pueden solicitar permisos cuando se instalan o si se preinstalaron sin el uso de una actividad.
- En Android 6.0 y versiones posteriores, las aplicaciones sin cabeza deben utilizar uno de los siguientes métodos para solicitar permisos:
- Agregue una actividad para solicitar permisos. (Este es el método preferido.)
- Comparte un UID con otra aplicación que tenga los permisos necesarios. Utilice este método solo cuando necesite que la plataforma maneje varios APK como una sola aplicación.
El objetivo es evitar confundir a los usuarios con solicitudes de permiso que parecen 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, contribuya con las cadenas a AOSP.
Creando excepciones
Puede conceder previamente permisos a aplicaciones que son controladores o proveedores predeterminados para la funcionalidad principal 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/operador a los grupos de permisos existentes, tal como lo haría 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.
Revocar permisos
En Android 13 y versiones posteriores, puedes revocar tus propios permisos de tiempo de ejecución otorgados usando Context.revokeSelfPermissionsOnKill() . La revocación se produce de forma asincrónica y se activa cuando es seguro hacerlo sin interrumpir al usuario. Cuando se activa la revocación, se eliminarán todos los procesos que se ejecutan en el UID que llama.
Es importante comprender que la revocación de un único permiso puede no reflejarse en la interfaz de usuario de configuración, que trata los permisos por grupo. Normalmente, un grupo de permisos se mostrará como concedido siempre que al menos uno de los permisos de ese grupo esté concedido. Si es importante para usted asegurarse de que los usuarios puedan confirmar la revocación en la configuración, asegúrese de revocar todos los permisos en el grupo de permisos. Para saber qué permisos pertenecen a un determinado grupo, puede utilizar 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 concede ninguno de los permisos en primer plano correspondientes.
La revocación no se activará mientras el proceso permanezca en primer plano, pero también se puede activar de inmediato eliminando manualmente todos los procesos que se ejecutan en el uid actual, por ejemplo usando System.exit() . Sin embargo, se recomienda dejar que el sistema decida cuándo activarlo.
Una vez que la revocación de un permiso entre en vigor, podrá solicitarlo nuevamente y se le pedirá al usuario que conceda o rechace la solicitud. No es posible solicitar un permiso que haya sido previamente denegado por el usuario. Si bien se le recomienda revocar los permisos que posee actualmente pero que ya no necesita, debe tener cuidado de no informar al usuario sobre la revocación hasta que entre en vigor.