Je pensais que adb donnait une sorte d'accès temporaire sans restriction (comme le Root temporaire).
Lorsque vous ouvrez une application ordinaire d'émulation de terminal, un terminal s'affiche et vous êtes automatiquement connecté en tant qu'utilisateur particulier. L'ID utilisateur de cet utilisateur particulier est l'ID utilisateur de l'application émulateur de terminal affichée. Un tel utilisateur et une telle application sont considérés comme indignes de confiance et ne sont pas autorisés à faire un grand nombre de choses. Vous pouvez voir les éléments figurant sur la liste noire dans le code source de untrusted_app.te .
ADB, d'autre part, lorsqu'il s'interface avec l'appareil, utilise l'ID utilisateur 2000. Cet utilisateur est appelé coquille et peut faire pas mal de choses dans le but de déboguer mais ne peuvent toujours pas répondre aux demandes complexes d'un utilisateur final. 1 . À moins qu'Android ne propose un mécanisme permettant de basculer vers un autre utilisateur à volonté (tel que 'su' ; non graphique mais console), l'utilisateur final ne peut faire bon usage de l'utilisateur shell que lorsque l'appareil est connecté au PC en mode débogage. Suivez le code source de shell.te pour connaître les privilèges dont jouit l'utilisateur de l'obus.
En bref, si Android n'est pas enraciné, l'utilisateur shell est évidemment gagnant en raison des privilèges qui lui sont accordés par rapport à un utilisateur indigne de confiance, mais il ne sert pas de bon substitut au superutilisateur (su). En plus de cela, comme je l'ai noté ci-dessus, il a un coût.
Ressource connexe : les identifiants d'utilisateur qui sont définis dans Android
1 Qu'il soit temporaire ou non, l'utilisateur Root a toujours l'ID utilisateur 0.