2 votos

¿Borrar todas las aplicaciones del sistema de Android con el fin de desinstalarlas impedirá que se inicie?

Las motivaciones de las empresas con ánimo de lucro como Google, Samsung y Microsoft, junto con las motivaciones de los servicios secretos como GCHQ y la NSA, están en desacuerdo con mi deseo de utilizar el costoso teléfono inteligente que he pagado para ejecutar sólo las aplicaciones que yo elija.

Es aparentemente imposible comprar o construir un teléfono con nada más que Android de código abierto puro instalado. Todos tienen cantidades impactantes de bloatware preinstalado.

Así que he rooteado mi teléfono y estoy usando un Debloat (emulador de terminal) para eliminar las aplicaciones del sistema. He eliminado casi todo lo relacionado con Google, Samsung, Microsoft, etc.

Mi teléfono tarda ahora más de una hora en reiniciarse y se calienta mucho.

Mi pregunta es, si sigo eliminando todas las aplicaciones y las aplicaciones del sistema. ¿Seguirá funcionando el sistema operativo Android de tal manera que sólo podré instalar las apps de código abierto que yo elija? ¿O hay algunas apps que son realmente imprescindibles para que el sistema operativo se ponga en marcha?

1 votos

No sabemos qué modelo de Android y qué versión de Android estás usando Y sería difícil averiguar qué aplicaciones no son esenciales excepto las de Google sin tener el propio teléfono. La forma más segura es usar un custom recovery para hacer una copia de seguridad de la partición del sistema (y luego moverla en el PC) y luego hacer todos los experimentos que quieras en las apps del sistema.

1 votos

Bueno, como @Firelord ha dicho que tu pregunta es específica del dispositivo, intentaré darte una visión general. En primer lugar hay que tener claro que si estás muy preocupado, eliminar sólo las aplicaciones del sistema puede no ser suficiente para "desinstalar" completamente tu teléfono. La razón es que las aplicaciones Java entran en juego después de cargar la máquina virtual zygote que maneja el bytecode de Java. Desde el bootloader hasta el zygote en el proceso de arranque, se ejecuta una enorme cadena de código nativo. Muchos procesos/servicios/demonios son iniciados por el proceso init que se ejecutan continuamente en segundo plano proporcionando muchas funcionalidades necesarias.

1 votos

Por nombrar algunos, están rild, netd, mediaserver, surfaceflinger, servicemanager, logd, etc. La mayor parte de este código es de código abierto; Google ha desarrollado AOSP y posiblemente también el código fuente del kernel (algunos proveedores no publican el código fuente del kernel). El SoC y el código relacionado con el hardware, incluidos los cargadores de arranque y los controladores o los blobs HAL, son de código cerrado, pero no es posible que contengan algún código anti-privacidad. Así que los principales culpables son las aplicaciones Java, en la mayoría de los casos. Al igual que los demonios de fondo, algunas aplicaciones esencialmente necesarias pueden estar relacionadas con AOSP y otras con el proveedor o el hardware.

2voto

Jack Wade Puntos 231

1. No se pueden eliminar todas las aplicaciones del sistema

Las aplicaciones del sistema no son sólo aplicaciones para ser utilizadas por los usuarios finales, sino que muchas de ellas no tienen ninguna interfaz de usuario y proporcionan algunas funcionalidades básicas del sistema operativo Android. Así que no se pueden eliminar. Por ejemplo SystemUI carga la interfaz de usuario básica, incluyendo la barra de estado, las notificaciones y el tema, mientras que Ajustes La aplicación hace lo que su nombre indica. Otros ejemplos de este tipo de aplicaciones profundamente integradas en el núcleo de Android son Bluetooth , ContactosProveedor , DocumentosUI , DescargaProvider , ExternalStorageProvider , Shell etc.

Aunque la mayoría de las aplicaciones del sistema son parte de AOSP, algunas pueden estar relacionadas con el proveedor o el hardware. Por ejemplo, en los dispositivos Qualcomm hay QtiTelephonyService , Servicio de tiempo y QCRilMsgTunnel etc. en /vendor/app/ . Los proveedores también pueden inyectar su propio código a las aplicaciones AOSP. SystemUI y Ajustes son casi siempre modificadas por los OEM de los dispositivos para proporcionar una interfaz de usuario y una configuración personalizadas. También lo son otras aplicaciones esencialmente necesarias como Lanzador , Teclado y Marcador aunque puedes sustituirlas por tus propias aplicaciones.

Por lo tanto, no siempre es posible en la práctica eliminar por completo las aplicaciones de bloatware, y la situación puede variar según los distintos proveedores, los distintos modelos de teléfono y las distintas versiones de Android. Una forma fácil de evitar la molestia de los intentos fallidos de desinstalación es utilizar una ROM personalizada de Android vainilla en un dispositivo rooteado con un kernel de código abierto y un bootloader desbloqueado.

2. El borrado de las aplicaciones puede no eliminar el dispositivo por completo

Si te preocupa demasiado el bloatware, eliminar sólo las aplicaciones (de sistema y/o de usuario) puede no ser suficiente para desinstalar completamente tu teléfono. Aunque en la mayoría de los casos las aplicaciones Java son las culpables y hay que tener más cuidado con las aplicaciones de código cerrado que suelen incluir los fabricantes de equipos originales, no es que los otros componentes de software en el dispositivo nunca puedan contener algún tipo de bloatware.

Las aplicaciones de Android se ejecutan en máquinas virtuales de tipo Java, por lo que entran en juego sólo después de la zygote está arriba. Pero desde el bootloader hasta zygote en el proceso de arranque, se ejecuta una enorme cadena de código nativo. El gestor de arranque inicia el kernel de Linux/Android, que inicia el primer proceso del espacio de usuario: init . init a su vez inicia muchos servicios nativos y demonios en segundo plano que proporcionan diferentes funcionalidades. Por nombrar algunos, están rild , netd , mediaserver , surfaceflinger , servicemanager , logd etc. zygote se inicia en el último.

La mayor parte de este código es de código abierto; Google desarrolla AOSP y una fuente de kernel común. Este último es modificado por los OEM de los dispositivos según el hardware de los mismos, pero no todos ellos liberan el código fuente del kernel. Los OEMs también pueden modificar la pila nativa de AOSP, aunque no es muy probable que contengan algún código anti-privacidad. Pero el SoC y el código relacionado con el hardware, incluidos los cargadores de arranque y los blobs binarios (HAL) en el espacio de usuario, son siempre de código cerrado. Y su el dispositivo puede ser controlado a distancia incluso si está apagado o incluso si no hay sistema operativo en él.

Así que es difícil evitar ser presa de las corporaciones y los servicios secretos con ánimo de lucro, a menos que se dejen de usar los gadgets. Para evitar cuerpos humanos rastreados o controlada a distancia podría ser el siguiente reto.

PreguntAndroid.com

PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X