Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

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 movió las aplicaciones de Android que requieren permisos peligrosos (consulte Permisos afectados ) de un modelo de permiso en tiempo de instalación a un modelo de permiso 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 y operadores de dispositivos pueden preinstalar aplicaciones con permisos preconcedidos 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. 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 / 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 siempre permitan, permitan mientras están en uso o deniegan permisos. En una actualización del sistema operativo a Android 10, los permisos otorgados a las aplicaciones se conservan, pero los usuarios pueden ir a 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 anima 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 concederlos o denegarlos.

Permisos afectados

Android 6.0 y superior requiere permisos peligrosos para usar un modelo de permisos en 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 de nivel de aplicación aisladas 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 que lo solicita en 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 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 estrictas) No se pueden otorgar permisos a las aplicaciones que no están en la lista blanca.
  • ( Restricciones suaves ) Las aplicaciones sin listas blancas 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 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. Entre los ejemplos de tipos de permisos restringidos se 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 que se entregan 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 las aplicaciones en tiempo de ejecución. Para obtener más detalles, 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_CALL puede tener acceso con permiso de teléfono). Para obtener más detalles, 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 de 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 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 blanca. Para obtener detalles sobre la implementación de los permisos divididos en primer plano / 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 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 las aplicaciones que son los controladores / proveedores predeterminados para la funcionalidad principal, definir permisos personalizados y personalizar el tema utilizado en la aplicación PermissionController .

Actualizar aplicaciones

Las aplicaciones en la imagen del sistema y las aplicaciones preinstaladas no tienen permisos pregrabados automáticamente. Le recomendamos que trabaje con los desarrolladores de aplicaciones preinstaladas (OEM, operador 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 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 la IU 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

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 versiones posteriores, las aplicaciones 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.)
    • Comparta 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 única 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 de la IU de permisos actualizando los temas predeterminados del dispositivo ( Theme.DeviceDefault.Settings y Theme.DeviceDefault.Light.Dialog.NoActionBar ) que usa 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, contribuya con las cadenas a AOSP.

Creando excepciones

Puede otorgar permisos previamente a las aplicaciones que son controladores o proveedores predeterminados para la funcionalidad principal del sistema operativo mediante 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 grupos de permisos existentes, tal como lo haría en Android 5.xy 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 de 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.