¿Cómo utilizar el SDK de Android y las herramientas del proveedor de teléfonos inteligentes para iniciar otro kernel?

Question

He progresado un poco en la búsqueda de una solución:

1) Se borraron todos los datos del usuario de los dispositivos que se utilizarán para los experimentos (Arranque en modo de recuperación> borrar caché/borrar datos/restablecer valores de fábrica)

2) Consultado en fuentes no oficiales.

Hay varios artículos y publicaciones en foros en la red. Algunos de ellos son útiles. La mayoría de ellos son bastante antiguos y se actualizaron por última vez hace mucho tiempo. Lo malo es que la mayoría de ellos contienen información sobre cómo rootear los dispositivos (es decir, romper la seguridad del sistema operativo al instalar deliberadamente un rootkit que explota una vulnerabilidad conocida para aumentar sus privilegios) y enlaces a scripts que no son confiables o de baja reputación que contienen dichos rootkits. Esta información potencialmente dañina se mezcla con partes útiles que brindan una descripción general de las opciones disponibles.

Muchos artículos se publican en el sitio xda-developers.com, suforosección ywiki.

Algunos artículos útiles de la wiki:

Esos artículos wiki generalmente se mantienen bastante mal (las últimas ediciones fueron en 2015).

3) Elija la plataforma (x86, ASUS Zenfone2)

En mi caso, estaba eligiendo entre un grupo de mis propios dispositivos Android usados. La mayoría de ellos tienen CPU basadas en ARM. El último y más potente fue ASUS con CPU Intel x86 (conjunto de instrucciones de 64 bits). La otra razón para elegir x86 fue una mejor compatibilidad con Linux y el requisito de ejecutar contenedores lxc basados en x86/AMD64. Elegir ARM requeriría el desarrollo de una rama contenedora separada o el uso de algún tipo de herramientas de emulación/conversión (no estoy seguro de que dichas herramientas sean eficientes/bien mantenidas/soportadas).

4) Se dio cuenta de que el objetivo podría ser inalcanzable con herramientas oficiales (respaldadas por el proveedor)

Envié un correo electrónico al soporte técnico de ASUS sobre el uso de su herramienta de desbloqueo del gestor de arranque. Pero la respuesta fue simple: "La herramienta simplemente desbloquea el gestor de arranque, no podemos ayudarlo con más pasos, ni siquiera podemos decirle qué sucede si usa la herramienta". Es decir, la herramienta es inútil (ni siquiera sé si funcionó de alguna manera en mi caso y en qué se diferencia de fastboot oem unlock). Para activar la herramienta, primero tuve que cambiar a Android 5.0 ya que no era compatible con versiones más nuevas de ROM. Todo lo relacionado con cambiar el gestor de arranque y arrancar otras imágenes no es oficial, no tiene soporte, no se recomienda, incumple la garantía, etc.

5) [OPCIONAL: NOTA1] Elija e instale la recuperación (no es compatible oficialmente con el teléfono ni con el proveedor del sistema operativo)

'Recuperación'- es una jerga de Android para cargador de arranque/BIOS (una partición separada en la memoria del dispositivo que mantiene un sistema liviano basado en Linux que arranca primero y presenta un menú de cargador de arranque con herramientas disponibles como 'copia de seguridad', 'borrar caché', 'restablecimiento de fábrica', ' cargar ROM personalizada, etc.). La recuperación OEM original no permite actualizar una ROM personalizada ni iniciar un sistema operativo personalizado.

El proyecto parece maduro, bien estructurado, mantenido activamente y, en general, da la impresión de ser un valioso proyecto global de código abierto. La cantidad de dispositivos y proveedores compatibles es muynotable. Por supuesto, preferiría utilizar la versión de recuperación mantenida y respaldada por el proveedor del teléfono y descargada de su sitio oficial (en mi caso, ASUS).

NOTA 1:Después de instalar TWRP y obtener más información sobre las herramientas SDK, me di cuenta de que probablemente era posible actualizar una ROM personalizada sin instalar una recuperación personalizada (utilizando las herramientas adb y fastboot del paquete de herramientas de plataforma SDK).

NOTA 2:El proceso de instalación está bien documentado para cada modelo. Utilicé el 'Método de instalación Fastboot'. Breve descripción del método (consulte la página en el sitio TWRP correspondiente a su dispositivo): 1) Instale las herramientas del SDK de Android (solo necesitará los componentes adb y fastboot del paquete de herramientas de plataforma), 2) Active el 'modo de desarrollador' en su dispositivo tocando 7 veces en la línea 'Número de compilación' en el menú Configuración > Acerca de, 3) En Configuración > Opciones de desarrollador habilite la 'Depuración USB', 4) Conéctese con su PC a través de USB, 5) En su PC puede verificar que el el dispositivo está conectado pasando el comando adb devices, 6) Ejecute adb reboot bootloaderpara ingresar al modo fastboot, 7) Coloque el archivo de imagen correcto descargado del sitio TWRP y renombrado 'twrp.img' en la carpeta que contiene los binarios adb y fastboot (normalmente la carpeta 'platform-tools' ), 8) Ejecutar fastboot flash recovery twrp.img.En mi caso, la imagen se mostró correctamente aunque adb informó un error.FAILED (remote: Permission denied), 9) Correr fastboot reboot. También puede reiniciar su dispositivo desde el menú TWRP. Lo importante es permitir que TWRP parchee su ROM original (partición con sistema operativo Android) para evitar que borre TWRP y lo reemplace con la recuperación original después de que se inicie. De lo contrario tendrás que repetir el proceso. Sí, eso dio miedo, de ahí el paso n.° 1.

6) Profundizado en la documentación oficial de AOSP

Después de perder la esperanza de utilizar un enfoque de caja negra en el sistema operativo Android para alcanzar el objetivo, comencé a revisar las secciones generales sobre la arquitectura del sistema operativo Android y los requisitos para los dispositivos compatibles.

Buenas fotos (arquitectura):

Cargador de arranque e información de seguridad:

Conclusión principal:Android definitivamente ha introducido características útiles del sistema operativo para ejecutar un kernel de Linux reducido en una amplia gama de dispositivos propietarios (FMCG-world) con estándares de hardware flexibles. Una de las características más útiles que podría y probablemente debería adoptar la corriente principal de Linux es la capa de abstracción HAL, que permite lidiar con el zoológico de controladores propiciatorios de una manera razonable. También son notables los aspectos modulares del kernel, que consisten en dividir el kernel en partes dependientes del SoC y de la placa, así como funciones de ahorro de energía y funciones de seguridad.

Buenas noticias:Desarrolladores del kernel de Linux yalgunoLos proveedores de distribuciones conocen muy bien todas estas partes buenas y están haciendo todo lo posible para introducir los cambios correspondientes. Estadísticas oficiales (ver Figura 2 delsección correspondiente del documento AOSP) muestran buena evidencia de convergencia entre el código AOSP y la corriente principal de Linux. Hay un claro efecto económico positivo de la convergencia para ambas partes (comunidades AOSP y Linux). Cuando se trata de partes interesadas como Google y los productores de hardware que protegen sus inversiones, parecen ir en la dirección opuesta. Google protege sus inversiones en el ecosistema y la base de usuarios, los productores de hardware están protegiendo sus inversiones en el desarrollo y producción de hardware de alta gama. La fricción entre estas dos fuerzas crea una especie de vector positivo. En mi opinión, debería existir algún tipo de acuerdo entre Google y los productores de hardware que regule esta fricción de manera inteligente. Por ejemplo, los productores de hardware pueden retrasar la introducción de sus blobs de controladores específicos de la placa en el kernel de Linux durante, digamos, 2 o 3 años (para los blobs de controladores específicos de SoC, este período quizás debería ser más corto). Esto garantizaría a los desarrolladores de Google y AOSP que el ecosistema Android se lleva toda la crema del mercado (todas las compras de nuevos dispositivos modernos de hardware de alta gama, ingresos por publicidad, software pago y servicios de usuarios de alta gama). Después de esos 2 o 3 años, los dispositivos (que ya no se consideran de alta gama) se lanzan de forma gratuita al enviar los controladores a Linux (los proveedores de hardware de mayor calidad, por supuesto, preferirían enviar el código fuente). La duración del período es bastante cercana al período de garantía habitual establecido para la mayoría de los dispositivos por los proveedores de hardware y un período de actualizaciones oficiales de Android (incluidas las actualizaciones de seguridad) distribuidas por esos proveedores. Me parece bien.

Malas noticias:Parece muy difícil negociar un acuerdo así.(en adelante, el Acuerdo)de manera sabia y explícita. El principal problema está en su naturaleza global. Piense en las posibles consideraciones legales (leyes antimonopolio en varias jurisdicciones, cuestiones fiscales transfronterizas, etc., etc.), número de proveedores de hardware (OEM, ODM, productores de SoC, etc., etc.) y otras partes interesadas involucradas (Google, AOSP, Android). desarrolladores, Linux, proveedores de distribuciones de Linux (servidor, escritorio y posiblemente dispositivos móviles, otros proyectos basados en Linux, GNU, FSF, etc., etc. hasta los usuarios finales). La falta de un acuerdo definitivamente está desacelerando la convergencia entre Linux y AOSP, para nuestro pesar común (los usuarios). Desde el punto de vista del hardware, la convergencia total fue posible hace varios años cuando los dispositivos convencionales [CPU x86 multinúcleo / > 2 Gb de RAM / > unidad flash de 16 Gb] llegaron al mercado. El problema es evidente cuando este hardware no se puede utilizar para ejecutar un kernel de Linux estándar (una distribución de servidor, ni siquiera de escritorio). Los instaladores no están disponibles, las herramientas de actualización no cuentan con soporte oficial de los proveedores y la documentación es escasa y dispersa. En junio de 2019 las cosas podrían ir mucho mejor...

7) El siguiente paso sería monitorear los esfuerzos realizados por las principales comunidades impulsadas por la conversión y los proveedores de soporte, así como los pasos realizados por los proveedores de hardware y AOSP/Google para negociar el acuerdo.

Answer 1