¿Cómo se reinicia una aplicación del sistema Android después de eliminarla en dispositivos rooteados?

Entonces, para aclarar, me gustaría saber cómo una aplicación del sistema puede resucitar (inicio automático) después de emitir un comando de eliminación. Hay formas de eliminar aplicaciones, mediante el uso de aplicaciones de eliminación de aplicaciones y directamente usando el comando rm para borrar físicamente el apk/odex y las carpetas. Y hay muchas respuestas sobre esto. Mi pregunta está relacionada con el "mecanismo" de arranque automático en sí. Es decir, ¿hay algún archivo xml y algún proceso principal en ejecución que lo verifique? O algo así. Como referencia, estoy usando Android 6.0.1 y MIUI 8.5.3 en un dispositivo rooteado.

Básicamente, estoy explorando la posibilidad de que algunas aplicaciones del sistema que elimine (y luego envíen su teléfono a bootloop) no sean necesarias, pero el proceso de verificación/intento de inicio es lo que hace que se reproduzca. El razonamiento es que, aparte del error "la aplicación dejó de funcionar", el sistema parece no verse afectado. Así que es el mensaje el que está creando el problema y lo que sea que esté detrás de generarlo. Esta respuesta me permitirá probar esta posibilidad y publicar cualquier hallazgo aquí.

Edit1:Así que parece la respuesta a la mitad de mi propia pregunta (suponiendo que no esté ocurriendo otra "magia negra", como otra aplicación que verifique el estado ...): lo más probable es que el reinicio se logre a través de BroadcastReceiver .

Una aplicación puede registrar un receptor de transmisión para eventos del sistema . La forma en que funciona es que, cuando ocurre un evento en el sistema (se conecta el USB, se detecta Internet, etc.), se envía una transmisión a todas las aplicaciones que están registradas para escuchar este evento. Una aplicación puede registrarse a través de su AndroidManifest.XML o pragmáticamente. Pero la parte principal de la pregunta es: ¿ dónde está este registro y cómo es posible modificarlo ( en un dispositivo rooteado, por supuesto)?

Edit2:Un poco más de información. Si hago ps, el proceso se muestra normal:

finddevice [....] SyS_epoll_ 7f83b48c54 S com.xiaomi.finddevice

Pero si cambio el nombre de una carpeta de este proceso del sistema (para deshabilitarlo) y luego elimino el proceso, parece que es un hilo de enlace ( binder_thr ) tratando de revivirlo:

finddevice [....] binder_thr 7f83b48d44 S com.xiaomi.finddevice

Y tan pronto como cambio el nombre de la carpeta a la original, vuelve a comenzar y se muestra como SyS_epoll_

Las aplicaciones se registran solas (si es necesario) con el sistema para transmisiones, como cambio de conectividad de red, cambio de orientación del dispositivo, etc. Cuando ocurre un cambio de este tipo, la transmisión activa la aplicación. Si tiene Xposed Framework instalado, intente esto: repo.xposed.info/module/de.defim.apk.receiverstop , y vea si la aplicación aún se activa por sí sola.
@Firelord Si estoy en lo correcto, entonces esto es factible incluso desde SD Maid , para usuarios que no son Xposed.
@DeathMaskSalesman Probó SD Maid, es una buena herramienta y funciona en algunas aplicaciones del sistema, pero no en todas. Dice "fallido" cuando intento desactivar sus oyentes en Receiver Manager.
@Firelord No tengo Xposed instalado. Entonces, cuando una de estas resistentes aplicaciones del sistema se reinicia, ¿es su oyente el que está haciendo algo? ¿O también puede ser alguna otra aplicación que está escuchando y cuando ve que mataste a su "amigo" lo resucita? Quiero decir, la primera opción es sobre la que he leído en algunos lugares, solo me preguntaba si la segunda opción también podría ser posible. ¿Hay un lugar de registro común donde se almacenan estas cosas (y se pueden editar)?
@Firelord Instalé Xposed para probar esta teoría, pero el módulo ReceiverStop solo ofrece control sobre las aplicaciones del sistema en la versión paga. (y solo lo necesito para probar) Encontré una alternativa en el módulo Xposed: repo.xposed.info/module/cn.wq.myandroidtoolsxposed Pero esta aplicación ofrece documentación limitada. Solo una lista de aplicaciones con una sola casilla de verificación al lado de cada una. Cuando hago clic en la casilla de verificación de esta aplicación del sistema y hago clic en Guardar, obtengo un brindis: "Listo". La aplicación aún se reinicia.
Alternativamente, puede usar Lucky Patcher para deshabilitar componentes de cualquier aplicación.

Respuestas (1)

No pude comprender mucho este código , pero la información sobre los receptores parece mantenerse solo en la memoria (sin archivo de índice en el almacenamiento interno). Puede usar el siguiente comando para ver qué receptor está registrado para qué tipo de transmisión.

adb shell dumpsys package

En cuanto a desactivar un receptor en particular, prueba Elixir 2 . Puede ir a su sección Aplicaciones, elegir su aplicación y luego desplazarse hacia abajo para encontrar los receptores (estáticos). Junto a ellos estaría la opción de desactivar ese componente.

Otra opción es usar el módulo ReceiverStop Xposed. Su versión gratuita permite deshabilitar receptores solo para aplicaciones instaladas por el usuario.

En cuanto a la línea de comandos, si conoce el nombre del receptor/componente, podría hacer lo siguiente:

adb shell su -c 'pm disable PKG/COMP'         # where PKG is package name of the app and COMP is the component you intend to disable.

Dicho esto, no probé si dichas soluciones funcionan para receptores registrados dinámicamente.

No hace falta decir que la respuesta es válida solo para dispositivos Android rooteados.
Bueno, esa es la cuestión, pm disabled no funciona para estos paquetes de sistema "difíciles". (Sin embargo, funciona para algunas aplicaciones del sistema) Por ahora estoy usando un script que escribí para desactivar/activar alternativamente. Script 1) cambia el nombre de los archivos .apk y .odex y 2) elimina el proceso. Esto crea un bucle infinito de ventana emergente que dice "lamentablemente..." Luego vuelvo a activar el script. Y el proceso se reinicia y los errores desaparecen. Las aplicaciones que se comportan de esta manera provocarán un bootloop si reinicio, por lo que ahorra tiempo de prueba.
Gracias por el enlace Elixir2, brinda detalles útiles adicionales. Pero al igual que SD Maid, no funciona para estas aplicaciones. Hacer clic en [deshabilitar] junto a Actividades/Receptores no tiene ningún efecto. ReceiverStop, como dijiste, solo da acceso a las aplicaciones del sistema en la versión paga. Pero solo necesito esto para probar. Eso es para eliminar los receptores y ver si la ROM sigue siendo estable. En caso afirmativo, entonces se identificaría el problema y trataría de encontrar una forma de secuencia de comandos para hacer esto de alguna manera.