En Android 6.0 y versiones posteriores, el modelo de permisos de las apps para Android los permisos sean más comprensibles, útiles y seguros para los usuarios. El modelo movió Android que requieren permisos riesgosos (consulta permisos afectados) de un del modelo de permisos en el momento de la 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 la actualizan. Dispositivo los fabricantes y operadores pueden preinstalar apps con permisos preotorgados sin notificar al usuario.
- Permisos de tiempo de ejecución
(Android 6.0 a 9) Los usuarios otorgan permisos riesgosos a una app cuando esta se está ejecutando. Cuando se solicitan permisos (como cuando se inicia la app o cuando el usuario accede a un esta función) depende de la app, pero el usuario otorga o rechaza el acceso de la app a grupos de permisos. Los OEM o proveedores pueden preinstalar las apps, pero no pueden otorgar previamente permisos a menos que pasarán por el proceso de excepción. (Consulta Creación excepciones).
(Android 10) Los usuarios notan una mayor transparencia. controle qué aplicaciones tienen permisos de tiempo de ejecución para el reconocimiento de actividad (RA). A los usuarios les interesa el en el diálogo de permisos de tiempo de ejecución para permitir, permitir durante el uso o denegar los permisos siempre. En una actualización del SO a Android 10, se conservan los permisos otorgados a las apps, pero los usuarios pueden ir a Configuración y cambiarlas.
Los permisos de tiempo de ejecución impiden que las apps accedan a datos privados sin el consentimiento del usuario. y proporcionarles contexto y visibilidad adicionales de los tipos de permisos que de contenido que buscan o que se les otorgaron. El modelo de entorno de ejecución alienta a los desarrolladores a ayudan a los usuarios a entender por qué las apps requieren los permisos solicitados para que los usuarios puedan tomar mejores decisiones sobre conceder o denegar estos permisos.
Permisos afectados
Android 6.0 y las versiones posteriores requieren permisos riesgosos para usar un modelo de permisos de tiempo de ejecución.
Los permisos peligrosos son aquellos de mayor riesgo (como READ_CALENDAR) que otorgan
solicitar a las apps acceso a datos privados de los usuarios o controlar un dispositivo, lo que puede afectar negativamente
afectar al usuario. Para ver una lista de permisos riesgosos, ejecuta el siguiente comando:
adb shell pm list permissions -g -d
Android 6.0 y las versiones posteriores no cambian el comportamiento normal
permisos. Todos estos son permisos no peligrosos, incluidos los normales,
sistemas y permisos de firma. Los permisos normales son permisos de menor riesgo (como
SET_WALLPAPER) que otorgan a las apps que solicitan acceso a elementos aislados 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
en versiones anteriores, el sistema otorga automáticamente permisos normales a la app solicitante en
instalación y no solicita la aprobación del usuario. Para obtener detalles sobre los permisos, consulta la declaración <permission>
element.
Restricciones estrictas y no estrictas en Android 10
Además de ser peligroso, un permiso puede tener restricciones o de restricciones no definitivas. En cualquier caso, el permiso restringido también debe incluirse en la lista de entidades permitidas. No incluido en la lista de entidades permitidas las restricciones estrictas se comportan de manera diferente a las de software restricciones:
- (Restricciones estrictas) A las apps a las que se les pueden otorgar permisos que no incluido en la lista de entidades permitidas.
- (Restricciones suaves) Las apps sin lista de entidades permitidas se comportan según las el permiso específico que soliciten. El comportamiento se describe en el documentación del permiso solicitado.
Cuando instalas una app, el instalador (como Google Play Store) puede seleccionar no incluir en la lista de entidades permitidas los permisos restringidos de la app Los permisos son restringidas por la plataforma y se pueden otorgar solo si una aplicación cumple con según la política de la plataforma. Algunos ejemplos de tipos de permisos con restricción estricta incluyen los SMS y Registro de llamadas.
La inclusión en la lista de entidades permitidas ocurre durante la instalación y cuando
- ya hay una app instalada durante la actualización de Android de 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 incluir permiso.
- el instalador (como Google Play Store) marca el permiso como incluido en la lista de entidades permitidas.
Los usuarios no pueden incluir permisos de forma manual en la lista de entidades permitidas.
Requisitos
El modelo de permisos de tiempo de ejecución se aplica a todas las apps, incluidas las preinstaladas y las ya instaladas. que se entregan al dispositivo como parte del proceso de configuración. Entre los requisitos de software para apps, se incluyen los siguientes:
- El modelo de permisos de tiempo de ejecución debe ser el mismo 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 solicitar a los usuarios que otorguen permisos durante el tiempo de ejecución. Para obtener más detalles, consulta Actualización
apps. Se pueden otorgar excepciones limitadas a controladores y apps predeterminados.
que proporcionan una funcionalidad básica del dispositivo que es fundamental para su funcionamiento esperado.
(Por ejemplo, la app de Teléfono predeterminada del dispositivo para controlar
ACTION_CALLpodría tener acceso al permiso del teléfono). Para obtener más detalles, consulta Crea excepciones. - Apps precargadas que tienen permisos peligrosos debe 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 aplicación, no debe desviarse de la implementación de AOSP de PermissionController, los usuarios pueden revocar permisos peligrosos de apps preinstaladas, por lo que .
- Las aplicaciones sin interfaz gráfica deben usar una actividad para solicitar permisos o compartir una UID con otra app que tenga los permisos necesarios. Para obtener más información, consulta Apps sin interfaz gráfica.
Migración de permisos
Los permisos otorgados a las apps en Android 5.x permanecen vigentes después de la actualización a Android 6.0 o versiones posteriores, pero los usuarios pueden revocar esos permisos en cualquier momento.
En una actualización de Android de 9 a 10, se obtienen incluido en la lista de entidades permitidas. Para obtener detalles sobre la implementación de permisos divididos en primer y segundo plano, consulta Cambio de privacidad en Android 10 y comienza con Solicitar segundo plano. ubicación.
Integración
Al integrar 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 modelo nuevo También puedes definir excepciones para las apps
que son los controladores o proveedores predeterminados para la funcionalidad principal, definen permisos personalizados y
personaliza el tema que se usa en la app de PermissionController.
Cómo actualizar apps
Las apps en la imagen del sistema y las preinstaladas no se otorgan automáticamente de forma previa. permisos. Te recomendamos trabajar con desarrolladores de apps preinstalados (OEM, operadores de terceros) para realizar las modificaciones necesarias de la aplicación con el comando developer lineamientos. Específicamente, debes asegurarte de que las apps preinstaladas se modifiquen para evitar fallas y otros problemas cuando los usuarios revocan 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 del AOSP de Android 6.0 o versiones posteriores. Por ejemplo, el flujo de la IU
durante la instalación de una aplicación no deben desviarse de la implementación de AOSP de
PermissionController Los usuarios incluso pueden revocar los permisos peligrosos de
y apps preinstaladas.
En Android 6.0 a 9, algunos permisos se otorgan durante el flujo de instalación. Sin embargo, a partir de
En 10, el flujo de instalación (que realiza la app de Package
Installer) es una función independiente de la concesión de permisos (en el
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 interfaz gráfica pueden solicitar permisos cuando instalados o si estaban preinstalados sin el uso de una actividad.
- En En Android 6.0 y versiones posteriores, las apps sin interfaz gráfica deben usar uno de los siguientes métodos para solicitar permisos:
- Agrega una actividad para solicitar permisos. (Este es el método preferido).
- Comparte un UID con otra app que tenga los permisos necesarios. Usar esta solo cuando necesitas que la plataforma controle varios APK como un solo .
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 permisos. Para ello, haz lo siguiente:
actualizar 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 apps,
no puedes personalizar la ubicación, la posición ni las reglas
Aparece la IU.
Si deseas incluir strings para idiomas adicionales, agrega el cadenas al AOSP.
Crea excepciones
Puedes otorgar previamente permisos a apps que son controladores predeterminados o
para la funcionalidad principal del SO con
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 peligroso y agregar permisos específicos del OEM o proveedor a los permisos existentes como en Android 5.x y versiones anteriores.
En Android 6.0 y versiones posteriores, si agregas un nuevo permiso riesgoso, se debe administrar en de la misma manera que otros permisos peligrosos (solicitados durante el tiempo de ejecución de la app y revocable para los usuarios). Más precisamente:
- Puedes agregar permisos nuevos a un grupo actual, pero no puedes modificar el Asignación AOSP de permisos peligrosos y grupos de permisos peligrosos. (En otras palabras, no puede 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.
Probar permisos
Android incluye pruebas del Conjunto de pruebas de compatibilidad (CTS) que verifican los permisos individuales se asignan a los grupos correctos. Aprobar estas pruebas es un requisito de compatibilidad con CTS para Android 6.0 y versiones posteriores.
Revocar permisos
En Android 13 y versiones posteriores, puedes revocar tus permisos
permisos de tiempo de ejecución con
Context.revokeSelfPermissionsOnKill()
La revocación ocurre de forma asíncrona y se activa cuando es seguro hacerlo sin interrumpir
del usuario. Cuando se activa la revocación, se cierran todos los procesos que se ejecutan en el UID que realiza la llamada.
Es importante comprender que la revocación de un solo permiso puede no estar reflejada en el
de configuración de Terraform, que trata los permisos por grupo. Por lo general, un grupo de permisos se muestra como
siempre y cuando se otorgue al menos uno de los permisos de ese grupo. Si se aseguran de que los usuarios
confirma que la revocación en la configuración es importante para ti, así que asegúrate de revocar
en el 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 el fondo correspondiente permisos si no se otorga ninguno de los permisos correspondientes en primer plano.
La revocación no se activa mientras el proceso permanezca en primer plano, pero
también pueden activarse de inmediato mediante la eliminación manual de todos los procesos que se ejecutan en el UID actual, por
con System.exit().
Sin embargo, se recomienda dejar que el sistema decida cuándo activarla.
Una vez que se revoca un permiso, puedes solicitarlo de nuevo, y el usuario que otorgues o rechaces la solicitud. No es posible solicitar un permiso que tenía que el usuario rechazó anteriormente. Si bien se recomienda que revoques los permisos que se retienen actualmente, pero ya no son necesarias, debes tener cuidado de no informar al usuario acerca de revocación hasta que entre en vigencia.