Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Permisos en tiempo de ejecución

En Android 6.0 y superior, 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 se trasladó aplicaciones Android que requieren permisos peligrosos (ver permisos afectados ) de un modelo de permiso de instalación a tiempo a un modelo de permisos de ejecución:

  • Permisos de tiempo de instalación

    (Android 5.1) e inferior el usuario otorga permisos peligrosos a una aplicación cuando instalar o actualizar la aplicación. Los fabricantes y operadores de dispositivos pueden preinstalar aplicaciones con permisos preconcedidos sin notificar al usuario.

  • Permisos en tiempo de ejecución

    (Android 6.0 - 9) el usuario otorga permisos peligrosos a una aplicación cuando la aplicación 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 concede / niega 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. (Véase Creación de excepciones .)

    (10) Android Los usuarios ven una mayor transparencia y tener control sobre qué aplicaciones tienen el reconocimiento de la actividad (AR) permisos de ejecución. Usuarios se les pide por los permisos de ejecución de diálogo para permitir que sea siempre, permiten mientras está en uso, o niegan permisos. En una actualización del sistema operativo a Android 10, los permisos otorgados a aplicaciones se conservan, pero los usuarios pueden entrar en Configuración y cambiarlos.

Los permisos de tiempo de ejecución evitan que las aplicaciones obtengan acceso a datos privados sin el consentimiento del usuario y les brindan un 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 en tiempo de ejecución. Permisos peligrosos son los permisos de alto riesgo (como READ_CALENDAR ) que otorgan solicita el acceso a aplicaciones de datos privados del usuario, o el control de un dispositivo, 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. Permisos normales son permisos de menor riesgo (tales como SET_WALLPAPER ) que Grant que solicita el acceso a aplicaciones aislado aplicación de nivel cuenta 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 concede automáticamente los permisos normales a una aplicación que lo solicita durante la instalación y no solicita la aprobación del usuario. Para obtener más información sobre los permisos, consulte la <permiso> elemento de documentación.

Restricciones duras y blandas en Android 10

Además de ser peligroso, un permiso puede tener una restricción estricta o una restricción suave. En cualquier caso, el permiso restringido también debe incluirse en la lista blanca. Las restricciones estrictas no incluidas en la lista blanca se comportan de manera diferente a las restricciones suaves no incluidas en la lista blanca:

  • (Restricciones especialmente graves) Las aplicaciones pueden no tener permisos que no están lista blanca.
  • (Restricciones blandas) Aplicaciones sin listas blancas se comportan de acuerdo con el permiso específico que soliciten. 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 incluir en la lista blanca 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. Algunos ejemplos de tipos de permisos restringidos de forma estricta incluyen los permisos de registro de llamadas y SMS.

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 blanca.
  • el instalador (como Google Play Store) marca el permiso como en la lista blanca.

Los usuarios no pueden incluir permisos manualmente en la lista blanca.

Requisitos

El modelo de permiso 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 permiso 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 de Android Compatibility Test Suite (CTS).
  • Las aplicaciones deben solicitar a los usuarios que otorguen permisos a la aplicación en tiempo de ejecución. Para más detalles, ver las aplicaciones de Actualización . Se pueden otorgar excepciones limitadas a las aplicaciones y controladores predeterminados que brindan la funcionalidad básica del dispositivo fundamental para el funcionamiento esperado del dispositivo. (Por ejemplo, por defecto Marcador de aplicación del dispositivo para el manejo de ACTION_CALL puede tener acceso el permiso del 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 sin cabeza deben usar una actividad para solicitar permisos o compartir un UID con otra aplicación que tenga los permisos necesarios. Para más detalles, ver las 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 blanca. Para más detalles sobre la aplicación de los permisos divididos primer plano / fondo, ver androide 10 cambio privacidad , comenzando con la ubicación Solicitud de fondo .

Integración

Al integrar el modelo de permisos de tiempo de ejecución de la aplicación para Android 6.0 y superior, debe actualizar las aplicaciones preinstaladas para que funcionen con el nuevo modelo. También puede definir excepciones para aplicaciones que son los controladores predeterminados / proveedores para la funcionalidad básica, definir permisos personalizados, y personalizar el tema utilizado en el PermissionController aplicación.

Actualización de aplicaciones

Las aplicaciones en la imagen del sistema y las aplicaciones preinstaladas no tienen permisos pregrabados automáticamente. Le animamos a que el trabajo con los desarrolladores de aplicaciones preinstaladas (OEM, portador, y tercero) para hacer las modificaciones necesarias de aplicaciones utilizando pautas de desarrollo . Específicamente, debe asegurarse de que las aplicaciones preinstaladas se modifiquen para evitar fallas y otros problemas cuando los usuarios revocan los permisos.

Aplicaciones precargadas

En Android 9 y versiones anteriores, las aplicaciones precargadas que usan permisos peligrosos deben tener como objetivo el nivel de API 23 o superior, y mantener el modelo de permisos AOSP de Android 6.0 y superior. Por ejemplo, el flujo de interfaz de usuario durante la instalación de aplicaciones no debe desviarse de la aplicación de AOSP PermissionController . Los usuarios pueden incluso revocar los peligrosos permisos de las aplicaciones preinstaladas.

En Android 6.0 a 9, algunos permisos se otorgan durante el flujo de instalación. Sin embargo, a partir de 10, el flujo de instalar (realizado por el Package Installer app) es una función separada de permisos de concesión (en el Permission Controller app).

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 sin cabeza pueden solicitar permisos cuando se instalan o si se preinstalaron sin el uso de una actividad.
  • En Android 6.0 y superior, las aplicaciones sin cabeza deben utilizar uno de los siguientes métodos para solicitar permisos:
    • Agrega 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 varios APK como una sola aplicación.

El objetivo es evitar confundir a los usuarios con solicitudes de permisos que aparecen fuera de contexto.

Personalización de la interfaz de usuario de PackageInstaller

Si lo desea, puede personalizar el tema Permisos de interfaz de usuario mediante la actualización de los temas del dispositivo por defecto ( 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 IU de permisos.

Para incluir cadenas para idiomas adicionales, contribuir a las cuerdas AOSP.

Creando excepciones

Puede previa a la concesión de permisos a las aplicaciones que se encuentran en controladores predeterminados o proveedores para la funcionalidad del sistema operativo central utilizando el DefaultPermissionGrantPolicy.java clase 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

Se pueden definir permisos y grupos personalizados como normal o peligroso y agregar permisos OEM / Carrier-específicos a grupos de permisos existentes, como ya se podía 5.x en Android 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 quitar 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 CTS con Android 6.0 y versiones posteriores.