¿Es posible iniciar un teléfono Android desde una unidad USB?

¿Hay alguna forma de iniciar un teléfono Android* desde una unidad USB alimentada por bus**? Si es así, ¿cuáles son los pasos para lograrlo?

* Por ejemplo, uno con funcionalidad USB OTG.

** Por ejemplo, una unidad flash.

Respuestas (3)

Por favor, aclare cuál es el objetivo previsto y por qué.

Los teléfonos Android tienen sus propios cargadores de arranque y no se pueden anular por otros medios.

No es como el BIOS de una PC donde puede cambiar el orden de arranque para arrancar desde ciertos dispositivos como Red PXE, USB, HDD primario/secundario...

Editar:

Después de los comentarios a continuación, y en relación con la pregunta del OP

¿Hay alguna forma de iniciar un teléfono Android (por ejemplo, uno con funcionalidad USB OTG) a través de una unidad USB alimentada por bus?

El cargador de arranque genérico (*que reside en el conjunto de chips) no tiene conocimiento de USB, etc., ya que el lk (Little Kernel) está más preocupado por atrapar las pulsaciones de teclas para cargar en cadena en la recuperación o arrancar directamente en el entorno de Android. (Al mantener presionada la tecla Vol + Abajo en este caso) - en pseudocódigo ( esto es del contexto/aspecto de lk, y también, las direcciones de memoria relacionadas con cómo leer las particiones están codificadas en este lk por lo que saber cómo procesar la lógica! )

El kernel lk es el estándar de facto de Qualcomm para conjuntos de chips MSM (Snapdragon) y adoptado por fabricantes como Sony, Motorola, LG, Samsung y se puede encontrar en la fuente AOSP en bootable/bootloader.

si ( ¿Se presionó la tecla para bajar el volumen? ) , entonces

  • encadene el kernel de la /recoverypartición a una dirección particular en la memoria y salte a él y comience la ejecución, al abrir el entorno de recuperación

más

  • encadene el kernel de carga desde la /systempartición a una dirección particular en la memoria y salte a él y comience la ejecución para abrir el entorno de Android.

terminara si.

Como el kernel dentro de lk es bastante limitado, teniendo en cuenta que la imagen binaria del kernel está grabada en el chip y, por lo tanto, no hay forma de modificarla . Y también debe mencionarse que lk contiene el fastbootprotocolo en preparación para flashear , /booty /recoveryparticiones . Hay dos secuencias para arrancar, arranque primario y arranque secundario tal cual:/system/data

  • Arranque primario -> lk (dependiendo del resultado de la lógica)
  • Vaya a Arranque secundario -> /booto/recovery

Nota al margen: a Samsung le gusta el PBL/SBL (que es el cargador de arranque principal y el cargador de arranque secundario, respectivamente) en su jerga cuando se trata de modding. Lo que pasa con Samsung es que, en algunos teléfonos, PBL y SBL pueden estar encriptados (Samsung Wave GT-S8500 es uno de esos ejemplos, donde era casi imposible portar Android a él debido al DRM dentro de los cargadores de arranque, lo cual era una pesadilla). para manejar y hacer que modificarlo sea extremadamente difícil, sin embargo, ¡es una especie de trabajo a través de un exploit en el código FOTA!)

Esta es la razón por la que no hay instalaciones adicionales, como la funcionalidad OTG o cualquier otra cosa, como comunicaciones en serie, lectura de SDCard, gráficos, etc., ya que haría que el kernel lk fuera más grande de lo previsto. En otras palabras, es el tamaño de kernel más pequeño posible el que está designado para hacer que suceda el pseudocódigo anterior.

Además, otra forma de verlo es esta, y depende de la versión de Android: la funcionalidad USB OTG aparece completamente en el entorno de Android, es decir, cuando aparece la pantalla de inicio familiar, la funcionalidad OTG está habilitada. Desafortunadamente, no es el caso cuando se mira desde la perspectiva de lk.

Si tiene curiosidad, aquí está la entrada de Qualcomm en el lk anterior, que es parte de la pequeña fuente C que tiene el ensamblaje ARM incluido y se encuentra en la fuente AOSP de JellyBean enbootable/bootloader/legacy/usbloader/main.c

int boot_linux_from_flash(void)
{
    boot_img_hdr *hdr = (void*) raw_header;
    unsigned n;
    ptentry *p;
    unsigned offset = 0;
    const char *cmdline;

    if((p = flash_find_ptn("boot")) == 0) {
        cprintf("NO BOOT PARTITION\n");
        return -1;
    }

    if(flash_read(p, offset, raw_header, 2048)) {
        cprintf("CANNOT READ BOOT IMAGE HEADER\n");
        return -1;
    }
    offset += 2048;
    
    if(memcmp(hdr->magic, BOOT_MAGIC, BOOT_MAGIC_SIZE)) {
        cprintf("INVALID BOOT IMAGE HEADER\n");
        return -1;
    }

    n = (hdr->kernel_size + (FLASH_PAGE_SIZE - 1)) & (~(FLASH_PAGE_SIZE - 1));
    if(flash_read(p, offset, (void*) hdr->kernel_addr, n)) {
        cprintf("CANNOT READ KERNEL IMAGE\n");
        return -1;
    }
    offset += n;

    n = (hdr->ramdisk_size + (FLASH_PAGE_SIZE - 1)) & (~(FLASH_PAGE_SIZE - 1));
    if(flash_read(p, offset, (void*) hdr->ramdisk_addr, n)) {
        cprintf("CANNOT READ RAMDISK IMAGE\n");
        return -1;
    }
    offset += n;
    
    dprintf("\nkernel  @ %x (%d bytes)\n", hdr->kernel_addr, hdr->kernel_size);
    dprintf("ramdisk @ %x (%d bytes)\n\n\n", hdr->ramdisk_addr, hdr->ramdisk_size);

    if(hdr->cmdline[0]) {
        cmdline = (char*) hdr->cmdline;
    } else {
        cmdline = board_cmdline();
        if(cmdline == 0) {
            cmdline = "mem=50M console=null";
        }
    }
    cprintf("cmdline = '%s'\n", cmdline);
    
    cprintf("\nBooting Linux\n");

    create_atags(ADDR_TAGS, cmdline,
                 hdr->ramdisk_addr, hdr->ramdisk_size);
    
    boot_linux(hdr->kernel_addr);
    return 0;
}
Problema de gallina/huevo aquí: quería una respuesta a mi pregunta para reducir los casos de uso en función de la viabilidad; me está pidiendo que dé casos de uso primero :) Entonces, solo puedo aclarar mis objetivos vagamente por ahora. Una podría ser lograr algo como el cifrado de disco completo arrancando desde una unidad USB cifrada por hardware (Lok-It/dataShur/etc), de modo que ingresar un código de acceso en la unidad evite la necesidad de ingresar una contraseña de descifrado en el dispositivo Android. Idealmente, esto podría hacerse de tal manera que, una vez que se inicie el teléfono, se pueda quitar la unidad, dejando que el teléfono siga funcionando correctamente hasta el próximo reinicio.
Cierto... Interesante - nunca he oído hablar de un caso como ese - de todos modos - ¿por qué? Algo para pensar, ¿ dónde ingresaría un código de acceso de este tipo? Android ICS hacia arriba tiene la capacidad de cifrar todo el volumen IIRC. ¿No ha investigado eso?
El código de acceso se ingresaría utilizando el teclado integrado en la unidad. (Si no sabe a qué me refiero con esto, busque las unidades que mencioné). Y sí, he investigado el cifrado integrado de Android, pero (a) no está exento de inconvenientes (ver, por ejemplo, security. stackexchange.com/q/10529 ; v.gd/6hOcmd ), (b) no funciona en todos los teléfonos, incluso en aquellos que tienen ROM ICS+ disponibles de los fabricantes (por ejemplo, algunos modelos de Xperia), y (c) hay otros posibles casos de uso en los que sería deseable poder arrancar un teléfono/tableta desde un dispositivo de almacenamiento masivo USB.
Para ser sincero, eso no se puede lograr, para empezar, no existe un cargador de arranque de teléfono inteligente que simplemente, desde una perspectiva de alto nivel, "haga una pausa" hasta que se ingrese un código de acceso. ¡Lo que está pidiendo está más allá de este foro y requiere un nicho especializado, si no, de cargadores de arranque personalizados para lograrlo! Para empezar, el gestor de arranque genérico, lk (está en AOSP bajo bootable/bootloader) es adoptado de facto por Qualcomm para sus conjuntos de chips, que es utilizado por empresas como Sony, LG, Motorola, por nombrar solo algunos... solo digo, la pregunta no es constructiva!
Por cierto, no veo la mención de las unidades que afirmaste haber mencionado....?
Di dos ejemplos: Lok-It y dataShur . Ambos tienen teclados integrados.
Lok-It está encriptando la unidad flash, al igual que dataShur, ¡de un vistazo! Cifra el contenido en él... aún así, mantengo mis comentarios... :)
Soy muy consciente de que Lok-It y dataShur encriptan solo su propio contenido: esa es toda su razón de ser . Estoy agradecido por su intento de ayudar, pero temo que se haya distraído con mi caso de uso sugerido, que (1) no es muy relevante para mi q, y (2) parece haber entendido mal de todos modos. (Seguramente mi culpa en el último frente: ¡difícil de articular el caso de uso a través de comentarios breves!). Estaría aún más agradecido si pudiera olvidarse de los códigos de acceso y volver a mi consulta inicial y simple: ¿hay alguna forma de iniciar un teléfono Android desde una unidad USB alimentada por bus y, de ser así, cuáles son los pasos para lograrlo? ?
En resumen, no hay forma de hacerlo, parece que olvida el énfasis en mis comentarios en relación con el cargador de arranque y el hecho de que los teléfonos inteligentes tampoco tienen BIOS ... solo digo.
Gracias por desarrollar tu respuesta. Claramente, esperaba que hubiera alguna forma de iniciar un dispositivo Android desde el almacenamiento masivo USB, por ejemplo, desde el modo de cargador de arranque o el modo de recuperación del sistema o algo como BootManager o similar, pero parece que no la hay. Lástima. Gracias de nuevo por tomarse el tiempo para responder!
En realidad, es técnicamente posible arrancar en un pequeño sistema similar a un BIOS en el dispositivo y luego montar dispositivos USB de forma transparente y proceder a arrancar desde allí, para responder a su pregunta. Pero sí, no podrá hacerlo sin acceso ilimitado al dispositivo.
@t0mm13b. Disculpas por ser OT, pero eso de Samsung me llamó la atención. ¿Es aplicable a mi pregunta aquí? De ser así, ¿consideraría amablemente responderla? android.stackexchange.com/questions/127826/…
¿Hay alguna manera de reemplazar el sistema con una distribución diferente y mantener este cargador de arranque?

Sin embargo, es posible en cierto sentido. Dadas las limitaciones mencionadas en la respuesta de @ t0mm13b, tiene sentido que el cargador de arranque mencionado (lk) no pueda hacer esto. Entonces, arrancamos un kernel personalizado desde fastboot(para pruebas), que arranca, habilita la funcionalidad OTG y una vez que se encuentra un kernel válido en el dispositivo OTG que está conectado, lo carga en cadena en la memoria y le pasa el control. Esto probablemente podría incluso integrarse en recuperaciones personalizadas modernas como TWRP que tienen soporte OTG y (en algunos casos) MultiROM.

En realidad, esto se ha utilizado para iniciar Ubuntu en una tableta Nexus 9, utilizando el método:

  1. fastboot boot <otg_chainloader_kernel>
  2. <otg_chainloader_kernel>arranca y habilita OTG y espera a que se conecte el dispositivo OTG.
  3. El dispositivo está desconectado de la PC y la unidad flash USB que tiene una imagen de arranque de Ubuntu está conectada a través de OTG.
  4. <otg_chainloader_kernel>detecta un kernel de Linux válido en el dispositivo OTG y le pasa el control después de cargarlo en cadena en la memoria.

Ahora, si quisiera, podría iniciar una imagen ROM de Android compatible de manera similar, pero recuerde que la unidad OTG deberá mantenerse conectada al dispositivo hasta que decida volver al sistema operativo nativo (ya que todas las aplicaciones se cargarán). y todos los datos se escribirían en la unidad flash USB, a menos que toda la ROM de Android pudiera configurarse como un ramdisk (¿alguna vez has oído hablar de Puppy Linux?), lo cual, dadas las capacidades de memoria actuales de los dispositivos Android comunes y el tamaño del La ROM en sí es actualmente poco práctica). Eso también impide la carga mientras se inicia el sistema operativo OTG, en la mayoría de los dispositivos con puertos de carga/datos unificados.

Fuente: subforo XDA-Developers Nexus 9

¿Podría ser posible hacer esto para Android para poder iniciar la vista previa de N sin instalar?
@SuiciDoga, ¿supongo que TWRP MultiROM es compatible con el arranque OTG? Utiliza la técnica anterior AFAIK, solo que sin todos los fastboots. El kexec-hardbootparche para el kernel que usa TWRP MultiROM es básicamente del OTG-Chainloader-Kernelque hablo.
Ahora, eso también depende del dispositivo en el que desee probar este ejercicio. El Nexus 9 y el Nexus Player tienen TWRP, pero MultiROM no funciona en ellos (¿problemas con x64/ARM64?). IDK sobre el Nexii actual, también.

es posible y lo hice en mi tablet acer iconia!!!!

conecte una unidad flash a su PC y formatéela en fat32 use rufus para transferir el iso/dd a su unidad flash

conéctelo a otg y a su teléfono / tableta ... mantenga presionada la tecla de encendido y toque el volumen hacia abajo si no arranca, intente mantener presionada la tecla de encendido y toque el volumen hacia arriba

luego, usando las teclas de volumen, muévase a UDisk (la marca de su unidad flash) o SATA; UDISK (no tiene que ser su marca usb, puede decir almacenamiento usb) y haga clic en la tecla de encendido para confirmar

bueno, tuve serios problemas para arrancar en el menú, así que de alguna manera logré evitar que el kernel arrancara y con eso detuve el arranque de Android

Creo que fue así: me conecté a la PC, luego eliminé todos los elementos de la tableta, pero copié la carpeta de Android

Se eliminó el kernel y después del arranque se conectó nuevamente a la PC con un concentrador USB

bueno espero haber ayudado :)

Debe ser un SoC excepcional, podría ser compatible con UEFI. No muchos SoC utilizados en estos días en dispositivos Android le permiten configurar el orden de arranque.