Permisos de la aplicación del sistema

Tengo una aplicación que necesita permisos de root para ejecutarse. No hay problema, todos mis dispositivos personales están rooteados, por lo que me siento muy cómodo con el proceso. El problema es que esta aplicación se va a usar en dispositivos propiedad de la empresa entregados a ciertos empleados y no quiero que puedan desinstalar la aplicación ni quiero que tengan acceso de root al dispositivo.

Estaba pensando que el siguiente proceso lograría mis objetivos:

  1. Rootear el dispositivo
  2. Instalar mi aplicación como una aplicación del sistema
  3. Inicie la aplicación y otorgue sus derechos.
  4. Desrootear el dispositivo

Dado que sería una aplicación del sistema y el dispositivo no estaría rooteado, los usuarios no podrían eliminar la aplicación. De lo que no estoy seguro es si esa aplicación conservará o no sus privilegios de root una vez que el dispositivo esté desrooteado.

¡Cualquier comentario o idea sería muy apreciada!

No puede instalar su aplicación como aplicación del sistema, ya que necesita la misma clave de firma que se usó para firmar la ROM en cuestión. Si el dispositivo se desrootea, automáticamente pierde la raíz.
¿Qué pasa con las aplicaciones como Titanium Backup Pro o /system/app mover que convierten las aplicaciones de los usuarios en aplicaciones del sistema? Usando una de esas aplicaciones, es posible convertir una aplicación de usuario en una aplicación de sistema.
Incluso si esto funcionara, ¿qué evitaría que alguien vuelva a rootear el dispositivo y elimine la aplicación?
Técnicamente, nada. Pero dado que la aplicación que quiero instalar es para monitorear y administrar el dispositivo de forma remota, podría saber si lo hicieron.
¿Cómo? De la declaración anterior: "No quiero que puedan desinstalar la aplicación ni quiero que tengan acceso de root al dispositivo". La cuestión es que pueden desinstalarlo en cualquier momento... no hay nada que les impida hacerlo, incluso con adb y un cable USB, los empleados podrían ser expertos en tecnología sin que usted lo sepa...
En realidad, sería bastante simple saberlo... si la aplicación deja de informar y el examen del dispositivo revela que lo han desinstalado, los despido por manipular mi equipo. Si a través del monitoreo encuentro SuperUser.apk instalado, sé que han vuelto a rootear el dispositivo y los despido por manipular mi equipo.
Hmmm... lo único que se me ocurre es crear una ROM personalizada, eso depende del dispositivo en cuestión, si son todos iguales, el trabajo será mucho más fácil, si no, tienes problemas . Y simplemente modifique la fuente de AOSP para evitar que el administrador de paquetes se desinstale, es decir, debe piratear una solución rápida de una línea en las entrañas y agruparla con el superusuario y su aplicación, que está oculta a la vista ... aparte de eso , si habla sin un enfoque de rollo propio, ¡no tiene suerte!
@ t0mm13b En realidad, ese enfoque de TiBu debería funcionar: raíz → instalar TiBu → convertir la aplicación en aplicación del sistema (es decir, se instala en /system/apps) → desinstalar TiBu → desrootear. Hecho. Esa aplicación tendría acceso a niveles de protección de "firma o sistema" en ese momento. Pero darle acceso de root es algo diferente (y probablemente ni siquiera sea necesario aquí).

Respuestas (1)

Como ya señaló ProNetGuru , Titanium Backup podría usarse para eso:

  1. raíz
  2. instalar TiBu
  3. convertir la aplicación a la aplicación del sistema (es decir, se instala en/system/apps
  4. desinstalar TiBu
  5. desrootear

Hecho. Esa aplicación tendría acceso hasta los niveles de protección de "firma o sistema" en ese momento (si así se especifica en su Manifiesto).

Darle acceso de root es algo diferente, pero probablemente ni siquiera sea necesario aquí.

Para que una aplicación tenga signatureOrSystemnivel, tendría que tenerlo android:sharedUserId="android.uid.system"en el manifiesto y firmar con la misma clave de firma que la ROM... tbh, nunca lo he probado... para una aplicación normal que tiene un manifiesto normal, ya que no tiene la etiqueta anterior. no implica necesariamente que tenga ese nivel de protección de firma o sistema, incluso si se instaló como una "aplicación del sistema".
Oh. Es posible que me haya equivocado en esa parte (entonces, es solo un "sistema" de nivel de protección; pero, por favor, ¿cuál es la diferencia entre "firma" y "firmaOSistema" entonces? No hay un "sistema de nivel de protección" separado). Pero, por favor, corríjame: pensé que no era posible "dar acceso a la raíz de una aplicación" y luego desrootear el dispositivo mientras aún tenía ese bloqueo. Así que esto es lo más cerca que se puede llegar, dadas las circunstancias.
signatureOrSystem¡El nivel de protección significa que puede hacerlo rm -rf /sin necesidad de rootear! Y hacer cosas que una raíz normal puede hacer (uid de 0), eso es lo último. Hay muchos sharedUserIdniveles diferentes, como por ejemplo: android.uid.phone, si esa android:sharedUserIdetiqueta tiene el ejemplo anterior, significa que una aplicación puede hacer cualquier cosa relacionada con la capa de telefonía y nada más. Es un grano mucho más fino de control de acceso detrás de escena para aplicaciones de nivel de sistema y también para minimizar la violación y la malicia. Todo lo que hace TiBu, vuelve a montar el sistema r/w y mueve la aplicación allí, nada más.
Y, si esas aplicaciones del sistema, es decir, integradas en la ROM, tienen su firma digital eliminada, se negará a ejecutarse, por lo que puede ver por qué hay otro grado de niveles de protección más bajos que los permisos normales de manifiesto de Android.
Además, para agregar más ideas a esto, supongamos que el OP se fue y creó su propia ROM con dicha aplicación que tiene esa etiqueta en el manifiesto, instalada en el sistema y firmada con la firma de ROM recién creada: días felices. Luego, si el OP decide actualizar dicha aplicación a través de Play Store y distribuirla desde allí, no se actualizará porque las claves de firma no coinciden, y la única forma de hacer que la actualización funcione sería... sí, desinstalar el sistema. ¡aplicación e instálela desde Play Store! Uf, es difícil explicarlo todo. :)
Qué asco. Entonces parece que toda la pregunta es más bien XY. ¿De qué estamos hablando? ¿Qué se necesita realmente? ¿Por qué tiene que ser "una aplicación de sistema con acceso de root"? ¿Quizás prefiero borrar mi respuesta de inmediato?
Es más como la pregunta de configuración de OP como XY y sí, OP dijo "Iniciar la aplicación y otorgarle sus derechos" y desrootearla, lo que está poniendo a OP en una situación sin salida. La respuesta a continuación es concisa y simple y es la respuesta correcta a pesar de que OP no acepta nada más...
OK, entonces me iré en este punto. OP debe probar si funciona para él y luego aceptar cualquiera de las dos respuestas que resulte correcta.
es turbio!!! :Hacer/
Agradezco mucho toda la información y los conocimientos proporcionados por todos. Estaré probando esto en la próxima semana y aceptaré una respuesta y les haré saber a todos cómo funciona.
@ t0mm13b estás un poco verde. Ve a verificar tus datos (y por favor no te ofendas). Estás totalmente equivocado sobre mucho de lo que has dicho en estos comentarios. Hazme saber si tienes alguna pregunta. Las aplicaciones del sistema no pueden hacer rm -rf /. La partición del sistema es de solo lectura. Necesitas volver a montarlo r/w. Además, no necesita tener la misma firma que las aplicaciones del sistema para ser una aplicación del sistema. signatureOrSystemen un permiso no tiene nada que ver con ser una aplicación del sistema. Se otorga a aplicaciones en la carpeta del sistema O aplicaciones firmadas con la misma clave que el propio sistema.
@dcow mientras puedo secundar la mayoría de sus datos: ¿no se define exactamente una "aplicación del sistema" como instalada en la carpeta del sistema? ¿Y no podrían simplemente volver a montar ellos mismos antes de ejecutar rm -rf? Pero, por supuesto, tiene razón al decir que "solo tener el permiso en el Manifiesto no es suficiente": es cierto, debe estar firmado con la "clave del sistema" o al menos instalado como aplicación del sistema en primer lugar para que ese permiso sea concedido, pero eso es lo que hace el paso n. ° 3 de la respuesta.
Permisos de la aplicación del sistema
RespuestasAquíPolítica de privacidad1y, 0v