La signification de "Niveau de protection : signature" a-t-elle changé avec Android 6 ?

Non, la signification du niveau de protection de la "signature" n'est pas modifiée dans Android 6.

Nous pouvons "blâmer git" le fichier PackageManagerService.java et vérifier la fonction grantSignaturePermission . La logique de base n'a pas changé depuis Android Lollipop. La logique suivante a été ajoutée dans 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;
    }

A partir du code ci-dessus, nous pouvons voir,

• si la permission est spécifiée avec "signature|pre23" et que la version du sdk cible de l'application est inférieure à 23, elle obtiendra cette permission, car cette permission a été déplacée vers la permission système dans Android 6.
• si la permission est spécifiée avec "signature|preinstalled" et que l'application est une application système préinstallée, elle obtiendra la permission.
• si la permission est spécifiée avec "signature|installateur" ou "signature|vérificateur" et que l'application est installateur et vérificateur, elle obtiendra la permission.

Conclusion Le niveau de protection de la signature n'a pas changé de signification dans Android 6. Si une permission a un niveau de protection de la signature avec un autre drapeau, comme pre23, preinstalled, intaller ou verifier, il a de nouvelles significations.

Ce qui suit explique la confusion concernant la permission WRITE_SETTING dans la question :

La documentation sur WRITE_SETTING est erroné en ce qui concerne le niveau de protection. Si vous regardez le code source d'Android à 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" />

vous pouvez voir que le niveau de protection est signature|préinstallée|appop|pre23 .

Une application non-système utilisant une signature différente peut accéder à la fonctionnalité en raison du niveau de protection de appop ce qui signifie que l'utilisateur peut choisir si cette autorisation est activée ou non.

RÉPONSE COURTE
OUI

LONGUE RÉPONSE de documents d'autorisation

Groupes de permission

Toutes les permissions dangereuses du système Android appartiennent à des groupes de permissions. Si l'appareil fonctionne sous Android 6.0 (niveau 23 de l'API) et que la targetSdkVersion de l'application est égale ou supérieure à 23, le comportement système suivant s'applique lorsque votre application demande une permission dangereuse :

Si une application demande une autorisation dangereuse répertoriée dans son manifeste et que l'application n'a actuellement aucune autorisation dans le groupe d'autorisations, le système affiche une boîte de dialogue à l'utilisateur décrivant le groupe d'autorisations auquel l'application veut accéder. La boîte de dialogue ne décrit pas l'autorisation spécifique au sein de ce groupe. Par exemple, si une application demande l'autorisation READ_CONTACTS, la boîte de dialogue du système indique simplement que l'application doit avoir accès aux contacts de l'appareil. Si une application demande une autorisation dangereuse répertoriée dans son manifeste et que l'application possède déjà une autre autorisation dangereuse dans le même groupe d'autorisations, le système accorde immédiatement l'autorisation sans aucune interaction avec l'utilisateur. Par exemple, si une application a déjà demandé et obtenu l'autorisation READ_CONTACTS et qu'elle demande ensuite WRITE_CONTACTS, le système lui accorde immédiatement cette autorisation.

S'il vous plaît, regardez ceci à propos de 23+ pratiques