Android - Is it possible to boot an Android phone from a USB drive?

Please clarify what is the intended goal and why?

Android phones have their own boot-loaders and cannot be overridden by other means.

It is not like a PC's BIOS where you can switch the ordering of boot to boot from certain devices such as Network PXE, USB, Primary/Secondary H.D.D...

Edit:

After the comments below, and in relation to the OP's question

Is there any way to boot an Android phone (E.g. one with USB OTG functionality.) via way of a bus-powered USB drive

The generic boot-loader (*which resides on the chip-set) has no knowledge of USB etc, as the lk (Little Kernel) is more concerned about trapping keystrokes in order to chain-load into recovery or to boot directly into Android environment (When holding Vol+Down key in this instance) - in pseudo-code (this is from the context/aspect of lk, and also, the memory addresses pertaining to how to read the partitions are hard-coded into this lk so it will know how to process the logic!)

The lk kernel is the de-facto standard by Qualcomm for MSM chipsets (Snapdragon) and adopted by manufacturers such as Sony, Motorola, LG, Samsung and can be found in the AOSP source under bootable/bootloader.

if (Is Volume Down key pressed?) then

  • chain-load kernel from /recovery partition into particular address in memory and jump to it and start execution, in bringing up the recovery environment

else

  • chain-load kernel from /system partition into particular address in memory and jump to it and start execution in bringing up the Android environment.

end if.

As the kernel within lk is pretty limited, considering that the binary image of the kernel is burned into the chip and therefore no way of modifying it. And also should be mentioned that lk contains the fastboot protocol in preparation for flashing /boot, /recovery, /system and /data partitions. There are two sequences to boot, primary boot and secondary boot as it is:

  • Primary Boot -> lk (depending on outcome of logic)
  • Go into Secondary Boot -> /boot or /recovery

Side note: Samsung is fond of the PBL/SBL (Which is Primary Boot Loader and Secondary Boot Loader respectively) in their jargon when it comes to modding. Thing about Samsung, is that, in some handsets, PBL and SBL may be encrypted (Samsung Wave GT-S8500 is one such example, where porting Android to it was nearly impossible to do because of the DRM within the boot loaders which was a nightmare to deal with and made modding it extremely difficult, nonetheless, it is sort of working via an exploit in the FOTA code!)

This is why there are no extra facilities such as OTG functionality or anything else such as serial communications, reading from SDCard, graphics etc as it would make the lk kernel bigger than is intended. In other words, it is the smallest possible size of kernel that is designated to do just the above pseudo-code happen.

Also, another way of looking at it is this, and this is dependent on the Android version - the USB OTG functionality is fully brought up within the Android environment, i.e when the familiar home screen appears, then OTG's functionality is enabled. Unfortunately not the case when looking at it from lk's perspective.

If you're curious, here's the Qualcomm entry on the above lk which is a part of the tiny C source that has ARM assembly included and found in JellyBean's AOSP source in 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;
}

It is possible in a sense, however. Given the limitations mentioned in @t0mm13b 's answer, it makes sense that the mentioned boot loader (lk) is incapable of doing this. So, we boot a custom kernel from fastboot (for testing), which boots, enables OTG functionality and once a valid kernel is found on the OTG device which is connected, chainloads that into memory and passes control to it. This could probably even be integrated into modern custom recoveries like TWRP which have both OTG and (in some cases) MultiROM support.

This has actually been used to boot Ubuntu on a Nexus 9 tablet, using the method:

  1. fastboot boot <otg_chainloader_kernel>
  2. <otg_chainloader_kernel> boots and enables OTG and waits for OTG device to be connected.
  3. Device is disconnected from PC and USB flash drive having bootable Ubuntu image is connected to it via OTG.
  4. <otg_chainloader_kernel> detects a valid Linux kernel on the OTG device and passes control to it after chainloading it into memory.

Now, if you wanted to, you could boot a compatible Android ROM image in a similar way, but remember that the OTG drive would have to be kept connected to the device until you decide to return to the native OS (since all apps would load from, and all data would be written to the USB flash drive, unless the entire Android ROM could be configured as a ramdisk (ever heard of Puppy Linux?), which, given the current memory capacities of common Android devices and the size of the ROM itself is currently impractical). That precludes charging while booted to OTG OS, too, on most devices with unified data/charger ports.

Source: XDA-Developers Nexus 9 subforum