Pensé que adb da algún tipo de acceso temporal sin restricciones (como Root temporal).
Cuando abres una aplicación ordinaria de emulador de terminal, se te muestra un terminal y se inicia automáticamente la sesión como un usuario determinado. El ID de usuario de este usuario particular es el ID de usuario de su app emuladora de terminal mostrada. Ese usuario y esa aplicación se consideran poco fiables y no se les permite hacer muchas cosas. Puede ver los elementos de la lista negra en el código fuente de untrusted_app.te .
Por otro lado, ADB, cuando interactúa con el dispositivo, utiliza el ID de usuario 2000. Este usuario se llama shell y puede hacer bastantes cosas con el fin de depurar pero todavía no puede satisfacer las intrincadas demandas de un usuario final 1 . A menos que Android ofrezca un mecanismo para cambiar a otro usuario a voluntad (como 'su'; no gráfico sino de consola), el usuario final está limitado a hacer un buen uso del usuario shell sólo cuando el dispositivo está conectado al PC en modo de depuración. Sigue el código fuente de shell.te para conocer los privilegios de los que goza el usuario de la shell.
En resumen, si el Android no está rooteado el usuario shell obviamente sale ganando por los privilegios que se le otorgan en contraste con un usuario no confiable, pero no sirve como un buen sustituto del superusuario (su). Además de eso, como he señalado anteriormente viene con un costo.
Recurso relacionado: IDs de usuario que vienen definidos en Android
1 Temporal o no, el usuario Root siempre tiene el ID de usuario 0.