En Android casi todos los fabricantes incluyen su propia colección de aplicaciones «muy necesarias». Una marca instala tres tiendas, otra añade duplicados de la aplicación de llamadas y de la galería, una tercera regala generosamente una selección de software de socios que el usuario no pidió. En algún momento el propietario del smartphone abre la lista de aplicaciones y comprende una cosa sencilla: la mitad del conjunto solo ocupa espacio, está en memoria y molesta por el hecho mismo de existir.
Mediante ADB parte de los paquetes preinstalados no solo se pueden desactivar, sino también quitar del perfil de usuario actual sin acceso root. El método es conocido desde hace tiempo, pero en torno al tema todavía hay mucha confusión. Unas instrucciones prometen «eliminación completa para siempre», otras proponen borrar todo a la vez, incluidos componentes del sistema, tras lo cual el smartphone empieza a comportarse como un ladrillo muy caro.
En la práctica el esquema es más prosaico. ADB ofrece acceso por comandos al dispositivo, y el gestor de paquetes de Android permite desactivar una aplicación para el usuario o eliminar un paquete precisamente del espacio de usuario. La partición del sistema en ese escenario normalmente no se reescribe, por lo que se trata más de una configuración cuidadosa que de cirugía. En manos habilidosas el método es útil; en manos inexpertas, estimulante.
A continuación se detalla todo el proceso: por qué tocar las aplicaciones del sistema, en qué se diferencia desactivar de eliminar, qué comandos usar, qué es mejor no tocar y cómo recuperar un paquete si el experimento fue más lejos de lo previsto.
Por qué se eliminan o desactivan aplicaciones del sistema
La razón principal es sencilla: el software preinstalado a menudo duplica funciones de Android o de los servicios de Google. En un smartphone pueden convivir dos galerías, dos tiendas de aplicaciones, varios asistentes de voz, un navegador propio y un conjunto de servicios publicitarios del fabricante. El usuario no utiliza la mitad de los paquetes, pero el sistema sigue almacenándolos, actualizándolos y ejecutándolos de vez en cuando.
La segunda razón son los recursos. No todas las aplicaciones del sistema consumen constantemente batería y memoria, pero algunos paquetes permanecen en segundo plano, escuchan eventos del sistema, envían telemetría, comprueban actualizaciones o muestran recomendaciones. En dispositivos antiguos y de gama baja ese lastre se nota con rapidez. Android sabe ahorrar recursos por sí mismo, pero el software extra no mejora el rendimiento.
La tercera razón es el orden. Cuando en el menú de aplicaciones desaparecen servicios innecesarios, el smartphone se vuelve más limpio y comprensible. El usuario ve solo el conjunto que usa realmente. Para muchos propietarios de Android el argumento puede no ser muy técnico, pero es honesto: menos basura, menos irritación.
También existe un escenario corporativo cauteloso. A veces mediante ADB se desactivan paquetes de demostración, tiendas propias, servicios multimedia impuestos y otros componentes prescindibles en dispositivos de trabajo. Android soporta la gestión de paquetes y usuarios a nivel del sistema, y ADB actúa como herramienta estándar de acceso al dispositivo para desarrolladores y administradores.
Pero el enfoque tiene límites. No es necesario eliminar todo por una «limpieza máxima». Algunos paquetes parecen inútiles, aunque en realidad responden de llamadas, notificaciones, la interfaz, Bluetooth, actualizaciones, sincronización, cámara o el funcionamiento de los ajustes. El error es frecuente: alguien ve un nombre de paquete desconocido, decide que es basura y en un minuto se queda sin el lanzador funcional.
Desactivar y eliminar mediante ADB no es lo mismo
La bifurcación más importante es esta. Desactivar hace que el paquete quede inactivo para el usuario seleccionado. El icono desaparece, la aplicación no se inicia y el sistema deja de considerar el paquete operativo. Eliminar con el parámetro --user 0 quita el paquete del usuario actual, pero no siempre borra la aplicación de la partición del sistema. Tras un restablecimiento o una actualización de firmware algunos paquetes pueden volver.
Por eso la expresión «eliminar completamente una aplicación del sistema sin root» suena bien, pero no siempre es precisa. Sin desbloquear el sistema el usuario suele controlar la visibilidad y la disponibilidad del paquete para su perfil, no extirpar el componente de la firmware de forma definitiva. Para la mayoría de los escenarios ese comportamiento es suficiente. Si la aplicación no se ve, no se actualiza y no molesta, el objetivo práctico ya está logrado.
| Acción | Qué hace | Ventaja | Riesgo |
|---|---|---|---|
| Desactivación | Desactiva el paquete para el usuario | Fácil de restaurar | No todos los paquetes se pueden desactivar |
| Desinstalación con --user 0 | Elimina el paquete del perfil del usuario 0 | Lista de aplicaciones más limpia | A veces es más difícil restaurarlo sin ejecutar una reinstalación |
Si la tarea consiste en un debloat cuidadoso sin aventuras, es mejor empezar por la desactivación. Esa opción es más segura y más fácil de revertir. La eliminación para el usuario tiene sentido cuando el paquete no hace falta y el propietario del dispositivo sabe cómo restaurar la aplicación.
Otro matiz está relacionado con los usuarios en Android. La documentación describe por separado el trabajo de ADB en un entorno multiusuario. Los comandos del gestor de paquetes pueden aplicarse a un usuario concreto mediante el indicador --user, y por defecto muchas operaciones se orientan al usuario del sistema. En smartphones normales con más frecuencia se usa user 0.
Cómo preparar el smartphone y qué comandos usar
Primero hay que activar el modo desarrollador y la depuración USB en el dispositivo. En las versiones modernas de Android la depuración ADB se activa en la sección de opciones de desarrollador. En Android 4.2 y posteriores el menú de desarrollador está oculto por defecto y suele abrirse pulsando varias veces sobre el número de compilación. En Windows en algunos dispositivos también se necesita el controlador USB correcto del fabricante o el Google USB Driver.
Luego en el ordenador harán falta Android SDK Platform Tools. Tras conectar el smartphone conviene comprobar la conexión con el comando:
adb devices
Si el dispositivo aparece en la lista, se puede pasar a ver los paquetes. El comando básico es:
adb shell pm list packages
Para buscar paquetes desactivados o activados, el gestor de paquetes de Android soporta claves adicionales, incluyendo -d para disabled y -e para enabled. Para trabajar con un usuario específico se puede indicar explícitamente --user.
adb shell pm list packages -d
adb shell pm list packages -e
adb shell pm list packages --user 0
Si se encuentra el paquete deseado, la desactivación normalmente se realiza así:
adb shell pm disable-user --user 0 nombre.del.paquete
En la documentación de Android para el gestor de paquetes también aparecen los comandos disable, disable-user y enable, y disable-user acepta el indicador --user. Para devolver la aplicación valdría:
adb shell pm enable nombre.del.paquete
Si el propietario del dispositivo quiere quitar el paquete exactamente del perfil de usuario, se usa otra orden:
adb shell pm uninstall --user 0 nombre.del.paquete
El comando elimina el paquete para el usuario seleccionado. En la práctica el escenario con user 0 es el más habitual, es decir, para el perfil principal del smartphone. En la descripción oficial de ADB el indicador --user user_id figura explícitamente en el comando uninstall.
Antes de cualquier cambio es sensato guardar la propia lista de comandos en un archivo de texto. Mejor aún: primero desactivar la aplicación, observar el sistema durante uno o dos días y solo después decidir la eliminación para el usuario. Ese orden es aburrido, pero reduce mucho la posibilidad de encontrarse con un restablecimiento de fábrica no planeado.
Qué aplicaciones es mejor no tocar y cómo revertir cambios
Hay categorías de paquetes que es preferible dejar en paz si no se entiende exactamente su papel. En el grupo de riesgo están la interfaz del sistema, el lanzador, el teléfono, los contactos, el servicio de mensajes, Bluetooth, la cámara, los ajustes, los servicios de actualización, los servicios de sincronización, el paquete instalador de aplicaciones y componentes de la capa del fabricante. Incluso un nombre de paquete que parece inofensivo puede corresponder a un módulo crítico.
La precaución es especialmente importante en ROMs de Samsung, Xiaomi, realme, OnePlus y otras marcas, donde las funciones del sistema suelen estar ligadas a servicios propios. La eliminación de un paquete publicitario puede salir perfecta, mientras que borrar un «agente del sistema desconocido» rompe de repente Always On Display, la tienda de temas, gestos, la grabación de llamadas o la comprobación de actualizaciones. Android es modular desde hace tiempo, pero no hasta niveles de magia.
La lógica segura es:
- primero averiguar el nombre exacto del paquete;
- comprobar de qué se encarga la aplicación;
- empezar por desactivar, no por eliminar;
- no tocar paquetes relacionados con la interfaz, la conectividad o la seguridad;
- registrar todos los comandos que se hayan ejecutado.
Si se desactivó una aplicación, restaurar el paquete suele ser más sencillo con el comando adb shell pm enable nombre.del.paquete. Si el paquete se eliminó para el usuario, la recuperación depende del firmware y del estado del paquete. En algunos dispositivos ayuda reinstalar el paquete del sistema para el usuario mediante el gestor de paquetes; en otros es más fácil hacer un restablecimiento de ajustes. Por eso la regla «primero disable, luego pensar» sigue vigente no por capricho, sino por la dura estadística de experimentos de usuarios.
En resumen, ADB sigue siendo una de las maneras más cómodas de poner Android en orden sin acceso root. El método es útil cuando el propietario del smartphone quiere quitar el software preinstalado, aligerar la interfaz y reducir la cantidad de software en segundo plano. Pero ADB exige disciplina. Los comandos actúan rápido, no perdonan errores y no preguntan «¿está seguro?». Por eso el mejor debloat empieza no con heroísmos, sino con cuidado.
Desactivar correctamente las aplicaciones del sistema mediante ADB ofrece exactamente el resultado que la mayoría de usuarios necesita: menos cosas innecesarias, menos ruido y más control sobre el dispositivo. En cambio, intentar una limpieza total por deporte suele acabar al estilo típico de Android: divertido, estresante y con búsqueda de instrucciones para la recuperación.
FAQ
¿Cómo eliminar aplicaciones del sistema en Android mediante ADB sin root?
Hay que activar el modo desarrollador, habilitar la depuración USB, instalar Platform Tools en el ordenador, conectar el smartphone y usar un comando como adb shell pm uninstall --user 0 nombre.del.paquete. Este método normalmente elimina el paquete del perfil de usuario, no de la partición del sistema.
¿Qué es más seguro, desactivar una aplicación via ADB o eliminarla con --user 0?
Es más seguro desactivar. El comando disable-user es más fácil de revertir y provoca menos efectos secundarios desagradables. La eliminación para el usuario conviene solo después de comprobar que el smartphone funciona correctamente sin el paquete en cuestión.
¿Se puede recuperar una aplicación del sistema tras eliminarla con ADB?
En muchos casos sí, pero el método depende del firmware y del estado del paquete. Tras una desactivación habitual ayuda adb shell pm enable nombre.del.paquete. Tras una eliminación para el usuario la restauración a veces requiere un comando específico del gestor de paquetes o, en otros casos, es más sencillo un restablecimiento de ajustes.
¿Qué aplicaciones del sistema no se deben eliminar mediante ADB?
Mejor no tocar el lanzador, la interfaz del sistema, los ajustes, el teléfono, los contactos, Bluetooth, la cámara, los servicios de actualización, el instalador de aplicaciones y los componentes de los que depende la capa del fabricante. Si el propósito de un paquete es desconocido, conviene estudiarlo primero.
¿Por qué reaparecen las aplicaciones del sistema después de eliminarlas?
Una causa habitual es que el paquete se eliminó solo para el usuario y no de la partición del sistema. Tras una actualización de firmware, un restablecimiento de ajustes o algunos parches importantes, el fabricante puede volver a activar o reinstalar el paquete preinstalado.