Comment vérifier si “android.la permission.PACKAGE_USAGE_STATS” l'autorisation est donnée?

Fond

J'essaye de l'application lancée, en statistiques, et sur Lollipop, il est possible à l'aide de la UsageStatsManager de classe, en tant que tel (post original ici):

manifeste:

<uses-permission
    android:name="android.permission.PACKAGE_USAGE_STATS"
    tools:ignore="ProtectedPermissions"/>

de l'ouverture de l'activité qui va permettre à l'utilisateur de confirmer en vous donnant cette autorisation:

startActivity(new Intent(Settings.ACTION_USAGE_ACCESS_SETTINGS));

avoir les stats, agrégées :

 private static final String USAGE_STATS_SERVICE ="usagestats"; //Context.USAGE_STATS_SERVICE);
 ...
 final UsageStatsManager usageStatsManager=(UsageStatsManager)context.getSystemService(USAGE_STATS_SERVICE);
 final Map<String,UsageStats> queryUsageStats=usageStatsManager.queryAndAggregateUsageStats(fromTime,toTime);

Le problème

Je n'arrive pas à vérifier si l'autorisation que vous avez besoin ("android.la permission.PACKAGE_USAGE_STATS") est accordée. Tout ce que j'ai essayé jusqu'à présent renvoie toujours qu'il est refusé.

Le code fonctionne, mais la vérification d'autorisation ne fonctionne pas bien.

Ce que j'ai essayé

vous pouvez vérifier une autorisation accordée à l'aide de ceci:

String permission = "android.permission.PACKAGE_USAGE_STATS";
boolean granted=getContext().checkCallingOrSelfPermission(permission) == PackageManager.PERMISSION_GRANTED;

ou ceci:

String permission = "android.permission.PACKAGE_USAGE_STATS";
boolean granted=getPackageManager().checkPermission(permission,getPackageName())== PackageManager.PERMISSION_GRANTED;

À la fois toujours retourné, il a refusé (même si j'ai l'autorisation en tant qu'utilisateur).

Regardant le code de UsageStatsManager, j'ai essayé de venir avec cette solution de contournement:

      UsageStatsManager usm=(UsageStatsManager)getSystemService("usagestats");
      Calendar calendar=Calendar.getInstance();
      long toTime=calendar.getTimeInMillis();
      calendar.add(Calendar.YEAR,-1);
      long fromTime=calendar.getTimeInMillis();
      final List<UsageStats> queryUsageStats=usm.queryUsageStats(UsageStatsManager.INTERVAL_YEARLY,fromTime,toTime);
      boolean granted=queryUsageStats!=null&&queryUsageStats!=Collections.EMPTY_LIST;

Il a travaillé, mais c'est toujours une solution de contournement.

La question

Comment se fait je ne suis pas d'obtenir le résultat correct de la vérification d'autorisation?

Ce qui doit être fait pour vérifier il mieux?

InformationsquelleAutor android developer | 2015-03-07
  1. 15

    Par notre enquête: si le MODE par défaut (MODE_DEFAULT), l'ajout de la vérification de l'autorisation est nécessaire. Grâce à Weien d'examen à l'effort.

    boolean granted = false;
AppOpsManager appOps = (AppOpsManager) context
        .getSystemService(Context.APP_OPS_SERVICE);
int mode = appOps.checkOpNoThrow(AppOpsManager.OPSTR_GET_USAGE_STATS, 
        android.os.Process.myUid(), context.getPackageName());

if (mode == AppOpsManager.MODE_DEFAULT) {
    granted = (context.checkCallingOrSelfPermission(android.Manifest.permission.PACKAGE_USAGE_STATS) == PackageManager.PERMISSION_GRANTED);
} else {
    granted = (mode == AppOpsManager.MODE_ALLOWED);
}
    • Quelle est la différence entre l'utilisation de cette, et celui que j'ai accepté?
    • La seule différence est dans la mode: MODE_DEFAULT, l'autorisation peut être accordée ou non. Une vérification plus poussée est nécessaire.
    • Est-il possible que le code d'origine de ce que j'ai accepté de ne pas travailler, alors? Ce qui est le cas d'utilisation ?
    • La mode: MODE_DEFAULT pourrait revenir dans les premiers temps apps vérifier (à l'autorisation n'est pas modifié encore). Mais ce mode ne signifie pas que la permission n'est pas accordée. Nous avons besoin de vérifier autorisation à l'aide du contexte.checkCallingOrSelfPermission() fonction.
    • Mais quand j'ai essayé checkCallingOrSelfPermission , il est toujours écrit que c'est refusé, ce qui est pourquoi j'ai posé cette question fil (voir la partie "ce que j'ai essayé" ) . Pouvez-vous nous dire ce qu'il faut faire pour voir comment il fonctionne différemment (étapes)?
    • Notre solution a montré, seulement contexte d'utilisation.checkCallingOrSelfPermission() lorsque le mode est MODE_DEFAULT. D'autres cas devraient utiliser la logique originale comme vous l'avez mentionné.
    • ok, je vous remercie pour cette.
    • Vous êtes les bienvenus. Il est bon d'aider à la meilleure solution.
    • plantage sur checkOpNoThrow donc je veux demander la permission "d'android.la permission.PACKAGE_USAGE_STATS" est un travail en dessous de sucette ou pas
    • OPSTR_GET_USAGE_STATS - Ajout de l'API de niveau 21 (Lollipop).
    • Je ne crois pas checkCallingOrSelfPermission renvoie true lorsque MODE_DEFAULT et l'autorisation est accordée. Pouvez-vous confirmer que vous avez réellement vu un tel cas, à tous?
    • pas de travail pour oppo appareil, des suggestions?
    • Veuillez spécifier votre question dans le détail de laisser les membres de la communauté de l'aide.
    • Votre réponse est à l'origine d'une erreur pour moi, aide serait appréciée: stackoverflow.com/questions/51343155/...
    • android.Le manifeste.la permission.PACKAGE_USAGE_STATS est disponible à partir de l'API de niveau 23 , est cette autorisation est donnée pour les applications tierces pour l'API de niveau 21 et 22?
    • href="https://github.com/aosp-mirror/platform_frameworks_base/blob/lollipop-release/core/res/AndroidManifest.xml#L2521" >cette autorisation n'est jamais accordée à la non-Système apps.
    • Le supplément de vérifier dans cette réponse n'est nécessaire que si vous êtes l'élaboration d'un système app. Voir je m'explique.

    InformationsquelleAutor Chris Li
  2. 27

    Autorisations spéciales accordées par l'utilisateur dans les paramètres système (statistiques d'utilisation de l'accès, de la notification d'accès, ...) sont traitées par AppOpsManager, qui a été ajoutée dans Android 4.4.

    Note que, outre l'utilisateur de vous accorder l'accès dans les paramètres système vous généralement besoin d'une autorisation dans le manifeste Android (ou certains de ses composants), sans que votre application ne s'affiche même pas dans les paramètres système. Pour les statistiques d'utilisation vous avez besoin android.permission.PACKAGE_USAGE_STATS autorisation.

    Il n'y a pas beaucoup de documentation à ce sujet, mais vous pouvez toujours vérifier Android sources pour cela.
    La solution peut sembler très orthodoxe parce que certaines constantes ont été ajoutées plus tard à la AppOpsManager, et certaines constantes (par exemple, pour vérifier les différentes autorisations) sont encore cachés dans des Api privées.

    AppOpsManager appOps = (AppOpsManager) context
        .getSystemService(Context.APP_OPS_SERVICE);
int mode = appOps.checkOpNoThrow("android:get_usage_stats", 
        android.os.Process.myUid(), context.getPackageName());
boolean granted = mode == AppOpsManager.MODE_ALLOWED;

    Cela vous indique si l'autorisation a été accordée par l'utilisateur.
    A noter que depuis l'API de niveau 21, il est constant AppOpsManager.OPSTR_GET_USAGE_STATS = "android:get_usage_stats".

    J'ai testé cette vérification de la Sucette (y compris 5.1.1) et il fonctionne comme prévu. Il me dit que l'utilisateur a donné l'autorisation explicite sans aucun plantage.
    Il y a aussi la méthode appOps.checkOp() qui pourrait jeter un SecurityException.

    • Pour une raison quelconque, il s'est écrasé pour moi. Pourriez-vous veuillez donner une vue plus détaillée de code? Peut-être que je me trompe quelque part...
    • Quel exception fait jeter?
    • Je pense que c'est: java.lang.SecurityException: uid 10046 n'ont pas android.la permission.UPDATE_APP_OPS_STATS. Tu veux dire qu'il a besoin d'une autorisation supplémentaire? BTW, je pense que c'est mieux d'écrire "android.os.Processus.myPid()" que "myUid" .
    • J'ai mis à jour la réponse, si vous utilisez checkOpNoThrow() méthode, est ne devraient pas jeter de l'exception. Toutefois, la vérification ne semble pas être un travail sur Lollipop 🙁
    • Désolé, mais le point de moi de l'utiliser, est pour Lollipop, que cette autorisation a été ajoutée il y a...
    • Dire à propos de la solution de contournement que j'ai écrits, autres que le problème qu'il est basé sur le fait que le code ne change pas (ce qui est une mauvaise chose), c'est "correct" ? sera-ce toujours le travail (encore une fois, en supposant que la mauvaise hypothèse) ?
    • J'ai vérifié le code, et il a fonctionné parfaitement pour moi. On pourrait dire la bonne valeur qui a été définie pour l'application dans les paramètres de sécurité.
    • Quel code? celui que vous avez écrit, ou celui que j'ai écrit?
    • Ma réponse, le code que j'ai écrit a fonctionné parfaitement sur mon Nexus 5 avec Lollipop.
    • Semble fonctionner. Comment avez-vous trouver cette solution? Existe-il des choses importantes que je devrais savoir à ce sujet? Et pourquoi pas la vérification d'autorisation de travail comme d'habitude?
    • BTW, pour une raison quelconque, Android Studio n'aime pas l'utilisation du "Contexte.APP_OPS_SERVICE" .
    • Si cela vous a aidé, envisager d'accepter la réponse. J'ai vérifié Android sources pour la solution. Si vous regardez dans les UsageStatsService vous trouverez comment il vérifie l'autorisation. Il vérifie tout d'abord le consentement explicite de l'utilisateur AppOpsManager et puis il issues de standard de vérification des autorisations. Il est important de savoir que ce contrôle vérifie uniquement utilisateur des autorisations de ce genre, elle ne vérifie pas manifeste des autorisations.
    • Quelle est la norme de vérification des autorisations? Pouvez vous s'il vous plaît copiez et collez le code que vous avez regardé? Sur le point d'accepter, je le ferai. Pour l'instant, vous obtenez +1 pour la peine.
    • Pouvez-vous confirmer que la solution ci-dessus est le travail pour vous? Mon besoin, c'est la récente liste des tâches et passé par toutes vos questions et post liées à ... Pouvez-vous me donner une idée comment avez-vous finalement réussi.
    • que je me souvienne, il a travaillé, mais à cause de quoi il ressemble, je pense que plus de recherche est nécessaire.
    • J'ai testé le code sur Android 5.1.1, et il se bloque avec le SecurityException .Pourquoi est-ce?
    • Votre réponse est à l'origine d'une erreur pour moi, aide serait appréciée: stackoverflow.com/questions/51343155/...

    InformationsquelleAutor Tomik
  3. 4

    Le deuxième argument de checkOpNoThrow est uid, pas pid.

    Modifiant le code de réfléchir qui semble résoudre les problèmes d'autres ont été d'avoir:

    AppOpsManager appOps = (AppOpsManager) context
        .getSystemService(Context.APP_OPS_SERVICE);
int mode = appOps.checkOpNoThrow("android:get_usage_stats", 
        android.os.Process.myUid(), context.getPackageName());
boolean granted = mode == AppOpsManager.MODE_ALLOWED;
    • Pourquoi n'avez-vous pas l'écrire dans les commentaires si c'est la seule chose qui ne va pas...
    • Je n'ai pas la réputation d'écrire un commentaire encore. N'hésitez pas à ajouter un commentaire, et je vais supprimer ma réponse.
    • Comme c'est étrange. Je suis très sûr que j'ai essayé avant, et qu'il n'a pas de travail. J'ai même exactement le même code dans les points de app que j'ai fait pour cela, et signalés à Google. Je n'ai aucune idée de ce qu'il se passe. Peut-être que j'ai eu une mauvaise rom ?
    • Votre réponse est à l'origine d'une erreur pour moi, aide serait appréciée: stackoverflow.com/questions/51343155/...
    InformationsquelleAutor kingjason611
  4. 1

    Le supplément de vérifier dans Chris Li's réponse est inutile, sauf si vous êtes l'élaboration d'un système app.

    Lorsqu'une application est installée et que l'utilisateur n'a pas touché l'application de l'utilisation de l'autorisation d'accès, puis checkOpNoThrow() retourne MODE_DEFAULT.

    Chris dit ensuite, nous avons besoin de vérifier si l'application a la PACKAGE_USAGE_STATS manifeste de l'autorisation:

    if (mode == AppOpsManager.MODE_DEFAULT) {
    granted = (context.checkCallingOrSelfPermission(Manifest.permission.PACKAGE_USAGE_STATS) == PackageManager.PERMISSION_GRANTED);
} else {
    granted = (mode == AppOpsManager.MODE_ALLOWED);
}

    Cependant, à moins que votre application est une application système, la vérification de cette autorisation retourne toujours PERMISSION_DENIED parce que c'est une signature de l'autorisation. De sorte que vous pouvez simplifier le code en bas à ceci:

    if (mode == AppOpsManager.MODE_DEFAULT) {
    granted = false;
} else {
    granted = (mode == AppOpsManager.MODE_ALLOWED);
}

    Que vous pouvez ensuite simplifier réduit à ceci:

    granted = (mode == AppOpsManager.MODE_ALLOWED);

    Qui nous ramène à l'original, la solution la plus simple:

    AppOpsManager appOps = (AppOpsManager) context.getSystemService(Context.APP_OPS_SERVICE);
int mode = appOps.checkOpNoThrow(AppOpsManager.OPSTR_GET_USAGE_STATS, Process.myUid(), context.getPackageName());
boolean granted = (mode == AppOpsManager.MODE_ALLOWED);

    Testé et vérifié dans Android 5, 8.1 et 9.

    • Depuis cette réponse ne permet pas de couvrir tous les cas, comme vous l'avez même écrit (pas de système pour les applications), je pense que ma réponse est mieux: stackoverflow.com/a/54839499/878126 . Il couvrira tous les cas, et même si l'utilisateur s'est converti à l'application d'un système d'application, elle fonctionne. Je ne vois pas de point dans l'écriture d'une nouvelle réponse qui est identique et qui dit que c'est mieux juste parce que c'est plus court, tout en disant que cela ne fonctionne que dans certains (certes, la plupart) des cas...
    • Merci de mentionner ma réponse. En effet je l'ai essayé dans un pré-installation d'une application.
    InformationsquelleAutor Sam