¿Hay alguna forma de arrancar un teléfono Android* desde una unidad USB alimentada por bus**? Si es así, ¿cuáles son los pasos para conseguirlo?
* Por ejemplo, uno con funcionalidad USB OTG.
** Por ejemplo, una unidad flash.
¿Hay alguna forma de arrancar un teléfono Android* desde una unidad USB alimentada por bus**? Si es así, ¿cuáles son los pasos para conseguirlo?
* Por ejemplo, uno con funcionalidad USB OTG.
** Por ejemplo, una unidad flash.
Por favor, aclare cuál es el objetivo previsto y por qué.
Los teléfonos Android tienen sus propios cargadores de arranque y no pueden ser anulados por otros medios.
No es como la BIOS de un PC donde se puede cambiar el orden de arranque para arrancar desde ciertos dispositivos como PXE de red, USB, H.D.D. primario/secundario...
Después de los comentarios de abajo, y en relación con la pregunta del OP
¿Hay alguna manera de arrancar 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 con el fin de cargar en cadena en la recuperación o para arrancar directamente en el entorno de Android (Al mantener la tecla Vol + Abajo en este caso) - en pseudo-código ( ¡esto es desde el contexto/aspecto de lk, y también, las direcciones de memoria pertenecientes a cómo leer las particiones están codificadas en este lk para que sepa cómo procesar la lógica! )
El kernel lk es el estándar de facto de Qualcomm para los conjuntos de chips MSM (Snapdragon) y adoptado por fabricantes como Sony, Motorola, LG, Samsung y se puede encontrar en la fuente AOSP bajo bootable/bootloader
.
si ( ¿Se ha pulsado la tecla de bajar el volumen? ) entonces
/recovery
partición en una dirección particular en la memoria y saltar a ella y comenzar la ejecución, en traer el entorno de recuperaciónsi no
/system
en una dirección particular en la memoria y saltar a ella y comenzar la ejecución en traer el entorno de Android.fin de si.
Como el núcleo dentro de lk es bastante limitado, teniendo en cuenta que la imagen binaria del núcleo se graba en el chip y por lo tanto no hay manera de modificarlo . Y también hay que mencionar que lk contiene el fastboot
protocolo para la preparación de los flashes /boot
, /recovery
, /system
y /data
particiones. Hay dos secuencias para arrancar, el arranque primario y el arranque secundario como es:
/boot
o /recovery
Nota al margen: Samsung es aficionado al PBL/SBL (que es Primary Boot Loader y Secondary Boot Loader respectivamente) en su jerga cuando se trata de modding. La cosa con Samsung es que, en algunos teléfonos, el PBL y el SBL pueden estar encriptados (el Samsung Wave GT-S8500 es un ejemplo de ello, donde portar Android a él era casi imposible de hacer debido al DRM dentro de los cargadores de arranque que era una pesadilla para tratar e hizo modding extremadamente difícil, sin embargo, está funcionando a través de un exploit en el código de la FOTA)
Esta es la razón por la que no hay facilidades extra como la funcionalidad OTG o cualquier otra cosa como las comunicaciones en serie, la lectura de la SDCard, los gráficos, etc, ya que haría el kernel lk más grande de lo que se pretende. En otras palabras, es el tamaño más pequeño posible del kernel que está designado para hacer sólo lo que sucede en el pseudo-código anterior.
Además, otra forma de verlo es esta, y esto depende de la versión de Android, la funcionalidad USB OTG es totalmente trajo dentro del entorno Android, es decir, cuando aparece la conocida pantalla de inicio, entonces La funcionalidad de OTG está activada. Lamentablemente no es el caso cuando se mira desde la perspectiva de lk.
Si tienes curiosidad, aquí tienes la Entrada de Qualcomm en el lk anterior, que es una parte del pequeño código fuente en C que tiene incluido el ensamblaje ARM y que se encuentra en el código fuente AOSP de JellyBean en bootable/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;
}
La cuestión del huevo y la gallina aquí: I quería una respuesta a mi pregunta para limitar los casos de uso en función de la viabilidad; usted me piden que dé casos de uso primero :) Así que, por ahora, sólo puedo aclarar vagamente mi(s) objetivo(s). Uno de ellos podría ser conseguir algo como el cifrado completo del disco arrancando desde una unidad USB cifrada por hardware (Lok-It/dataShur/etc), de modo que al introducir un código de acceso en la unidad se evite la necesidad de introducir una contraseña de descifrado en el dispositivo Android. Lo ideal sería que, una vez arrancado el teléfono, se pudiera retirar la unidad, dejando que el teléfono siguiera funcionando bien hasta el siguiente reinicio.
Bien... Interesante - nunca he oído hablar de un caso así - de todos modos - ¿por qué? Para reflexionar, donde ¿introducirías un código de acceso de este tipo? Android ICS tiene la capacidad de encriptar todo el volumen IIRC - ¿No has mirado en eso?
El código de acceso se introduciría mediante el teclado integrado en la unidad. (Si no sabes a qué me refiero con esto, busca las unidades que he mencionado.) Y sí, he investigado el cifrado incorporado de Android, pero (a) no está exento de inconvenientes (véase, por ejemplo. security.stackexchange.com/q/10529 ; v.gd/6hOcmd ), (b) no funciona en todos los teléfonos, incluso en los que tienen ROMs ICS+ disponibles de los fabricantes (por ejemplo, algunos modelos Xperia), y (c) hay otros casos de uso potencial para los que sería deseable poder arrancar un teléfono/tablet desde un dispositivo de almacenamiento masivo USB.
Sin embargo, es posible en cierto sentido. Dadas las limitaciones mencionadas en la respuesta de @t0mm13b, tiene sentido que el mencionado gestor de arranque (lk) sea incapaz de hacerlo. Así que, 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 las modernas recuperaciones personalizadas como TWRP que tienen tanto soporte OTG como (en algunos casos) MultiROM.
De hecho, esto se ha utilizado para arrancar Ubuntu en una tablet Nexus 9, utilizando el método:
fastboot boot <otg_chainloader_kernel>
<otg_chainloader_kernel>
arranca y habilita el OTG y espera a que se conecte el dispositivo OTG.<otg_chainloader_kernel>
detecta un kernel Linux válido en el dispositivo OTG y le pasa el control después de cargarlo en cadena en la memoria.Ahora bien, si quisieras, podrías arrancar una imagen ROM de Android compatible de forma similar, pero recuerda que la unidad OTG tendría que mantenerse conectada al dispositivo hasta que decidieras volver al SO nativo (ya que todas las aplicaciones se cargarían desde, 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 (¿has oído hablar de Puppy Linux?), lo cual, dadas las capacidades de memoria actuales de los dispositivos Android comunes y el tamaño de la propia ROM es actualmente poco práctico). Eso impide cargar mientras se arranca con el sistema operativo OTG, también, en la mayoría de los dispositivos con puertos de datos/carga unificados.
Fuente: Subforo XDA-Developers Nexus 9
@SuiciDoga, ¿supongo que TWRP MultiROM es compatible con el arranque OTG? Utiliza la técnica anterior AFAIK, sólo que sin todo el fastboot
s. El kexec-hardboot
El parche para el kernel utilizado por TWRP MultiROM es básicamente el OTG-Chainloader-Kernel
Hablo de.
¡¡¡¡es posible y lo hice en mi acer iconia tablet!!!!
conecte un pendrive a su pc y formatee a fat32 usa rufus para portar la iso/dd a tu pendrive
conéctalo al otg y a tu teléfono/tablet.. Mantenga la tecla de encendido y pulse el volumen hacia abajo si no arranca intente mantener la tecla de encendido y pulse el volumen hacia arriba
luego usando las teclas de volumen muévase a UDisk (su marca de 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 varios problemas con el arranque en el menú, así que de alguna manera me las arreglé para evitar el kernel para arrancar y por eso detener el Android para arrancar
Creo que fue así: me conecté a la PC, luego borré todos los datos de la tablet, pero copiando la carpeta de Android
se quitó el kernel y después de arrancar se conectó de nuevo al pc con un hub usb
bueno espero haber ayudado :)
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.