Notez que cette permission n'est presque pas documentée, et que nous devons donc chercher à comprendre sa véritable signification. Il ne s'agit donc en aucun cas d'une "réponse faisant autorité" - mais plus ou moins d'une "bonne supposition" et d'une "déduction à partir d'autres pointeurs".
La description officielle de cette permission (comme indiqué, il n'y a pas d'autre documentation) est la suivante :
Permet à une application de modifier la carte des services Google.
Donc maintenant on peut deviner ce que ça veut dire. Faisons un peu de "reverse engineering" pour y voir plus clair. Ryan a déjà donné quelques conseils dans son commentaire, en faisant le lien avec deux questions de l'OS :
Lire entre les lignes : Chaque fois qu'une application veut utiliser (des parties de) l'application Cadre des services Google il doit déclarer le READ_GSERVICES
autorisation requise - ce qui revient à peu près au même que d'exiger une GET_ACCOUNTS
si vous voulez USE_CREDENTIALS
L'application doit d'abord s'assurer que le service requis est disponible, avant d'y accéder.
Cela nous donne une idée de ce que le Carte de service Google doit être : une sorte d'index pour les services Google disponibles (installés).
Maintenant que nous avons découvert ça, nous pouvons deviner ce que le WRITE_GSERVICES
et pourquoi elle est protégée par la loi sur la protection des données. system
(c'est-à-dire qu'elle n'est accordée qu'aux "applications système", c'est-à-dire celles qui sont intégrées à la ROM, qui est installée sur l'ordinateur). /system
partition) : Si READ_GSERVICES
est destiné à déterminer quels services Google sont disponibles, WRITE_GSERVICES
doit être son pendant à mise à jour cette carte de service. Il s'agit par exemple, à chaque fois qu'un nouveau service est installé (ou supprimé), de mettre à jour l'"index des services Google disponibles sur l'appareil" - la "carte des services Google".
Une chose que je me demande dans ce contexte est, pourquoi cette autorisation appartient à la ACCOUNTS
groupe
Voir aussi :