La documentación del desarrollador escribe en el nivel de protección "firma":
Un permiso que el sistema otorga solo si la aplicación solicitante está firmada con el mismo certificado que la aplicación que declaró el permiso. Si los certificados coinciden, el sistema otorga automáticamente el permiso sin notificar al usuario ni solicitar su aprobación explícita.
Esto fue como siempre lo supe. Pero parece de alguna manera contradecir lo que escribe la misma documentación sobre WRITE_SETTINGS , que está marcado como "Nivel de protección: firma":
Si la aplicación tiene como objetivo el nivel de API 23 o superior, el usuario de la aplicación debe otorgar explícitamente este permiso a la aplicación a través de una pantalla de administración de permisos.
¿Eso significa que el comportamiento hacia esto ha cambiado con Marshmallow, y una aplicación que no pertenece al sistema que usa una firma diferente aún puede acceder a la funcionalidad cubierta por ella, siempre que el usuario esté de acuerdo? Además, con la nueva "mentalidad" de otorgar automáticamente permisos de un grupo donde el usuario ya tiene otro permiso otorgado: ¿este permiso también se otorga automáticamente entonces (como con todos los permisos del nivel de protección "peligroso"), o es la diferencia aquí? que siempre requiere el acuerdo del usuario, pase lo que pase?
Nota 1: hubo muchos cambios en la forma en que se manejan los permisos en Android 6+. Para no hacer una pregunta "demasiado amplia", he tratado de dividirla; así que para las otras partes, consulte también: Cambios en el sistema de permisos con Android 6.0: ¿Cuáles son las implicaciones para nosotros, los usuarios? y Android 6+ y permisos de cuenta: ¿adónde han ido?
Nota 2: esto definitivamente es relevante para el usuario final, ya que se trata de sus datos, y la verificación cruzada de permisos para posibles implicaciones debe ser parte del proceso de instalación o, más bien, de selección de aplicaciones. No estoy preguntando desde la perspectiva de un desarrollador cómo lidiar con eso al escribir una aplicación (aunque eso podría ser interesante;)
No, el significado del nivel de protección de "firma" no cambia en Android 6.
Podemos 'culpar' al archivo PackageManagerService.java y verificar la función grantSignaturePermission . La lógica básica no cambió desde Android Lollipop. La siguiente lógica se agregó en Android 6:
if (!allowed && (bp.protectionLevel
& PermissionInfo.PROTECTION_FLAG_PRE23) != 0
&& pkg.applicationInfo.targetSdkVersion < Build.VERSION_CODES.M) {
// If this was a previously normal/dangerous permission that got moved
// to a system permission as part of the runtime permission redesign, then
// we still want to blindly grant it to old apps.
allowed = true;
}
if (!allowed && (bp.protectionLevel & PermissionInfo.PROTECTION_FLAG_INSTALLER) != 0
&& pkg.packageName.equals(mRequiredInstallerPackage)) {
// If this permission is to be granted to the system installer and
// this app is an installer, then it gets the permission.
allowed = true;
}
if (!allowed && (bp.protectionLevel & PermissionInfo.PROTECTION_FLAG_VERIFIER) != 0
&& pkg.packageName.equals(mRequiredVerifierPackage)) {
// If this permission is to be granted to the system verifier and
// this app is a verifier, then it gets the permission.
allowed = true;
}
if (!allowed && (bp.protectionLevel
& PermissionInfo.PROTECTION_FLAG_PREINSTALLED) != 0
&& isSystemApp(pkg)) {
// Any pre-installed system app is allowed to get this permission.
allowed = true;
}
Del código anterior, podemos ver,
Conclusión : el nivel de protección de firma no cambió su significado en Android 6. Si un permiso tiene un nivel de protección de firma con otro indicador, como pre23, preinstalado, instalador o verificador, tiene nuevos significados.
A continuación se explica la confusión sobre el permiso WRITE_SETTING en la pregunta:
La documentación sobre WRITE_SETTING es incorrecta sobre el nivel de protección. Si observa el código fuente de Android en frameworks/base/core/res/AndroidManifest.xml :
<permission android:name="android.permission.WRITE_SETTINGS"
android:label="@string/permlab_writeSettings"
android:description="@string/permdesc_writeSettings"
android:protectionLevel="signature|preinstalled|appop|pre23" />
puede ver que el nivel de protección es signature|preinstalled|appop|pre23 .
Una aplicación que no pertenece al sistema que usa una firma diferente puede acceder a la funcionalidad debido al nivel de protección de appop , lo que significa que el usuario puede elegir si este permiso está activado o desactivado.
WRITE_SETTINGS, sino para protectionLevel:signature), ¡le otorgaría la recompensa de inmediato!preinstalledantes (ni appopni pre23, pero estos dos se explican por sí mismos en el contexto, ya que AppOp se presentó oficialmente con 23/MM). Como ocurre con tanta frecuencia, la documentación no se ha actualizado para incluir los nuevos niveles. Si tienes algún enlace sobre ellos, ¡será apreciado! +15rep (aceptar) luego #DRESPUESTA CORTA
SÍ
RESPUESTA LARGA de documentación de permisos
Grupos de permisos
Todos los permisos peligrosos del sistema Android pertenecen a grupos de permisos. Si el dispositivo ejecuta Android 6.0 (nivel de API 23) y el targetSdkVersion de la aplicación es 23 o superior, se aplica el siguiente comportamiento del sistema cuando su aplicación solicita un permiso peligroso:
Si una aplicación solicita un permiso peligroso que figura en su manifiesto y la aplicación actualmente no tiene ningún permiso en el grupo de permisos, el sistema muestra un cuadro de diálogo al usuario que describe el grupo de permisos al que la aplicación quiere acceder. El cuadro de diálogo no describe el permiso específico dentro de ese grupo. Por ejemplo, si una aplicación solicita el permiso READ_CONTACTS, el cuadro de diálogo del sistema simplemente dice que la aplicación necesita acceso a los contactos del dispositivo. Si el usuario otorga la aprobación, el sistema otorga a la aplicación solo el permiso que solicitó. Si una aplicación solicita un permiso peligroso que figura en su manifiesto y la aplicación ya tiene otro permiso peligroso en el mismo grupo de permisos, el sistema otorga el permiso inmediatamente sin cualquier interacción con el usuario. Por ejemplo,
Mire esto sobre las prácticas de 23+
MEJORES PRÁCTICAS Y CAMBIOS PARA API 23+
Imperio de E
izzy