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_
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.
Señor del Fuego
Grimorio
emilio
emilio
emilio
iBug