dual booting android x86 with windows 8.1 onto a surface pro 3

[Insight SS]

I'm making this post as I have done my nut the last several days trying to install and boot android x86 onto a Surface Pro 3 that also runs the preinstalled windows 8.1.

I have often used forums and discussion boards to find solutions to problems but after a hundred + websites searches and countless forum posts gobbling up something like 36 solid work hours over the last week I found no information on what I eventually discovered the solution to be. So this seems like an appropriate place to make a contribution to the community. May it save someone pulling out their precious hair strands.

Initial goal:
To install android-x86-5.1-rc1 onto my Surface Pro 3 to run a particular app that requires bluetooth connectivity. (I found no virtual machines or emulators that had bluetooth working)

I will list the problems and solutions as I ran into them. There are many for a noob.

*************************************************************************
If you are going to follow this as a tutorial get " Reflect ". NOW (I mean like right now) and make a Reflect boot usb and use Reflect to make an image of your hard drive. 1 key stroke is all it takes to say yes to formatting the wrong partition that turns your $1100+ worth of beloved Surface Pro 3 (i3) into a belovedly painful paper weight. With a back up... proceed.
**************************************************************************





Problem 1:
Could not boot android-x86-5.1-rc1.iso from a usb.

Solution 1:
There are two file versions for download on http://www.android-x86.org/ for android x86. android-x86-5.1-rc1.iso and android-x86_64-5.1-rc1.img.
The Surface Pro 3 as it turns out is a EIF machine. That is it uses UEFI instead of BIOS to start the computer.

The Surface Pro 3 needs android-x86_64-5.1-rc1.img burnt to a usb using Rufus.
The .img file sets all relevant setting, partition type etc. [lost some strands to get to this point]
some Surface Pro's may need the usb labeled "BOOTME" (with out quotes) or they won't work (Microsoft nuance apparently). Do this in Rufus after you load the .img and before you press start.

Next change EFI boot setting- power off Surface Pro 3 then hold volume up and press power button for a few seconds, release power button continue holding volume up until you enter boot options.
Set usb to boot first
Turn off "Secure Boot Control" (or you won't be able to boot anything that's not Microsoft essentially) You will boot with a ugly red screen because this is off also- c'est la vie -

---Hazar! you should be able to plug your usb in and boot to a selection screen for android x86.

Next check you can run as a live cd - runs android off usb stick, you cant save any data though. Then install.






Problem 2:
Installing android x86 not work - no keyboard

Solution 2:
Androidx86 setup dose not have drivers for the surface pro touch screen or keyboard. Get a usb hub and plug in a usb keyboard along with you usb boot stick.

***Now before I go further, it's said you can install to an existing partition with other data on it i.e windows c: drive. however I shrunk the c: drive by 3.3gb's and made a fat32 partition for android x86 with that new space. You can Use the windows "create and format disk partitions" utility coupled with the "perfect Disk" application using defrag and prep for shrink options. If that doesn't make sense google making a new hdd partition, google is your friend here. Also Surface Pro 3 with windows 8.1 come with Bit Locker drive encryption enabled by default - Even if you haven't activated it yet (I hadn't) the drive is still encrypted and androidx86 install won't be able to read the partition. - activate and Disable it -

With a partition made you will have noticed there are several partitions on your Surface drive or any EFI system for that matter. One (the first partition for me) will be dos type tools, another (the second in my case) will be the EFI boot files partition. Another is windows c: drive, and another is the recovery partition that holds windows install files. you may find some unallocated space that windows likes to have too.
Basically you need to count the number of partitions you see in windows disk management's app so you know what partition number to install on when your are looking at the android x86 install screen.
My androidx86 partition was the 4th partition so in the installer I had to choose sda4 as the partition to install to. Numbering starts at sda1. sdb1 would be partition 1 on the second drive in your pc, possibly a thumb drive.







Problem 3:
can't boot into android x86 after install - boot loader dose not show up

Solution 3:
Install grub2win with correct linux boot parms (I assume this means parameters) [this is where I lost most of my hair. I have 3 strands left]

For whatever reason android x86 install did not install grub (grand unified boot loader) onto my Surface Pro 3 properly. Install gave me an option to install "grub" and "EFI Grub" which I assume means Grub2 as that's the version designed to work with UEFI systems. Not knowing what they were originally I installed both, then one then the other - no joy.
I just kept booting back to windows.

Solution 3a:
Install Grub2Win from within windows.
Extract your grub2 folder to a drive of your choosing I ended up using c: drive.
**Note grub2 will not start unless its in Root:/grub2/
don't get caught like I did with it being extracted from the zip file to Root:/grub2win/grub2 - On my Surface Pro 3 I got no error message just a perpetual busy in background mouse cursor when i tried to launch the programe. I thought it was incompatible with the surface. When I tried running Grub2win on my PC I got the error message that Grub2 couldn't find its main executable... I had just doubled clicked on it! anyway, I shifted the grub2 subdirectory as mentioned above and it worked
--Hazar!






Problem 3B:
How do I set up Android X86 on grub2win?

Solution 3B:
Open Grub2win
Install by clicking on the "Manage EFI Partition Modules"
Click on "Manage Boot Menu"
Click "ADD A New Item"
Select "android" as the os type in the drop down menu
In "Boot Mode" section type the name of the folder your android image files installed to. Being as the version current at time of this being written in android-5.1-rc1 that's the default install directory for me. I typed in /android-5.1-rc1
Grub2 will search all the drives and partitions for that folder.

--Congratulations, if you reboot now grub2 (providing you got that happy green screen upon closing grub2win) should load its boot screen with a windows and android option... But

Take note of the "linux Boot Parms" in the grub2win menu screen under "boot Mode" these are ridiculously important to have right and bloody hard to get information on or to see if your changes actually did anything.

Default setting is "verbose androidboot.hardware=android_x86 video=-16"
Works with most hardware apparently or at least use to.

If you don't change this on a Surface Pro 3 and probably other 64bit EFI systems this is what happens.







Problem 4:
android x86 starts to boot but stops at a command line type console that reads " ANDROID root@x86_64:/# " an underscore _ flashes at you. if your quick enough to read it before it disappears that is.

I'm going to repeat that again because in all the hundreds of forum posts I read I only came across 1 reference to this and those people gave up.

*** android x86 starts to boot but stops at a command line type console that reads " ANDROID root@x86_64:/# " an underscore _ flashes at you.***

After tugging relentlessly at my last 3 strands of hair I managed to cause a series of brain fissures and found out this information.

The Kernel appears to have loaded.
You can type things in and execute commands. Type a letter and then pressing tab will give you a list of commands starting with that letter. Not very helpful as I was never able to find documentation on this.

This " kernel command console " may show up instead of android x86 OS loading because of an incompatible driver mode set in the boot parameters.
Available parameters I stumbled across include:
Video=-16 -I assume its a generic simple instruction.
video=vesa -vesa mode?
video=uvesa -a type of vesa mode?
UVESA_MODE=1680x1050 -somebody used this setting along with video=-16
video=vesa vga=320 -supposed to set a resolution where 320 in the hex value
for 800. 800x600 res perhaps. Like I said I never found clear
explanations of these. If a reader wants to post correct information on
these please do.
xforcevesa -forces vesa

If these low level drivers don't operate some hardware you have it seems your next option, if your determined, is to compile a new kernel with compatible drivers. Good luck!

However video driver modes were not the problem for the Surface Pro 3.
video=-16 worked for me.

I found many references for androidboot.hardware=android_x86
older androidx86 builds use androidboot_hardware=android_x86
I think I saw one used as androidboot.hardware=generic_x86
Another was androidboot.hardware=x86
for eeep machines use androidboot.hardware=eeep
for asus laptops use androidboot.hardware=asus

Sigh.
After sitting amongst a nest of scattered hair, with red eyes, a throbbing head and questioning what I was doing with my life it occurred to me to install to a usb stick. Maybe that would work better.
**It did!
I could boot a freshly installed copy of android x86 5.1 rc1 from a usb stick. Now having a usb stick plugged in every time I wanted to run android would not work for the small business situation that I'm setting up for with my shoe string budget... so onward I trudged.

After doing some unnecessary experiments copying the usb thumb drives files to my EFI partition and dedicated android system partition, and attempting to chainload the usb sticks boot files (grub2 seems determined to only look for boot loaders in the EFI partition (you then you have to tell those boot files where to find the OS they are ment to load too...))
I discovered the boot Parameter settings I needed.


And here it is---> androidboot.hardware=android_x86_64


How come I never found this? surely someone has talked about running a 64bit android OS on a 64 bit system using grub2...?

If discomfort is a great growth mechanism then maybe it was my turn to grow some.

Bleeding ears aside,

To get a Surface Pro 3 to run android-x86_64-5.1-rc1.img ( Android-x86 5.1-rc1 EFI image (64-bit OS) ) with the grub2win interface for grub2 use these parameters for the " Linux Boot Parms " input field (that you have to click on several times before the cursor will allow input)


verbose androidboot.hardware=android_x86_64 video=-16


Bluetooth, wifi, touch screen, Surface pro keyboard and everything else work great with this OS build. The guys at http://www.android-x86.org/ have done an amazing job.


May the patience to endure and persist on to success be with you.

-Insight SS

[Chih-Wei Huang]

Thank you for the effort to fight the issues and
share the information to help others.

About the androidboot.hardware parameter,
The rule of thumb is it's the target name of the image.

In jb-x86 and kitkat-x86, we only have one
target: android_x86.
Since lollipop-x86, we support two targets:
android_x86 for 32-bit image
(could be used on both 32-bit and 64-bit CPUs)
and android_x86_64 for 64-bit image
(for 64-bit CPU only, of course)

Before (including) ics-x86, that's another story.

For more info about the supported targets
of each release, see
http://www.android-x86.org/getsourcecode


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Abdullah Wiqar]

dude, I admire your persistence and tenacity. I nearly matched you for it but unfortunately I gave up. I have an HP Split X2 64 bit with UEFI and I went through literally ALL the same hoops and hurdles that you went through. Got all the way to GRUB, got it installed, booted into Android and all but then I saw that the space allocated to the data was very minimal and to get more space I'll have to use an ext3 partition. When I did that, GRUB2win stopped working. 

Did you figure out a way to get grub2win to work on ext2/3 partitions? Or do you have the entire 3 gig of spaces for android data files on your FAT32 partition? 

Also, I noted that you turned safe boot off but the UEFI remained on? Did you turn on legacy boot or something? And if not, how did it boot into grub2win loader when you reboot the surface? 

Btw, there's an installer on XDA forums that does the entire job in a couple of clicks. Works for the most part. When I tried it, the only thing that wouldn't work was the auto rotate which is a deal breaker for me. Anyway here's the link: 

http://forum.xda-developers.com/android/software/winapp-android-x86-installer-uefi-t3222483

[Mke]

Hey. Don't know if it has to do with efi or what... But I have Grub2Wim booting my Linux and both 4.4 and 5.1 amdroids. 2 ext4 and one ext3...

Sent with AquaMail for Android
http://www.aqua-mail.com

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.

[fgdn17]

testers needed for this installer......try it next time

http://forum.xda-developers.com/android/software/winapp-android-x86-installer-uefi-t3222483

[おとめ座ひなたぼっこ]

hi insight SS.
how come do you have ANDROID:root@android_x86_x64#_? (#)
which ramdisk.img do you use?
release note says that superuser not work for x64
I suppose you should only have ANDROID:root@android_x86_x64$_ ($)

[Phil Lee]

Am i right, that theres no root yet in the current x64 image?

For when is the new image planned? 

[Chih-Wei Huang]

What the release note said is the Superuser app doesn't work
on the 64-bit image. (which has been fixed in the source tree now)
The virtual console (Alt-F1) still has root, of course.

[おとめ座ひなたぼっこ]

oh I see. How about 6.0 testing branch, when will the Terminal is suable or am I missing Superuser app

[Insight SS]

HA! 
So close and yet so far.

It never occurred to me to explore source code documentation... the thought of looking at source code stuff scares me actually :/

-Cheers!

[Insight SS]

Thanks :)
Apologies on late reply, I must not have had on update notifications.

The 3 gigs of space on fat32 was all used for the android system.img, Data.img, etc. when I mathed out the required space, system files plus data it worked out I would need about 3.3 Gb. The size of the Data Image is set when installing android x86. the default size is 512Mb but you can change that to 2048Mb (the maximum supported...  or so I read and that several tutorials referenced). Checking the storage specs just now in the Android OS on the SP3 reported 1.94GB of of total space.
Is 2GB what you meant for minimal? I didn't see through the install attempt I made with ext2 format so I can't really comment. Sorry.

Yes Safe Boot option is off and the SP3 uses UEIF boot system (as opposed the the older BIOS system) SP3 UEFI does not give you an option for Legacy Boot. It dose not give you very many options at all actually. I beleive Legacy boot emulates the BIOS start up environment for older 32bit OS's or an OS made to start with BIOS...
So to answer your question, The Surface Pro 3's UEFI is very persistent at findinding and loading the windows boot loader, fortunately for me, when GRUB2 didn't install properly in the Android installer, after a short booting delay, I landed back in windows. From there I surfed the net and downloaded GRUB2Win. GRUB2Win detected UEIF and in set itself up appropriately... I suppose I would say make sure GRUB2Win is installed onto the windows drive?

Oh man, wish I had found that installer at the start! 
Did screen rotate work in your original fat32 install? If it did, maybe it's worth trying again.

Have a good one.

[Jeroen van Wamelen]

Hey Thanks Insight SS ! The procedure was more or less identical for my Sony Tap 11. I now have a working dual boot device thanks to you and all the fabulous people involved with Android x86.

Observations on my device:

- It's very prone to reboots, with apps re-optimising on every boot.

  example: having chrome open and rotating the device will reboot it every time.

- Power button does not lock the device, it instantly brings up the power menu.

- All included live wallpapers are 0 bytes in size and crash immediately upon launching.

- Apps trying to request root access just freeze up. ( likely to the superuser not working as mentioned )

- Pulling down notifications sometimes displays the user switcher on the right edge of the screen

- Youtube is only allowing 360p playback maximum

- Home, Multitasking & Back button are blurry

- Battery stat graph is totally messed up

- There are no NFC options,even though my device has NFC

[Chih-Wei Huang]

2015-12-10 5:13 GMT+08:00 Jeroen van Wamelen <jeroenva...@gmail.com>:
> Hey Thanks Insight SS ! The procedure was more or less identical for my Sony
> Tap 11. I now have a working dual boot device thanks to you and all the
> fabulous people involved with Android x86.
>
> Observations on my device:
>
> - It's very prone to reboots, with apps re-optimising on every boot.
> example: having chrome open and rotating the device will reboot it every
> time.

I think you use the 64-bit image, right?
This is a know issue only happened on the 64-bit image.
It has been fixed in the source tree.
You can build it yourself or wait the next release.

> - Power button does not lock the device, it instantly brings up the power
> menu.

Right...
I admin it's different than kitkat-x86 but
I'm OK with it.
Whether to switch back to the same kitkat-x86 behavior
is yet to be decided.

> - All included live wallpapers are 0 bytes in size and crash immediately
> upon launching.

Works for me.
What's your GPU? Has HW OpenGL been enabled?
(check Settings -> About)

> - Apps trying to request root access just freeze up. ( likely to the
> superuser not working as mentioned )

Another known issue of 64-bit image which
has been fixed.

> - Pulling down notifications sometimes displays the user switcher on the
> right edge of the screen

The right behavior. So?

> - Youtube is only allowing 360p playback maximum

This is been explained in another thread.
Android originally only supports this.
All android phones and tablets shipped in the world equipped
with hardware codecs so they can play HD or higher videos.

In kitkat-x86 we ported ffmpeg as the software codecs
we it can play a lot of video formats.
But this has not been ported to lollipop-x86 yet.

> - Home, Multitasking & Back button are blurry

Not sure what you meant blurry.
If you dislike the icons, complain to Google.

> - Battery stat graph is totally messed up

Hmm..?

> - There are no NFC options,even though my device has NFC

NFC has never been ported to android-x86
and you are the first one ask for it.
That means you are on your own to port it...

[Jeroen van Wamelen]

> ...

>This is a know issue only happened on the 64-bit image. 

>It has been fixed in the source tree. 

> You can build it yourself or wait the next release. 

Well these are pretty critical bugs, you cannot expect your end users to wait for 3-4 months for the next release.

The state it is now its totally unusable. Why aren't nightly or more frequent "unstable" builds available ?

And how can such major bugs make it to a big release candidate ?

> - Power button does not lock the device, it instantly brings up the power 

> menu. 

>Right... 

>I admin it's different than kitkat-x86 but 

>I'm OK with it. 

>Whether to switch back to the same kitkat-x86 behavior 

>is yet to be decided. 

Well then Androidx-86 is deviating from standard android behaviour.

Users have certain expectations when using an android device.

I think it is really weird to take device locking away from the power button, what are you gaining with this ?

> - All included live wallpapers are 0 bytes in size and crash immediately 

> upon launching. 

> Works for me. 

> What's your GPU? Has HW OpenGL been enabled? 

> (check Settings -> About) 

http://imgur.com/tRtJ3i7

> - Pulling down notifications sometimes displays the user switcher on the 

> right edge of the screen 

> The right behavior. So? 

The user switcher on the right side of the screen is only supposed to show on the lock screen.

Otherwise it functionality is duplicated in the notification pulldown. On top of that is is erratic in

the sense that it sometimes shows and sometimes doesn't.

> - Home, Multitasking & Back button are blurry 

> Not sure what you meant blurry. 

> If you dislike the icons, complain to Google. 

No the icons on the bottom seem to be rendered at lower DPI, causing them to be blurry compaired to the rest of the UI.

All other icons are rendered at the correct dpi and are sharp.

> - Battery stat graph is totally messed up 

> Hmm..?

http://imgur.com/9JxylRN

[George Turner]

You should save your arrogant attitude of entitlement for goods and services that you purchase.

[rbg]

hey if it's that critical for you, do something and fix it, then contribute back your work. There

are people who have been waiting for over 2 years now for some kickstarter projects who

claimed to do these things, and they still can't fix it, so they come here and expect people

like Chih-Wei and his other contributors to fix it for them.....

On Thursday, December 10, 2015 at 9:31:19 AM UTC-5, Jeroen van Wamelen wrote:

[Povilas Staniulis]

Many users mistakenly treat open source projects as if they were commercial products.

Android x86 isn't a commercial product, it's an open source project where developers contribute their time for free.
There are no set deadlines on fixing any bugs or making any releases.
Official releases are only published when the maintainer thinks it's time for a new release.

All the source code is available for you to build yourself.
If you have resources to run a nightly build server, you're welcome to do so.

--

[Mike]

Go Buy Console Os 8-)   Sry, I just couldn't resist.....

Mike

[fgdn17]

well said.....here is a summary that fits the bill...

Android-x86.org, is a project to port the Android open source project to x86 platform by Chih-Wei Huang 

- open source projects are not commercial products...

- developers contribute their time for free...

- there are no set deadlines on fixing any bugs or making any releases...

- official releases are only published when the maintainer thinks it's time for a new release...

 If your in a hurry and can't wait...

- all the source code is available for you to build yourself...

- feel free to solve your issue and consider giving back to the community your contribution...

credit to Povilas Staniulis

[Mke]

+1

Sent with AquaMail for Android
http://www.aqua-mail.com

[Jeroen van Wamelen]

This is not addressed to Mr Chih-Wei Huang but rather to the brute reply from George Turner & general:

Ah I see, because it is free and provided from the kindness of your heart it is exempt form any form of criticism. Even if that criticism is valid. If your interaction with your end user is basically "fuck off, build it yourself" then this project in its current state will serve a very very limited userbase, which makes me sad.

[George Turner]

I would say that declaring android-x86 as unusable is rather brute and quite a bit beyond criticism.

On Thu, Dec 10, 2015 at 7:28 PM, Jeroen van Wamelen <jeroenva...@gmail.com> wrote:

This is not addressed to Mr Chih-Wei Huang but rather to the brute reply from George Turner & general:

Ah I see, because it is free and provided from the kindness of your heart it is exempt form any form of criticism. Even if that criticism is valid. If your interaction with your end user is basically "fuck off, build it yourself" then this project in its current state will serve a very very limited userbase, which makes me sad.

--

[fgdn17]

so halfway through the thread the project leader takes time and rationally answers you questions,

you don't care for his answers cause you imply in your response to him, that you have much better insight

into all the issues....

then basically some users speak up without hitting you over the head with a hammer and explain

how best to get your results....you don't like it and come back with this...........

"brute reply from George Turner & general...blah...blah"

maybe you need to go see Microsoft and let them deal with your issues on your device....

maybe Android can address all your issues on your device....

you seem to think that this group is here for you and your problems are the only ones that are

important....

obviously you missed what the "brute reply from George Turner & general...blah...blah"

was telling you...there saying "get a clue, or fix it yourself, someone will get to it eventually"......

If you have trouble with that then it seems it's your issue not the issues of android-x86.org

IMO

[Mke]

Lol  +10

Sent with AquaMail for Android
http://www.aqua-mail.com

--

[Mke]

This is a cp ploy read 2 emails and its obvious... .

Sent with AquaMail for Android
http://www.aqua-mail.com

[Mke]

+10  Wow that's 30 in one night.. IMO

Sent with AquaMail for Android
http://www.aqua-mail.com

[rbg]

yup figured that out real quick....now the heats on and he's playing the victim again, can never

own up, always excuses...

[おとめ座ひなたぼっこ]

How to install img file, also if grub2 is install on uefi partition , how to remove it later. I ask for my Yoga

core I3 5020u

gt940 2g vram

4gb ddr3

500g had

touch 360

[Ian Lee]

I have managed to successfully install Android x86 4.4 onto my Acer P3. I
have also managed to get grub2 working and can switch OS as desired. The
problem is, I can only switch using an external USB keyboard. The P3
bluetooth keyboard does not activate until an OS is actually loaded.

Do you know of any workaround? Is it the same with your Surface Pro?

Regards,
Ian

[Brian Martinez]

i to have this problem with my surface pro 3. is there any way to use the volume buttons or touch to select os in grub2?

[Insight SS]

Hi Ian,
My sp3 keyboard works on the os selection menu for grub 2 so not sure I can be of much help. I did notice when I was in the grub2win config screen that there is an option for loading  additional drivers.
Maybe a grub2 forum could direct you to what you need in the way of a driver for your application.

Glad to hear you have had some success to this point.

Regards Justin.

--
You received this message because you are subscribed to a topic in the Google Groups "Android-x86" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-x86/53pb0jXYhwY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-x86...@googlegroups.com.

To post to this group, send email to andro...@googlegroups.com.

Visit this group at https://groups.google.com/group/android-x86.

[Brian Martinez]

Thanks lan. This is working out great for me! I did as you said but instead I just go to "set efi firmware boot order" in grub2win and select "request a test boot" and I simply restart my sp3. And like you said, I simply restart my sp3 and it automatically boots windows.

[Scoo Ter]

hmm, why so complicated?
If you don't want to mess around with your Windows bootloader by replacing it to Grub:
1. idea:
If you have Android installed on your internal disk, just use a tiny USB pendrive/hdd to start Android.
Copy the "EFI" folder to a pendrive's FAT32 partition, than in the UEFI set the pendrive to "first" in boot priority, done.
If you want boot Android just plug in the pendrive, otherwise it will boot from internal disk.
2.idea:
Copy the EFI folder to the Devices internal EFI partition.
As an ADMINISTRATOR in Windows:

mountvol z: /S

That will mount the EFI partition as drive "z", so you can copy the EFI folder to it
Than use "EasyUefi" to add  Android GRUB entry to the device's UEFI menu.
When your device boot up, hit the "F10" key (or similar) to bring up the UEFI Bootmenu, choose Android, done...
;-)

[Insight SS]

If that works it would indeed be elegant. 

If I have to change anything or reinstall I will definitely try that.

Thanks Scoo Ter

[Scoo Ter]

That works, definitely.
I use the second method for a stable build, installed on an internal EXT4 partition and the pendrive method for test builds.

[Jon West]

I was able to get it all working pretty easily using this method. I adapted it for Phoenix OS, but it works for Android-x86 too. : https://www.reddit.com/r/PhoenixOS/comments/426728/easy_uefi_install_for_phoenixos/