Contexte
Historiquement, les autorisations personnalisées d'Android ont été un désordre y dépendent de l'ordre d'installation qui était connu pour exposer les vulnérabilités .
Avant l'API 21, il existait une solution de contournement troublante selon laquelle le fait de déclarer la permission personnalisée d'une autre application dans votre manifeste permettait d'obtenir cette permission... Cependant, depuis l'API 21, une seule application peut déclarer une permission personnalisée et l'installation d'une autre application déclarant cette même permission sera empêchée.
Les alternatives sont de réinstaller l'application nécessitant la permission, afin qu'elles soient détectées par le système, mais cela n'est pas une bonne expérience pour l'utilisateur . Ou vérifier au moment de l'exécution les autorisations de l'application appelante, mais qui n'est pas sans présenter des défauts théoriques .
Problème
Depuis Android Marshmallow (6.0 - API 23), une application doit demander la permission à l'utilisateur, d'utiliser sa propre permission personnalisée . Une autorisation personnalisée déclarée n'est pas automatiquement accordée.
Cela semble curieux, étant donné qu'une seule application peut désormais le déclarer.
Pour répliquer
Déclarez la permission personnalisée et un BroadcastReceiver dans le manifeste.
<permission
android:name="com.example.app.permission.CONTROL_EXAMPLE_APP"
android:description="@string/control_description"
android:icon="@mipmap/ic_launcher"
android:label="@string/control_label"
android:protectionLevel="normal or dangerous"/>
<uses-permission
android:name="com.example.app.permission.CONTROL_EXAMPLE_APP"/>
// etc
<receiver
android:name="com.example.app.MyBroadcastReceiver"
android:permission="com.example.app.permission.CONTROL_EXAMPLE_APP">
<intent-filter android:priority="999">
<action android:name="com.example.app.REQUEST_RECEIVER"/>
</intent-filter>
</receiver>Depuis une application tierce, déclarez qu'elle utilise la permission personnalisée dans le manifeste (et acceptez-la via une boîte de dialogue ou les paramètres) et appelez :
final Intent intent = new Intent("com.example.app.REQUEST_RECEIVER");
context.sendOrderedBroadcast(intent, "com.example.app.permission.CONTROL_EXAMPLE_APP", new BroadcastReceiver() {
@Override
public void onReceive(final Context context, final Intent intent) {
// getResultCode();
}
}, null, Activity.RESULT_CANCELED, null, null);Le résultat sera CANCELED et le journal indiquera :
system_process W/BroadcastQueue : Déni de permission : réception de l'intention { act=com.example.app.REQUEST_RECEIVER flg=0x10 (has extras) } to com.example.app/.MyBroadcastReceiver nécessite com.example.app.permission.CONTROL_EXAMPLE_APP en raison de l'expéditeur com.example.thirdparty
Si j'utilise la norme ActivityCompat.requestPermissions() pour permettre à l'utilisateur d'accepter la permission, le récepteur, comme on peut s'y attendre, fonctionne correctement.
Pregunta
Est-ce un comportement attendu ? Ou ai-je négligé quelque chose ?
Il semblerait ridicule d'élever un dialogue disant
L'application Example App veut la permission d'utiliser Example App
Et cela peut effectivement concerner l'utilisateur, en lui fournissant une demande aussi absurde.
Je peux bien sûr changer la description et le nom de l'autorisation en quelque chose qu'ils accepteraient, par exemple communiquer avec d'autres applications installées Mais avant de soupirer et d'adopter cette approche, j'ai pensé que je devais poser cette question.
Nota
L'exemple de la diffusion ordonnée consiste à reproduire le problème. Mon application utilise d'autres implémentations de fournisseurs de contenu et un service lié. Ce n'est pas une implémentation alternative que j'exige, c'est une confirmation du problème.
Merci d'avoir lu jusqu'ici.
Edit : Pour clarifier, pour d'autres implémentations, comme la déclaration d'une permission sur un service (ce qui serait très simple à reproduire), la permission personnalisée déclarée est automatiquement accordée.
