Sur les émulateurs SDK et les machines virtuelles comme Genymotion, adbd
démarre en tant que Root et fournit un shell Root. À moins de modifier le code source pour qu'il en soit autrement et de reconstruire vos images VM, je pense que vous devrez utiliser l'option de démarrage par défaut. su
approche suggérée ci-dessus. su shell
fonctionne effectivement sur les émulateurs SDK ainsi que sur les VM de Genymotion. Plus précisément :
ubuntu$ adb shell
android# id
uid=0(root) gid=0(root) context=u:r:shell:s0
android# su shell
android$ uid=2000(shell) gid=2000(shell) context=u:r:su:s0
Notez que le shell initial est exécuté en tant que uid 0 et après que su shell
est exécuté en tant que uid 2000. En fait, vous pouvez vous connecter à n'importe quel uid Linux (Android userId
+ appId
) configuré sur votre émulateur/VM. Par exemple, après avoir fait adb shell
d'Ubuntu :
android# su u0_a16
android$ id
uid=10016(u0_a16) gid=10016(u0_a16) context=u:r:su:s0
android$
Sur mon émulateur, l'uid 0010016 est l'application calendrier de l'utilisateur 0 (propriétaire, userId
00). Rappelez-vous qu'après avoir fait un su, vous n'avez que les privilèges du nouvel uid, et cela peut ne pas inclure les permissions d'exécuter des commandes Linux ou de voir certains répertoires.
Enfin, si vous avez juste besoin d'effectuer une ou deux opérations en tant qu'utilisateur non-Root, vous pouvez enchaîner le tout en une seule commande dans Ubuntu. Quelque chose comme :
ubuntu$ adb shell su u0_a16 id
uid=10016(u0_a16) gid=10016(u0_a16) context=u:r:su:s0
o
ubuntu$ adb shell su radio cat /data/data/com.android.phone/shared_prefs/*.xml\; su radio id
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<boolean name="_has_set_default_values" value="true" />
</map>
uid=1001(radio) gid=1001(radio) context=u:r:su:s0
Testé ci-dessus sur l'émulateur SDK x86 fonctionnant en 4.4.2 et sur Genymotion VM fonctionnant en 4.4.2.