Can't make the Android image boot

[Passiday]

I am using Linux (Ubuntu 14.04) and I'd like to run Android on my Pine64 2GB board.

I have 16GB SD card, and I can't seem to make any of the images boot, so I come here out of despair.

The image I've currently downloaded from this page is android-ver5.1.1-20160711-pine64-16GB.img, zip file MD5 hash FAA48E4261451C1F54094AB6C253E76C.

Here's the command I used to burn the image:
$ dd if=/path/to/android-ver5.1.1-20160711-pine64-16GB.img bs=32M | pv -s 16G | dd of=/dev/mmcblk0p1 bs=32M

The process, however, finished when the progress bar was at 93%, but no error were thrown:
16004415488 bytes (16 GB) copied, 1283,6 s, 12,5 MB/s

The file size is 16088301568, so obviously there's something wrong.


I attempted also to burn the image using Gnome Disks utility, but it complains that the image is 83 MB bigger than the target device.
The Disks utility says my SD card size is "16 GB (16 005 464 064 bytes)", so apparently 16088301568-16005464064=82837504 is a problem. But why would there be a slightly-too-big image file for download? Its confusing.

I think I am too puzzled to move on now. Any suggestions how to get a proper image file and/or how to burn the current one?

[dkryder]

you are not alone on the android 5.1.1. those are known issues. android 7 seems to be working ok. it resizes the image during the first boot process.

[Ghost]

I am using Linux (Ubuntu 14.04) and I'd like to run Android on my Pine64 2GB board.

I have 16GB SD card, and I can't seem to make any of the images boot, so I come here out of despair.

The image I've currently downloaded from this page is android-ver5.1.1-20160711-pine64-16GB.img, zip file MD5 hash FAA48E4261451C1F54094AB6C253E76C.

Here's the command I used to burn the image:
$ dd if=/path/to/android-ver5.1.1-20160711-pine64-16GB.img bs=32M | pv -s 16G | dd of=/dev/mmcblk0p1 bs=32M

The process, however, finished when the progress bar was at 93%, but no error were thrown:
16004415488 bytes (16 GB) copied, 1283,6 s, 12,5 MB/s

The file size is 16088301568, so obviously there's something wrong.


I attempted also to burn the image using Gnome Disks utility, but it complains that the image is 83 MB bigger than the target device.
The Disks utility says my SD card size is "16 GB (16 005 464 064 bytes)", so apparently 16088301568-16005464064=82837504 is a problem. But why would there be a slightly-too-big image file for download? Its confusing.

I think I am too puzzled to move on now. Any suggestions how to get a proper image file and/or how to burn the current one?

The actual capacity of a MicroSD card varies between brands. Sounds like the image you are trying is so slightly bigger than the card you are burning onto, thus the process cannot complete. 

Try burning the 8GB image, just to confirm as working.

Or as dkryder says, there's always the Android 7 build, which auto-resizes to fill out the microSD on first boot.

[Passiday]

The actual capacity of a MicroSD card varies between brands. Sounds like the image you are trying is so slightly bigger than the card you are burning onto, thus the process cannot complete. 

Try burning the 8GB image, just to confirm as working.

Or as dkryder says, there's always the Android 7 build, which auto-resizes to fill out the microSD on first boot.

Well, I just dd-ed the Android 7 build (android-7.0-pine-a64-v1.4-r51.img, 4 099 932 160 bytes), but no luck. Just the red LED, and the projector where HDMI output is connected to, says no signal. The creators of Pine64 could at least have made some error screen to tell whats wrong.

I have two of these Pine64 2GB boards, and both behave the same, so, unless I got very unlucky, the problem lies within the SD card and/or the way how the image is burned on.

Previously I used this same card for Raspberry Pi 2, with no issues.

Afer dd-ing the image, the card would not normally mount on my Ubuntu, am I wrong to assume that it should mount and I'd be able to see the contents?

EDIT:
Ok, dammit, when I burned the image with the Gnome Disks utility, the result looked much better - properly partitioned drive, and it now boots, too, hooray! Pherhaps I had to dd the image to /dev/mmcblk0, instead of /dev/mmcblk0p1? Got to test that later.