Related
major update here, the dualizer has become a feature rich toolkit for dualbooting. this includes a modified version of amon ra's recovery image. you need it to use the dualizer toolkit, it is included and can be flashed with one command.
it is a beta version for now. i have tested each option, but i cannot foresee all conditions you might have on your phone... have a backup at all time! and don't forget to backup the stuff from your sdcard before installing dualboot, during the creation of this toolkit i accidently deleted everything on mine...
there is no logging at the moment, if you get any error messages please paste them here in full.
i haven't tried a nandroid backup at all yet, and wouldn't advice you to do it either. please use apps like titanium backup to backup your stuff. i will be looking into getting some kind of nandroid capability, but that is not a trivial topic. i can however imagine to have full pc-based backup capabilites, sometime in the future...
before you use any of the romX options make sure you have installed the dualboot environment, i have no idea what happens otherwise...
i have tried to include a full description, please let me know if something is unclear (i hope it is obvious that romX needs to be replaced with either rom1 or rom2):
Code:
kendon's dualboot toolkit for the HTC Hero
usage: ./dualizer <option>
place the two roms you want to use for dualbooting in the
rom1 and rom2 subdirectories. make sure directories do
contain other files. you can use the temp/ subdir of the
two rom folders to store your roms while you want to flash
another update.zip
you need a modified version of Amon_Ra's custom recovery image.
it can be installed with this tool, see the options.
options are:
help show this information
vmsetup prepare ubuntu vm for usage
check-dev check if your device is properly attached and connected via adb
boot-rec reboot hero to currently flashed recovery
check-rec check if RA-hero-v1.6.2-DBmod is currently flashed
boot-dbmod put hero in fastboot mode (back+power) first!
fastboot hero with RA-hero-v1.6.2-DBmod
no permanent changes are done, works with unlocked spl only
NOTE: the trackball doesn't select, use green key instead
unlocked-spl copies update.zip for unlocked spl to sdcard, so you can flash it.
if this goes wrong it can brick your phone, make sure you do it right!
flash-dbmod flash RA-hero-v1.6.2-DBmod to recovery partition (permanently)
NOTE: the trackball doesn't select, use green key instead
install-db ALL your data will be lost, so you better have a backup!
install dualboot environment on htc hero
this includes partitioning of the sdcard
place roms in folders rom1 and rom2 first!
romX wipedata wipe data/factory reset romX
romX wipedalvik wipe dalvik-cache for romX
for the following options place update.zip file in folder romX first!
romX flash flashes update.zip from folder romX
romX makeboot create boot.img-update.zip files for romX
romX makeboot push create boot.img-update.zip files for romX and push it to /sdcard
i don't see any potential to brick your phone, even if it fails, as the critical parts (spl, radio) are not touched at all. worst that could happen is that you have to do a full wipe and flash a rom... be careful while flashing recovery and/or bootloader though!
as always: use at own risk!
note: first (and maybe second) boot maybe painfully slow. after that it gets better, see for yourself if it is too slow for you. i have been using villainrom and slidevillain in a dualboot for a few days now, i haven't noticed too much slowdown. then again i don't care too much about this.
credits: huge thx to the ppl in this thread: http://forum.xda-developers.com/showthread.php?t=594077 the information in there helped a lot.
changelog:
v0.2: major update, toolkit for flashing, wiping etc.
v0.1: initial release
installation & usage instructions
please read the first post before you install dualboot!
instructions for windows:
instructions for windows said:
the dualboot install can now set up all necessary stuff in a fresh installed ubuntu virtual machine in virtualbox. you must have adb access to your hero from the windows command line, if you need help check theunlockr.com for their awesome video tutorials.
here is a great howto install virtual box in windows: http://www.psychocats.net/ubuntu/virtualbox
and this is the second part, howto install ubuntu in a virtual machine: http://www.psychocats.net/ubuntu/installing
once you are done installing ubuntu download the archive from the first post and follow these steps (the default download directory is "Downloads", so i'm gonna use that in this example):
- go to "Downloads", you find it in "Places" in the upper menu bar
- rightclick the zipfile you just downloaded and select "Extract Here"
- open a terminal window: goto Applications, Accessoires, Terminal
- execute these commands:
Code:
cd ~/Downloads/dualizer/
chmod +x dualizer
./dualizer setup
it will ask for your password once, then do some stuff and finally reboot the virtual machine.
once rebooted, connect your hero to your pc, rightclick on the usb sign in the lower right corner of the virtual machine window and select the "HTC Android Phone". some hardware installations from windows might pop up (happened to me), just click on next and let them do their stuff. if it doesn't work at first shut down ubuntu, then restart your pc and continue. "reboot tut gut", as the german likes to say
back to ubuntu, with your hero connected to pc and virtualbox, open a terminal and check if your hero is detected by adb with the following commands:
Code:
cd ~/Downloads/dualizer/
./dualizer check-dev
this will tell you if your device is properly connected. you can now continue with the options you can get from
Code:
./dualizer help
Click to expand...
Click to collapse
instructions for linux:
instructions for linux said:
you need java, perl and zip setup, make sure that these are available. then follow these steps:
- extract the attached zipfile from the first post on your pc (for this example i'll assume you extracted it on your desktop).
- get the two roms you want to dualboot, do not extract them.
- put one rom in the rom1 folder, the other rom in the rom2 folder inside the dualizer folder on your desktop.
- open a terminal, cd to the folder and make the main file executable by typing:
Code:
cd ~/Desktop/dualizer
chmod +x dualizer
- turn on your hero (recovery or normal, doesn't matter)
- connect your hero to your pc and check if your hero is detected by adb with the following commands:
Code:
./dualizer check-dev
this will tell you if your device is properly connected. you can now continue with the options you can get from
Code:
./dualizer help
Click to expand...
Click to collapse
reserved...
Holy... this is incredible. Great job on getting this out.
I use a virtual box and ubuntu 10.04 lts.The method seems to work but in step 3 on partition card my hero restarts and boots in recovery and i don't have time to mount the usb/htc device into virtual box so i get in step 5 an no device found error.The time is very short.I have to press USB-MS toggle on my hero and after that i have to mount it in virtual box.I've tried it over 20 times but i don't have time and in terminal get me the error.Is there a way to pause the process or a solution to my problem?
Sorry for my bad english
EDIT:SOLVED.Set the sleep from dualizer in step3 from 15 to 30.Wainting for setup to finish.Cross my fingers
EDIT2: Ok now this is getting awkward.Waiting on step 4 (push to sd) for 25 minutes now.I have checked the log.Last line says mounting /dev/block/mmcblk0p1 on /sdcard failed: No such file or directory.Should I wait for it any longer?Or what should I do now?
As I have said on the VillainROM forum; this is really outstanding work.
Well done, Kendon.
Zero00SM said:
EDIT2: Ok now this is getting awkward.Waiting on step 4 (push to sd) for 25 minutes now.I have checked the log.Last line says mounting /dev/block/mmcblk0p1 on /sdcard failed: No such file or directory.Should I wait for it any longer?Or what should I do now?
Click to expand...
Click to collapse
that shouldn't happen, and the pushing shouldn't take longer than a few minutes. you should cancel it by pressing ctrl-c, if you fancy debugging then check why it wouldn't mount. otherwise you can partition your sdcard, do a full wipe and should be able to flash a regular rom.
i guess i underestimated the complexity of the virtual machine solution, gotta look deeper into this... *sigh*
Hi, regarding the Apps2SD issue... Would it ever be possible for the two ROMs that are dual booting to have the same apps sourced from one place... if that makes any sense...
Like in windows... you can "install for all users" so if you log off and someone else logs in with there account the very same apps are there...
Ok bad analogy since we are talking about dual booting different versions like (Vista & Windows 7) ... but the same data on hdd is accessible...
is this possible with the dual booting scenario?
If I had Slide Villain and Villain 5.5 .. both being 2.1 ROMs which would make app compatibility a non-issue...
If I booted up Villain 5.5 and made changes to an app / save data .. could this not be accessible with the slide rom.. I would hate having to install the very same apps on another partition..worst of all if you have save data (such as a game) and wanted to play it on one of the ROMs your game progress would be different?
you could just use Titanium to transfer over the data but agaqin it is a long procedure.
It would be fantastic if we could mirror image exactly what we have on our main Roms to our "secondary roms" ...
Amazing !
Ciao
Fred
Yeah this is really amazing. I have read this on villainRom forum, and i was stupified .
But, if i want to flash another Rom as primary and need to wipe cache, i need to do this process again! Am i right?
for the shared apps:
a shared apps2sd directoy/partition is possible, although you'd have the problem that apps are installed to one market only, and idk what would happen when you update an app in one rom, would the update get market-linked in the other? you can solve this with titanium backup, but it isn't really comfortable at all. i'll think about this.
for shared data: in theory possible as well, but i don't think it would work out well. you cannot distinguish between system data and apps data that easily, and i don't think it would work to share system data (sense settings etc) between two different roms...
@masterxiter: easiest way to do this is to use the installer script again. you can wipe the cache manually, installing another rom would be really complicated (about as complicated as the installer script )...
Sweet. But is there any way i can run this in cygwin? every version of linux ive tried so far doesnt support my crap compaq wifi card or most things, or even wired for that matter, and running ubuntu in a virtual machine gives a reboot every time after step 1 (maybe cos i suck at terminal)
i'll try some time, but i have never used cygwin... so don't expect anything too soon.
joshman99 said:
Sweet. But is there any way i can run this in cygwin? every version of linux ive tried so far doesnt support my crap compaq wifi card or most things, or even wired for that matter, and running ubuntu in a virtual machine gives a reboot every time after step 1 (maybe cos i suck at terminal)
Click to expand...
Click to collapse
if you install ubuntu in an virtual machine like VMware(paid) or virtualbox(free) you can just use linux, it will automatically grab all your internet settings and stuff from the windows installation(main computer) so your windows will be like some kind of router for your virtual machine with everyhing working.
Very nice tutorial, i'm not going to try it.. because my phone has to be resend to HTC for fixing some dead pixels, there just messers with screens
BTW. you can also try another linux version sounds crazy, maybe try backtrack?? the only thing you need is linux, backtrack is..
I have backtrack 4 (I could never get wifi on that either, but tbh i couldnt work out how to try (that distro is soo confusing imo). I got backtrack 3 to work a while back, so if i can find the disk im gnna try that.
Also virtualbox didnt put my internet settings at all (maybe co im on win7 ultimate?)
Thanks for the suggestions, cos i know cygwin aint the most elegant solution
changing rom 1 and rom 2
i test lotz of roms.... everyday they are being updated...
say if i dualize with ahero0.8 and Kimera 1.7....
wud i be able to update aHero to 0.9 and leave kimera as it is???
simply can i update JUST ONE rom???
manual setup??
i tried it got error in step 3 and then 'Device not found errors...'
can u make a tutorial for doing it manually.....
kendong2 said:
please read the first post before you install dualboot!
instructions for linux:
you need java, perl and zip setup, make sure that these are available. then
Click to expand...
Click to collapse
hihi.. i am trying to do a dual boot, so im wondering what u mean by.. need java , perl and zip setup... can advice me?
He means that you need to have Java, perl and zip installed and configured on your Linux system. If you dont have that installed and configured correctly than the install script wont be able to run.
lolnl said:
He means that you need to have Java, perl and zip installed and configured on your Linux system. If you dont have that installed and configured correctly than the install script wont be able to run.
Click to expand...
Click to collapse
oh noes.. .i do not have those in my ubuntu, does that mean i cant do a dual boot? btw, i saw post 2 and post 3 ... are they the same instruction ? or different? (one for windows user and one for linux?)
Wanting to root my new Telstra T-Hub 2, made by Technicolor.
There appears to be no USB drivers available (nothing via Google)
There also appears to be no way to get into the Download Mode for connection to Odin. (again nothing on Google)
So these two points have left me a bit lost.
It is running Android (GB) 2.3.7
Any one have any ideas????
Rabs_1976 said:
Wanting to root my new Telstra T-Hub 2, made by Technicolor.
There appears to be no USB drivers available (nothing via Google)
There also appears to be no way to get into the Download Mode for connection to Odin. (again nothing on Google)
So these two points have left me a bit lost.
It is running Android (GB) 2.3.7
Any one have any ideas????
Click to expand...
Click to collapse
I got ADB working on my T-Hub 2 by using the generic Google drivers, and edited the adb_usb.ini to just say 0x069B
So far I have problems rooting it.
wocko1 said:
I got ADB working on my T-Hub 2 by using the generic Google drivers, and edited the adb_usb.ini to just say 0x069B
So far I have problems rooting it.
Click to expand...
Click to collapse
BUMP
I have this Tablet as-well and having the same problem.
any ideas on the best way to root this thing?
wocko1 do you have any more details on how to got that far?
Thanks guys.
Rabs_1976 said:
Wanting to root my new Telstra T-Hub 2, made by Technicolor.
There appears to be no USB drivers available (nothing via Google)
There also appears to be no way to get into the Download Mode for connection to Odin. (again nothing on Google)
So these two points have left me a bit lost.
It is running Android (GB) 2.3.7
Any one have any ideas????
Click to expand...
Click to collapse
was it released in any other countries as another device?
even if we got root on it what can we do for a custom ROM if noone can dev for it
Madaz2 said:
was it released in any other countries as another device?
even if we got root on it what can we do for a custom ROM if noone can dev for it
Click to expand...
Click to collapse
We as owners/users of T-Hub 2 devices require sensible answers to important questions.
We need usb drivers for the T-Hub 2, either from Telstra or from Technicolor the manufacturer of the device so that we can attain " ROOT ACCESS" via a usb cable connection to a computer.
Unless we can get "ROOT ACCESS" we cannot move applications to an external SD card (32 GB in my case) or use Titanium Backup or certain Antivirus programs that require "ROOT ACCESS".
Please accept the undeniable fact that 1 Gigabyte of storage on the internal SD card is totally insufficient and pathetic, almost as pathetic as the fact that we are still stuck with "Gingerbread" which puts us three versions behind on Android which is now up to "JellyBean" v2.
The fact is, I believe the Android operating system running on the T-Hub 2 is, like all other versions of Android, based on the Linux kernel which is software using the GNU General Public License, which allows people to see, copy, use, and modify for their own needs.
If indeed I am correct in my assumption then Telstra/Technicolor could be in breach of a world standard which would mean that the proprietary blocks and gates that they have built to prevent access to the kernel on the T-Hub 2 are illegal.
Download Mode discovered...and more...
I thought this:
Hold "Volume-" and "Volume+" and "Power Button" boots into download mode. This is incorrect.
This gets you to recovery mode (which shows the Android robot fallen over).
Help!
wocko1 said:
I got ADB working on my T-Hub 2 by using the generic Google drivers, and edited the adb_usb.ini to just say 0x069B
So far I have problems rooting it.
Click to expand...
Click to collapse
Have been looking for the drivers everywhere, and so far none of them have worked. Even tried wireless adb to no avail. Also tried gingerbreak but still nothing. Sick of looking at the bloatware. Someone please help!
anyone had more success now that it has ICS 4.0.4
Yes, it can be rooted, but...
Hi,
Yes, much more progress. I've gained ADB root access using the restore method (i.e., restoring a backup which has been modified to install a file to a strange path, e.g,: ../../../system/bin/su), I recommend creating your own restore file rather than using one of the many out there and using it to install the necessary SU software to the appropriate locations.
If your device isn't detected by ADB, check that the device ID has been added to the ADB config file. The Thub2 ID is not recognised automatically. Also, when using fastboot remember to specify this ID or it won't find your THub.
The biggest issue with the THub2 is that Telstra have (in an oddly intelligent move) adopted SquashFS for the root file system; this is the FS used on things like linux liveCD's, and it's 100% RO (well, 99% RO . I have gotten around this in a number of ways. 1: I copied the SquashFS partition using DD to an Ext4 partition, then forced a dirty unmount of the SquashFS partiition chained to a mount of the new Ext4 partition to /system. RW access no problems, SU installs OK, but no persistence without forcing the dirty unmount each boot. 2: I copied the SquashFS partition to my ~ using DD, mounted and edited the partition, then re-flashed to the thub. worked much better, persistence across reboots, but dangerous and dodgy method that could risk many NANDs. 3: I cross-compiled a busybox containing UnionFS to Android.
Option 3 is by far the best option. UnionFS provides a transperent RW layer for SquashFS filesystems, writing the updates that couldn't be written to a RO system like squash to another partition (e.g., Ext4 on SD card). Mount a UnionFS system over /system to enable write access to the system. Maybe a better idea to mount it at /, but that raises other problems I couldn't be bothered dealing with.
I mentioned above that SquashFS is on 99% RO (in all my other experiences, it has been well and truly 100% RO, so this indicates something else a-going on that we should be able to use; I haven't looked into it yet.). For some reason, files installed to the Thub2 using the Restore method are persistent. Very useful, and should lead to a cleaner method.
So rooting so far:
Root with Restore method to install (1 & 2., SU bins, or 3., UnionFS Busybox)
Remount / as RW
-->Path 1 & 2
Dirty unmount /system && dirty unmount /system2 && mount /dev/block/etc.. NOTE: Once you dirty unmount /system, you will need to reference the location of the Ext4 partiition using the absolute (real) name of the device. You will also need to invoke busybox from a fully qualified path, eg. /data/local/tmp/busybox, as the internal /bin applications are no longer available (eg., mount).
-->Path 3
No need to umount /system, just mount the UnionFS system over the top.
Finally, for Paths 1 & 3...
Install Superuser application and be free!
So to sum up; I have easily rooted the Thub2 to root over ADB using a number of methods, however the Restore method works 100% of the time. I have mounted an Ext4 system to /system in order to have RW, but this isn't persistent. I have re-flashed the SquashFS with modified content, and this works a treat, but is RO and dangerous to NAND. I have mounted a UnionFS system over the SquashFS system, and this seems to provide the best all round performance.
I also wrote a short and nasty .apk to mount the UFS system without terminal, so that's a go as well.
Have fun pulling it all apart; I don't read these message boards, so I probably won't se any questions. More than enough to get rooted though.
THub Drivers and ADB Access
THUB 2 DRIVER INSTALLATION AND ADB ACCESS
This method sets out how to install drivers for the THub 2 and access ADB (Android Debug Bridge).
Access to ADB is the usual way that you use to Root an Android device.
Please note that not all ADB versions work. If you download and try a root method, you may have to copy the ADB.exe and support files across so that the root method can at least have a chance of working.
INSTALLING GOOGLE UNIVERSAL ANDROID DRIVERS
1. Ensure that Debugging has been enabled – Settings Developer options USB debugging and make sure the box is checked
2. The following is for Windows 7, other versions will be similar
3. Unzip the file and copy contents to a folder on the C: drive. I copied it to a folder I named THub
4. Plug the THub into your PC and it will try to find suitable drivers – some drivers may load and install but at least one will come up with “No driver found”
5. Open “Computer”
6. Click on “System properties”
7. Click on “Device Manager”
8. Under “Other devices” you will see T-Hub2 with an icon with a yellow exclamation mark.
9. Right-click the device and select "Update Driver"
10. Select "Browse my computer for driver software"
11. Select "Let me pick from a list of device drivers"
12. Click “Show All Devices”
13. Click “Have disk …”
14. Browse to where you put the extracted files
15. Select and open “Android_winusb.inf”
16. Select “Android Composite ADB Interface”
17. Click “Next” and then Click “Yes” (Ignore warning)
18. Wait until the software installs
19. You should now have Android Composite Interface” under the “Android Phone” listing
If you have problems, ensure Debugging is selected and try unplugging the THub and reconnecting it
ACCESSING ADB
1. Ensure that Debugging has been enabled – Settings Developer options USB debugging and make sure the box is checked
2. The following is for Windows 7, other versions will be similar, It also assumes that the file has been down loaded, unzipped and installed in a folder called THub on you C: drive
3. Connect the THub to your PC
4. Click in the “Start” icon, lower left icon on your PC Desktop
5. In the entry box type in “CMD” and push “Enter”
6. You will be at the “Command Prompt”
7. You need to navigate to the “THub” folder, the following are my entries, and yours should be similar.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Terry>cd .. and “Enter”
C:\Users>cd .. and “Enter”
C:\>
C:\>cd THub and “Enter”
C:\THub>
8. At the THub folder type in “ADB devices” and “Enter”
9. You should get an output similar to this:
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
01545CAB0B015004 device
C:\THub>
10. You now have ADB access
11. Try “adb shell” and “Enter” to enter ADB and then “ls” and “Enter” to get the THub Root folder listing
What next, I don’t know but at least we have ADB access?
I have been trying to copy system files to my SD card to have a look at them but have no success.
Does anyone know how?
Here is the site I uploaded the files to:
"You can fill in the missing bits"
xxx.mediafire.com/download/voku3wnuff5s2ef/THub.zip
NOTE: There is also a file called “UniversalAdbDriverSetup6.msi”.
I don’t know what it is for, but I installed it anyway. It MAY be necessary for the above method.
Firstly, I understand this is an old thread but quite a lot of us Australians have this THub 2 now because Telstra seem to basically be handing them out like shots at a party.
As far as I know this thing still has no root access. You can get into ADB with it without too much trouble.
But what I really want to know is how I can get root access with SuperSU so I can install something like AdAway to remove the seemingly ridiculous amount of advertisements that apps and etc. come with.
In addition to that, after installing just TWO small apps. It seems the device's internal memory is already full and it cannot install any more apps.. I need root access in order to run Apps2SD so I can move some apps to the SD card that I have purchased for it.
Does anyone, and I mean anyone have any ideas about how to root this thing? There has to be some Australian who has a rooted version with SuperSU running.
I tried 'towelroot' but the device just rebooted (meaning it failed) and then when I ran the .apk again it said that the device was unsupported.
It's one thing to be able to get access to the root partition (which is possible over ADB) but it's another to be able to run apps with root privileges.
For any information.
The specs are:
Manufacturer - Technicolor
Operating System - Ice Cream Sandwich 4.0.4
Processor - 1 GHz dual core
Screen - 7″ (1024 x 600 pixels)
Camera - 1.9 MP rear camera, 1.2 MP HD front camera
RAM - 1GB
Storage - 2 GB Internal with an expandable Micro SD card slot (1GB internal usable)
Battery - 6000 mAh (non-removable)
I know it's nothing amazing, but if I could root the device and change the DPI, remove advertisements and install a few hacks. I'd get so much more out of the device.
I picked it up in almost perfect condition second-hand off eBay for only $15. They're worth $360 AU brand-new.
If anyone has any information at all, please do post something. My apologies again for bumping a super old thread but otherwise I was going to just start my own.
Possible to restore system partition
Hi Guys,
I done goofed.
I killed my T-Hub by flashing a corrupted system partition and now the device wont boot and only displays the Telstra logo at the boot loader. I do have a backup of my system partition however I cant work out how I would perform the restore. The boot loader will not allow an ADB connection so no luck there.
Im thinking JTAG may be my only option. I have experience with this on other devices but i cant find the JTAG terminals on this thing? I must have tapped about 60 different combinations of testpoints now and have only been able to get console out of the radio module which is obviously no good for talking to the kernel.
Any help would be greatly appreciated.
Cheers,
Swamp
SwampCrack1210 said:
Hi Guys,
I done goofed.
I killed my T-Hub by flashing a corrupted system partition and now the device wont boot and only displays the Telstra logo at the boot loader. I do have a backup of my system partition however I cant work out how I would perform the restore. The boot loader will not allow an ADB connection so no luck there.
Im thinking JTAG may be my only option. I have experience with this on other devices but i cant find the JTAG terminals on this thing? I must have tapped about 60 different combinations of testpoints now and have only been able to get console out of the radio module which is obviously no good for talking to the kernel.
Any help would be greatly appreciated.
Cheers,
Swamp
Click to expand...
Click to collapse
I'm completely new to this. What ROM would i look for to install on the THUB if any? And if i could install it?
clearburn said:
I'm completely new to this. What ROM would i look for to install on the THUB if any? And if i could install it?
Click to expand...
Click to collapse
sorry but no one has developed a ROM for this device, there is no demand
Madaz2 said:
sorry but no one has developed a ROM for this device, there is no demand
Click to expand...
Click to collapse
Thanks. I thought there might have been a rom from the basic device that didn't have all of the Telstra stuff on it.
It is currently a brick
if you can root it then you could install Titanium backup and uninstall the bloatware off of it
Some moderate success
I have had some moderate advancements of late.
I can get temporary ADB root using the directory traversal exploit
.
While the above method gets you a root terminal session, as it screws with some settings the device is nearly unusable due to screen flicker and general lag. I guess the exploit breaks some settings. Does anyone know how to leave the exploit in place and restore the settings file to eliminate the flickering and lag?
I have been able to export the system partition, edit it (add su.bin and SuperUser.apk) then swap the system mount so the device uses my edited system partition as described by malleus. When I try to flash my partition the device reboots and is in a semi brick state (reboot loop, stuck on boot loader Telstra logo).
I was able to obtain the OTA update files by getting an old 2.3.7 device, rooting it then grabbing the OTA files using ADB once it had downloaded them. These OTA's can be flashed from an SD card (ext4 format) in 3e recovery. This was a good bit of progress as it means I can restore from a bricked state. If anyone needs them, the files I have are:
Product_4.0.4_3.38-FOTA
Product_4.0.4_3.48-FOTA
This is all new territory for me but i think I am getting close to achieving full, persistent root in 4.0.4.
Any help would be appreciated.
I would be very interested in your progress as I have one of these but in default state it is only usable as a phone on the DECT base.....
Having some useful apps running off an SD card would help no end (like multimedia remote for my home theatre system)
Cheers,
Alex B
SwampCrack1210 said:
I have had some moderate advancements of late.
I can get temporary ADB root using the directory traversal exploit
.
While the above method gets you a root terminal session, as it screws with some settings the device is nearly unusable due to screen flicker and general lag. I guess the exploit breaks some settings. Does anyone know how to leave the exploit in place and restore the settings file to eliminate the flickering and lag?
I have been able to export the system partition, edit it (add su.bin and SuperUser.apk) then swap the system mount so the device uses my edited system partition as described by malleus. When I try to flash my partition the device reboots and is in a semi brick state (reboot loop, stuck on boot loader Telstra logo).
I was able to obtain the OTA update files by getting an old 2.3.7 device, rooting it then grabbing the OTA files using ADB once it had downloaded them. These OTA's can be flashed from an SD card (ext4 format) in 3e recovery. This was a good bit of progress as it means I can restore from a bricked state. If anyone needs them, the files I have are:
Product_4.0.4_3.38-FOTA
Product_4.0.4_3.48-FOTA
This is all new territory for me but i think I am getting close to achieving full, persistent root in 4.0.4.
Any help would be appreciated.
Click to expand...
Click to collapse
Has anyone made any progress on this?
I have two of these tablets that have sat unused since I got them from Telstra. I really just want to update it to at least 4.1, but there's no official release from Telstra for the T-Hub, and I don't think there will be. Are ports entirely unfeasible?
Do you think I could contact Technicolor? What should I say?
P.S. there is a recovery mode, because I've booted into it.
hxxp://imgur.com/O0uq4Uk
MODERATORS: Please humor me on this... instructional writing is NOT something I'm good at, so I spend many hours writing these pages. It will take time - many weeks - for the entire "how to" to be completed. I think it'll be worth it.
PLEASE DO NOT REPLY TO THIS POST. I've created a separate thread for discussion and Q&A:
http://forum.xda-developers.com/showthread.php?p=34234642
This is NOT a new wiz-bang overvolting underclocking souped up power ranger wonder-kernel. If you're looking for a kernel to load on your phone for daily use, this thread isn't for you.
This is a thread for developing a kernel that works in the Samsung Galaxy Note II for AT&T (SGH-i317.) That previous sentence is carefully phrased: The thread is for DEVELOPING the thread. It's not a "download this kernel" thread. As a matter of fact, I will NOT be posting a precompiled kernel or installer for the kernel.
I'm hoping to try and share my experience making these things so that YOU can do it on your own... without my help. In that regard, this will likely start as a "HOWTO" type of thread, and hopefully move into actual development discussion. On the other hand, it is NOT a classroom.
My intended audience includes existing developers with little android experience, or even experienced android developers that would like to tinker with kernels. I'm sure even non-developers who want to learn might be able to pick something up from this. I fully expect that I'll be writing things that people already know - and much of this will be boring "review" for many readers. Remember that while "you" might already know something, someone else reading it might not. (This is something I often forget myself. When it happens, please remind me.)
There are a couple things you should know about me...
First and foremost, you have to understand that I'm not a "people person", I'm sarcastic, and I'm a horrible teacher. I also expect a certain amount of technical ability. If I provide a suggestion that you go to "http://source.android.com/source/index.html" and follow the instructions for setting up a build environment on a linux-based machine, I expect you to understand that you need a web browser to go to the URL, that you have to type the URL into the browser (or just click the link), and that you read the webpage and figure out that "Initializing the Build Environment" is probably the proper thing to click. If a person has issues with that, then there really isn't anything I can do to help. It might be because they are beyond all help, or it could be because I'm a grumpy engineer. Either way, I'm sorry - please move on.
I hope to retain the patience to walk people through setting up a github account, branching a stock kernel, pulling that kernel source to your own machine, insert the files for a ramdisk, compiling that kernel, manually pushing that kernel to your own device (for testing), writing an edify script (for installing the kernel), and packaging it all together for installing via a recovery-type program.
Once we have a working kernel, I intend to walk any remaining readers through the process of "cherry picking" (not nose picking) changes from another open source project into this kernel. This is a fairly common practice among open source developers where individual changes from one project can be copied to another. Many of the kernels posted on XDA are made up of nothing but cherry picking.
Then, I hope to add some simple modifications to that same kernel, and explain what those modifications are, why the are done, and HOW they are done. There will be no "new" features being added here... just reinventing the wheel (at least as far as I'm planning.) Actually, these "modifications" will probably be copies of the work of another for the sake of simplicity (and the fact that most of the simple things worth doing have likely already been done.)
There are many steps in between all these, of course. Kernel logs, kernel configs, troubleshooting, recovery, etc.
You will need to have a linux machine suitable for building linux kernels. It doesn't matter if you have a dedicated machine for it, a "dual boot" system, or even if you run it in a virtual machine. (It just so happens that I typically run it in a VM.) We aren't building the entire linux system, just the kernel, so you won't need 50GB of free drive space. No, I don't know exactly how much space you'll need. Plan on 15GB and you should be fine. You'll have to know what adb is, have it installed, AND have it working. That's something I won't walk anyone through - there are plenty of tutorials on the web for it and if you can't get that basic part done without help, you should consider just using your android phone and not developing with it. Really, "adb" is a fundamental android tool and is worth understanding even if you don't want to tinker with kernels.
You will need to have some tools (a toolchain) installed.. However, we'll get to that a bit later. There are MANY prebuilt toolchains floating around, and there's no reason not to take advantage of them. A text editor on that linux machine will be useful. I won't make any particular suggestions, but if you have no idea what to use, "gedit" is a servicable editor, is included in most linux distros, and is good enough.
Keep in mind that I have a real life outside of XDA. A full time job, a wife, two kids (7 & 9) and my own hobbies. There might be significant delays between "chapters" of this HOWTO. There's really nothing I can do about that. It's life.
What do I expect to get out of this? I expect that people LEARN methods, ideas and concepts... and that we DISCUSS and SHARE development. I'm freely giving my knowledge and the lessons I've learned, so I expect that people who learn from it will also give that knowledge freely to others. If this thread gets you going with building kernels and you figure out how to solve some problem as a result, I expect that you'll share that solution just as freely. I expect that when you start building kernels for other devices, you don't bribe people with "extra features" if they give you money. I expect that you give back to the open source community what the open source community is giving you - with interest.
Why am I doing it and What am I getting out of it myself? I'm not completely sure, to be honest. Chances are very high that I'll get extremely frustrated from doing this and regret it. On the other hand, I hope I'll learn from the experience and that I'll learn from the people who participate in the thread. I don't care what you currently do or don't know - there's always something I can learn from you.
I also have to admit that I'm doing this because I'm tired of seeing the "development" subforums on XDA looking like app stores with support threads instead of places where people share and discuss development.
The Build Machine
A short note: There might be some confusion about the use of the "cd" command without any parameters found in a few places. These are intentional, and have the effect of "change to the user home directory." I often use these before creating a new directory to ensure I'm creating it in a "known" location.
The build machine, as I mentioned earlier, should be a linux machine. For the sake of simplicity, (and because I'm too lazy to explain each and every possible program you'll need, how to get it from each linux distro, etc) I'm going to suggest that you follow Google's instructions for setting up your environment. Not only will this ensure you have everything required (except for adb and a toolchain), but also help me to know what kind of system I'm helping with. More advanced users might want to ignore this and set up their own build environment. That's fine too - but please don't ask me to help with it later.
In case you're wondering, I'm actually creating a new virtual machine for the sole purpose of this HOWTO so that I can make sure that each step I give actually works. Here are the specs of the VM I'm creating:
Ubuntu 12.04(LTS) 64 bit on a 30GB HDD with 8GB of RAM and access to 2 processor cores.
If you are doing a fresh install of Ubuntu for this, I'd suggest, after installing it, to press the "Dash Home" button near the upper left of the screen and typing "terminal" and clicking the icon for "Terminal." This will start a command line prompt in a window. It will also put an icon for the terminal program on the toolbar along the left side of the screen. RIGHT-click this icon and choose "Lock to Launcher." This will make it easier to start the terminal program in the future. (you'll need it.) Do the same thing for "gedit" (the icon name comes up as "Text Editor") if you don't already have another text editor you prefer.
If you are doing a new Ubuntu install, I'd suggest running the "Update Manager" and installing available updates.
From this point forward, I have to make certain assumptions about the technical ability of the readers. One of those assumptions is that you'll have the technical ability to follow the instructions I give. I simply cannot spend the time and space to break down HOW a user might "create a file as the root user and copy lines to it." The honest and blunt truth is that if you aren't already able to do that, the rest of this HOWTO will be a nightmare for (and me.) This isn't to be mean, rude, nasty or anything else - we all had to learn addition and subtraction before long division.
Time to begin!
Please go to the following URL and follow the instructions for initializing a build environment on a linux (Ubuntu) machine:
http://source.android.com/source/index.html.
There are instructions here for setting up on Mac OS X, but I have to be completely honest in saying I don't know if kernel development will work in OSX - I've never tried it. You can if you want, but I won't be able to help you getting the machine set up. If you're using a linux distro other than one of the suggested Ubuntu versions, you'll need to read the instructions given and figure out how to apply them to your own installation. Not all of the packages it wants installed are actually needed for kernel development, but I'm too lazy to pick through them. They really don't take too much space.
You will probably encounter an error when you get to the step for the java JDK. (If you don't, then you aren't following the directions.) The java JDK is no longer available when following Google's instructions (and they never bothered to update the page.) Don't worry about that, as we don't need java for kernel building.
For the "Configuring USB Access" section, you'll need to specify a different line for the udev rules (so it sees a Samsung phone.) You can either add this line to the end of what Google provides, or use this single line instead of what they provide (I did the latter on my VM):
Code:
SUBSYSTEM=="usb", ATTR{idVender}=="04e8", MODE="0666"
As an alternative, you could also just copy the following line into a terminal window :
Code:
sudo sh -c 'echo SUBSYSTEM==\"usb\", ATTR{idVender}==\"04e8\", MODE=\"0666\" >> /etc/udev/rules.d/51-android.rules'
If your phone is already plugged into your computer's USB port, those changes won't take effect until after you unplug the phone and plug it back in. If you are using Ubuntu in a VM, you'll probably need to perform some action so the VM takes over that USB port and redirects it to the VM.
Some versions of Ubuntu will pop up dialogs asking what to do with the recently connected device (or even show an error or warning saying that it's unable to lock the device.) If this happens, make the dialogs go away: Select "do nothing" for prompts asking what to do, and just "OK" for any error or warning. We don't want to access the phone as a media player or camera or even as a MTP device. We only need "adb" access!
A short word about adb: We actually don't need to use adb for this. However, it greatly simplifies repeatedly copying kernel image files to the phone, running a shell on the phone, rebooting the phone, getting into recovery, etc. Anyway, if you do kernel development and don't have adb, people will laugh at you. It'd be like using a fork to eat noodles in Hong Kong.
As mentioned previously, after you get the basic machine going, you should follow the steps for initializing a build machine at http://source.android.com/source/index.html (and not worry about the error when trying to install the java JDK.) Be careful that you follow the steps for the version of Ubuntu that you have... the required package list for 10.04 is different than the package list for 12.04. (So if you blindly copy/paste the commands from the wrong sections, you'll get errors... I did when I copied the 10.04 package list for my 12.04 machine.)
There's still a few more things needed. For example, we spent the time editing those udev rules so linux would "see" the phone and we can use "adb" but we haven't actually installed "adb" yet. For that, we'll go to this link: http://developer.android.com/sdk/index.html
There's a few different bundles on this page, as well as some other things. We actually only want a very tiny subset of a subset of what's on here. Near the bottom of the page find the section for "Download for other platforms", and the "SDK Tools Only" section below that. The actual download we want is the SDK tools (only) for linux. As of my writing this, the file is named "android-sdk_r21-linux.tgz." Download that to your linux machine.
You'll then need to unarchive the "tarball" somewhere on your machine. If you don't have a great place in mind to put it already, and assuming you're using a pretty default Ubuntu system, you can open a terminal window and copy the following commands:
Code:
cd
tar xzvf Downloads/android-sdk_r21-linux.tgz
This will end up creating a directory called "android-sdk-linux" and sticking everything in it. But Wait! "adb" isn't actually included with that. So, assuming you've been following along with me so far (and if you haven't, you'll have to adjust the following commands) copy the following commands:
Code:
cd android-sdk-linux
tools/android
This will pop up a window letting you pick and choose which SDK elements you want to install. There's a LOT of stuff here, but all we need are the "Android SDK Platform-tools" (under "tools".) Check that box and click "Install 1 package..." Accept the license and click "Install." When it's done, click "Close" and then close the "Android SDK Manager" window.
To access adb, you might type something like "~/android-sdk-linux/platform-tools/adb devices" That's a pain in the rear, so how about we simplify things? Copy the following commands in that terminal window:
Code:
cd
mkdir bin
cd bin
ln -s ../android-sdk-linux/platform-tools/adb adb
cd
echo 'PATH="$HOME/bin:$PATH"' >> .bashrc
Those lines will create a symbolic link (like a windows shortcut) from the actual adb program to a private "bin" Then it tells "bash" (which is the default command interpreter in ubuntu distros) to look in that private bin for commands you type. Some users who aren't setting up brand new ubuntu systems for this might want to check that they are actually using bash and that $home/bin isn't already in their path - and adjust this accordingly. You'll need to close any 'terminal' windows you have open and restart them in order for this to take effect. (Advanced users: I know this isn't the best way to modify the PATH on a default Ubuntu box, but it's the easiest way to get it working. If you're advanced enough to know that, then you're also advanced enough to do it better on your system.)
Now, you SHOULD be able to plug your samsung android phone into that ubuntu machine, wait a couple seconds (and close any silly warning dialogs about locking the device) and adb will see your phone. To test, use the command "adb devices" (in a newly opened terminal window.) You should see something like "List of devices attached" followed by a string of letters/numbers some spaces and the word "device." For example:
Code:
List of devices attached
12a34b567c890def device
There's only one more thing left to do for this post: Install the toolchain.
A "toolchain" is a set of tools that we use to get from a bunch of source files to a kernel that can be installed. We could build a toolchain from GNU (or other) sources, but google has made this much easier for us by providing a prebuilt toolchain, and even made it easy to get. Personally, I'm EXTREMELY happy about that, as this "page" of the HOWTO is getting entirely too long. (I hope XDA doesn't crash when I copy it into a new post!)
Copy the following in a new terminal window:
Code:
cd
git clone https://android.googlesource.com/platform/prebuilt
This might take a while to download, so go ahead and distract yourself while it's going. When it's done, you've finished this post!
I had originally intended to start discussing git and github in this post, but I'm putting that off for the next post when I'll also have you fork the actual kernel source and pull the source to your build machine.
Before I go on, I'm going to take a little side trip into some open source (and GPL) concepts. I'm not a lawyer and nothing I write should be interpreted as legal advice.
The linux kernel, which is the kernel that android uses, is open source software and licensed under the "GPL." Without knowing all the legal mechanisms, this means that the kernel is freely available. It's free to use and the source is also free. Anyone who distributes a product that makes use of this kernel is REQUIRED to make the source available for free. This includes any changes that a company might make to the linux kernel. As those changes are a derived work, it must retain the free licensing of the main body. That includes even large companies like Samsung, HTC, Google, TiVo, Netgear, etc. There are some things not covered such as separately compiled kernel modules (like some ethernet drivers), but non-GPL licensed kernel modules are fairly rare.
This same rule applies to you and I. If you or I distribute a linux kernel alone or as part of a larger product, we are bound by the licensing of that kernel to make our source code available to anyone who asks. If you post a linux kernel on a website or any other form of distribution, you are legally and morally required to also ensure that the source code for that very same kernel is available.
I feel very strongly about this, so if you have a problem with it, please do me and the entire community a large favor and go away.
In addition, here on XDA, you are required to ask permission to use kernel code that another member wrote. This isn't a GPL requirement, but an XDA one. For that reason, I've asked a couple of other dev's on here if I could use some of their modifications in this HOWTO (and in the spirit of open source software, each one welcomed me to do so.) Even if it weren't a requirement here on XDA, it's always polite to ask the author if you can use their works. In almost all cases, they'll agree to it. In addition, they'll often offer tips and suggestions for using certain things. For example, they might warn you that if you want to cherry pick a certain change, you should also get another one or things will break.
Before reading this page, I want to point out that I'm fairly weak on git and github. I might be giving instructions that use the incorrect phrasing or are just simply the wrong way of doing things. If you see me doing this and you know better, PLEASE post a message on the companion discussion thread. If there's a better way, I want to know about it, and I want to update this post to reflect it. Keep in mind, though, that I'm trying to simplify things here for the HOWTO, so if your suggestion is more complex (or would require me to type two pages to explain it) I might not update this post with it.
Most linux-based kernel development these days uses a form of version control (source control, revision control, etc) that will catalog each change made to the source as a change set (or a commit.) Of these, "git" is the most prevalent. Git was written from the ground up specifically for linux development (by the folks who originally created linux) and to meet the very distributed needs of linux kernel development. For more information on git, wikipedia has a good article: http://en.wikipedia.org/wiki/Git_(software)
Along with "git" as the version control system, we'll be using Github as a free hosting service for out git repositories. Github acts like a server for projects using git for revision control. While the site is somewhat geared as a "social" code sharing website, you don't have to be a friendly person to use it. (They even let me use it!) In fact, it's perfectly acceptable to use Github as a server for a project that only you are working on. It's extremely well suited to act as a remote backup for your code projects (which, I admit, I abuse it as) and it serves one other purpose for us: It's an extremely easy way to meet the legal requirement that our linux source is freely available.
Git (and Github) offers a really nice mechanism for a person (such as a reader of this thread) to start a new git project based on the source code of someone else (such as an original kernel project I'll set up for that purpose.) In git's terms, you will "fork" my project into something that belongs to you. Internally, you're only actually creating a link in your project to a very specific version of mine, but it appears and acts like a full copy. (In ways, it's actually BETTER than a normal copy.)
You can, of course, also create a new project from scratch and add new files directly. However, it's considered a better practice to fork from an existing project if possible. This saves a considerable amount of space on the Github server as it's really only keeping a single copy of that original source. It also makes it much easier to pull in changes from the original project (and push changes back to it.) Unfortunately, it's sometimes difficult to find a "clean" branch to fork from. For the purpose of this HOWTO, I've created a clean copy of the SGH-i317 sources in a project in Github and you'll be able to fork from that.
Before forking my project, you'll first need to create a Github account if you don't already have one. Just go to http://github.com and click "Sign up for free." You'll be presented with a page reminding you of the high cost of this service (free) and asking you for a username, email address, and password. Fill in that information and click "Create an account" (which implies acceptance of their terms of service and privacy policy.) That's it. You now have a Github account.
While logged in with your Github account, you want to find a project to fork from. As mentioned, I have a pristine copy of Samsung's actual source release for the i317 set up for just this purpose. Up at the top of the Github webpage, you can search for that project. Just type "linux_kernel_sgh-i317" into that search bar, and you should get a result pointing to "garyd9/linux_kernel_sgh-i317." If you click that link, you'll end up at "https://github.com/garyd9/linux_kernel_sgh-i317"
Finally, you'll go ahead and fork a copy of that for your own use. This is a highly complicated procedure so please pay very careful attention to these instructions: On the upper left of the Github webpage, there's a button labeled "Fork." Go ahead and press it. That's it. (Some people actually mess this up. I have no idea how.) You now have, at least on the github site, your own copy of the kernel source. Leave that browser window open while doing the next step. It contains something we'll need very shortly...
(Parts of this are taken from Github's own "Bootcamp/Set Up Git" webpage at: https://help.github.com/articles/set-up-git#platform-linux I'd encourage you to go to that link and review it as well.)
Back on your build machine, open up a 'terminal' window and type the following command, replacing "Your Name" with your own name. Leave the quotation marks in place.
Code:
git config --global user.name "Your Name"
This is telling your local git software what your name is. This shows up in all your git commits, so you probably don't want to put something stupid here.
Also in the terminal window, you'll type this next command. This time, replace "[email protected]" with the email address you used to register on Github. (This is important!)
Code:
git config --global user.email [email protected]
Finally, there is one more command to type. This last one will tell git to cache (store) your Github account information so you don't have to type a password every single time you push to the server. (By default, it caches for 15 minutes. Read the Github bootcamp article linked above to find out how to extend that.)
Code:
git config --global credential.helper cache
Before we tell git to actually pull the source code from Github, there's one more little organizational thing I like to do. I like to keep all files related to building of a kernel in a single directory on my linux machine. There's more than just a kernel required for building the kernel! So, go ahead and copy the following commands to your terminal window:
Code:
cd
mkdir kernel-howto
cd kernel-howto
Now, everything related to this HOWTO can be put into one place: That newly created "kernel-howto" directory that we also changed into.
Now, it's finally time to get the source code to your build machine. Remember I suggested leaving the browser window open on the github page showing your newly forked project? Well, what we actually want is the page URL. It should look something like "https://github.com/yourUserName/linux_kernel-i317" "yourUserName" should be your Github username. We need that URL and add ".git" to tell git what to fetch. In this case, we'll be using the "clone" command which basically just tells git to make a copy of the remote project. You won't be able to just copy/paste the following command into your terminal window, because you'll have to change at least the yourUserName part of the URL. Go ahead and type this command (making the change needed.)
Code:
git clone https://github.com/yourUserName/linux_kernel_sgh-i317.git
When the command finishes, you'll have a new sub-directory inside of "kernel-howto" that's called "linux_kernel_sgh-i317". Go ahead and change into this directory.
Code:
cd linux_kernel_sgh-i317
There's only one last thing I want to do here before ending this post, and that's to ensure anyone following this HOWTO is able to push changes. To do this, just copy the following commands that will create an empty (and meaningless) file, add it to git, commit it as a change, and push it to the server.
Code:
touch HOWTO
git add -A
git commit -m "test commit"
git push
After the "git push" command is sent, you should be prompted for your github username and password. After you enter that information, you should see something similar to the following (the characters before "master->master" will be different):
Code:
To https://github.com/yourUserName/linux_kernel_sgh-i317.git
e3d49d2..ea9fbe9 master -> master
You can also go back to your Github page for this project to see the commit on Github. If you aren't on that page anymore, log in to Github, and click the linux_kernel_sgh-i317 repository on the right side of the webpage. Then find and click the "Commits" link (which is between "Files" and "Branches" a few lines down from the top of the page.) The top commit will be the "test commit" that you did on your build machine and pushed to Github.
The kernel isn't quite ready to be compiled. We'll get to that in the next post. In the meantime, if you'd like to learn more about using git and github, there's an interesting interactive walk-through style tutorial at http://try.github.com.
gitignore
When we work with the kernel, we will generate a lot of temporary files that we don't want to put into the git system or upload to GitHub. To have "git" exclude those files from consideration, a file (or set of files) called ".gitignore" should be created that tells git what to ignore. A more complete explanation of the .gitignore file can be found here: https://help.github.com/articles/ignoring-files
Instead of having you create and edit several different ".gitignore" files, I've made a patch that you can apply directory to your kernel tree, using git, that will add those .gitignore files. The following commands, which you should copy to a terminal' window, will change into the kernel source directory, fetch the patch file (using wget), apply the patch (using git am) and then delete the patch file (as it's no longer needed.) If you have the kernel source in a different directory, you'll have to adjust one of the "cd" commands accordingly. After deleting the patch file, we push those changes to the github server. I'll explain the various git commands more in depth in a later section of this HOWTO.
Code:
cd
cd kernel-howto/linux_kernel_sgh-i317
wget https://raw.github.com/garyd9/kernel-howto-misc/master/add_gitignores.patch
git am < add_gitignores.patch
rm add_gitignores.patch
git push
Just a few more things...
The next item to mention before compiling the kernel is the kernel config file. Linux, as a kernel, can be used on literally thousands of different configurations. However, each platform might require a different kernel. How this works is that when the kernel is compiled, a kernel configuration is supplied that tells the compiling tools which drivers to include, how to configure them, what kind of processor the target platform has, etc. For now, we'll just use a default configuration file that Samsung provided with the kernel source. That configuration is called "t0att_04_defconfig" and (luckily for us) actually seems to be accurate. When building for another device, don't assume that the kernel configuration provided with the source is accurate... I've had at least one case when the configuration Samsung provided for their own device simply didn't work for that device. Later in this HOWTO, we'll be discussing the kernel configuration much more in depth, and even making changes to it.
Next, we need to talk about that prebuilt toolchain we downloaded earlier in the HOWTO. When compiling the kernel, we need to tell the system to use that very specific toolchain for doing the work. What we're actually doing is called "cross compiling", which means we're compiling for a different platform than the compiler itself is running on. In this case, we're running on an x86 (or x86_64) platform, but compiling for the "arm" platform. To tell the system which toolchain to use for cross compiling, we will use a command line parameter that defines "CROSS_COMPILE" to point to the proper toolchain files. Assuming you've been following this HOWTO (and if you haven't, you'll have to adjust this accordingly every place it occurs) that will look like this: "CROSS_COMPILE=$HOME/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-"
Finally, there's just one more thing before we can compile. The actual tool we use to kick off compiles is called "make." Make doesn't really know much about compiling software, but it's a great tool for figuring out when things need to get done and for doing them. By default, "make" reads a file called "Makefile." A Makefile describes how files might be dependent on each other, how to compile files and put things together. Because of the magic of a Makefile, you won't have to recompile the entire kernel each time you make a minor change. Instead, "make" will only recompile what's needed to include updates to the source.
Are you ready for actually compiling? Okay, go ahead and copy these commands. There are two commands here. The first one just prepares the kernel config file, and the second one compiles the kernel. As always, if you've made changes to paths (locations) of things, you will have to edit these commands.
Code:
cd
cd kernel-howto/linux_kernel_sgh-i317
make arch=arm t0att_04_defconfig CROSS_COMPILE=$HOME/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-
make CROSS_COMPILE=$HOME/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-
Depending on the speed of your machine, this can take a while to complete. You'll be witness to many different files getting compiled and linked together as it runs. When it's done, you'll see something like this in your terminal window:
Code:
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
Building modules, stage 2.
MODPOST 7 modules
CC arch/arm/mvp/commkm/commkm.mod.o
LD [M] arch/arm/mvp/commkm/commkm.ko
CC arch/arm/mvp/mvpkm/mvpkm.mod.o
LD [M] arch/arm/mvp/mvpkm/mvpkm.ko
CC arch/arm/mvp/pvtcpkm/pvtcpkm.mod.o
LD [M] arch/arm/mvp/pvtcpkm/pvtcpkm.ko
CC drivers/interceptor/vpnclient.mod.o
LD [M] drivers/interceptor/vpnclient.ko
CC drivers/net/wireless/bcmdhd/dhd.mod.o
LD [M] drivers/net/wireless/bcmdhd/dhd.ko
CC drivers/net/wireless/btlock/btlock.mod.o
LD [M] drivers/net/wireless/btlock/btlock.ko
CC drivers/scsi/scsi_wait_scan.mod.o
LD [M] drivers/scsi/scsi_wait_scan.ko
Congrats - you've just compiled a linux kernel for Android.
There's only one problem: It's completely useless in it's current form. If you were to install that kernel on your phone, it simply wouldn't boot. What it really needs now is a ramdisk.
The next sections (plural) in this HOWTO will discuss what ramdisks are, how to extract one from an existing kernel, and how to package a ramdisk image with a kernel to make a flashable boot image. We also need to talk about partitions, block devices, making backups, using the 'dd' command, and a few other things.
You didn't think this was easy, did you?
It would be a great idea to get familiar with the "adb" tool; particularly the "shell", "pull" and "push" commands. (Use Google to search for "how to use adb.") Over the next several sections, we make use of these adb commands to copy files to and from the Android device and to interact with the device's operating system. This document also assumes that the device has already been rooted.
To get a "rooted adb shell" on a Samsung TouchWiz device, you'll have to have your device attached to and seen by your linux build machine, and use the command "adb shell" in a terminal window. Now, turn on the display for your android device and unlock it (if required.) Finally, back in the terminal window on the linux build machine, type the command "su". You Android device might pop up a prompt asking to give permission for the root access. If it does, grant the access. After the su command, the prompt should have a "#" symbol (instead of a "$" symbol.)As you might already have realized, just having a linux kernel is interesting, but not extremely useful. The kernel can boot, but once it does, it needs a filesystem to load programs from, to store data, etc. In the UN*X world (which linux is derived from), there's a single root to all filesystems, and other filesystems mount (attach) to that single root. Android (and many other embedded systems) use a root filesystem that isn't real - instead it's a virtual filesystem called a RAM Disk. Briefly, a RAM Disk is a portion of the devices RAM that's put aside and make to look like a persistent storage device. Unlike a real storage device, the RAM Disk (usually typed as "ramdisk") is completely erased each time the device is rebooted.
Linux allows taking that concept to a higher level by allowing a kernel to specify an initial ramdisk image. The image is a snapshot of a portion of an actual filesystem which is used to create the ramdisk. That, in turn, is specified in the kernel configuration to be the "initramfs" - which means that it becomes the root filesystem for the entire device. ("initramfs" is short for "Initial RAM FileSystem.") The initramfs image is embedded within the kernel image, and each time the kernel boots up, it uses that image as a root filesystem. Being it's a ramdisk, we can even make changes within the root filesystem after the device boots, but those changes will be wiped out the next time the device reboots.
Some other initramfs features supported by linux, but that don't seem to be used in Android, include the ability to switch root filesystems from within the initramfs, and the ability to store the initramfs as a seperate file (instead of embedding it in the kernel image.)As well as being an anchor for all the persistent (and non-persistent) storage devices in the phone, the Android initramfs also kick-starts the Android OS itself. (Remember that "linux" is a kernel, not the OS!) It usually contains some lower level system utilities (such as the files needed for adb functionality), a few kernel drivers that might not already be compiled into the kernel, a few config files used at the early stage of booting the device, and scripts used to get the rest of the system going. On some Android devices, the initramfs also contains the files needed for booting the phone recovery. (On other phones, including most that have been released since Android 4.0, recovery has it's own private kernel.) Remember, however, that the initramfs uses RAM, so it shouldn't be bloated with things that could be stored in real persistent storage.
Another aspect of using the initramfs that can be useful is that it allows booting at least a minimally functioning linux system in cases when the rest of the Android OS doesn't load properly. That minimal system could even be used to manually flash a different kernel, recovery, or even the entire firmware for the device.
Now that we have an idea what the initramfs is, and why we need one, the question is how to obtain one. In most cases, it's usually better to at least start with a copy of the initramfs already used by our Android device. This way, we know that everything needed in the initramfs already is there. We can (and will) make changes to it later. The best way to get an unmodified copy of the kernel's initramfs is to use a special tool to pull the ramdisk out of the kernel image.
For this HOWTO, we'll start with a "stock" kernel image (instead of a custom image that might have already been modified.) This gives us a known starting place, and ensures that files haven't been modified by a previous kernel developer. There are a few ways to get this kernel image. Often times, the easiest is to find one online in either a "recovery" style zip file, or packaged in a proprietary file such as Samsung's ODIN tar files. If you haven't installed a custom kernel on your device, you can also usually extract the kernel image directly from our phone.
The remainder of this section will be devoted to the information needed to extract a kernel image from the phone. Even if you don't have a stock kernel installed, it would be useful to read the information and go through the steps. The knowledge (and experience) will be useful when we have a kernel to install. However, different types of devices might have different device configurations, so some of this information might not be accurate for every device.
The kernel image (along with the device modem, firmware, data, etc) is stored on a special type of "flash" RAM that doesn't lose it's memory when power is removed. It's very much like any type of removable memory (such as a SDCard, USB thumb drive, etc.) Unlike those examples, however, this special storage is built into the phone or tablet. This guide refers to that flash memory as "persistent storage" which indicates storage that retains data even when power is off or the device resets.
The persistent storage on our devices is treated in linux much as a hard drive is treated on a PC. As with a hard drive, the persistent storage is split into logical "partitions" and each partition can be (and usually is) treated as a separate logical storage device. Our devices might contain 16GB of persistent storage space, but that 16GB is partitioned into a dozen or more smaller chunks providing separate locations for storing the kernel, the bootloaders, the files needed for recovery, the system files, the modem firmware, user data, etc.
In linux, physical (and virtual) devices have drivers in the kernel, and are represented by a special virtual filesystem usually mounted (attached) to a directory called "dev" in the root filesystem. Modern versions of the linux kernel usually separate the devices into sub-directories based on category. Persistent storage devices are almost always "block" devices. Finally, individual block devices are given names based on their driver and other ordering information as determined by the driver. Actual devices being represented are called "nodes" but are often also just called "device files" to keep the description simple. (This is an intentional simplification of how the device nodes are created.)
Based on the above paragraph, we know that the device nodes for the persistent storage can be found in a directory called "/dev/block" on our device. To see this, we'll need a rooted adb shell on your device (or rooted shell via a terminal emulator installed on the phone) and to copy the following command:
Code:
ls /dev/block
On most modern Android devices, we'll see a device node for "mmcblk0" which represents the entire built-in persistent storage. There will also be devices for each partition, such as "mmcblk0p1", "mmcblk0p2", and so on. One of those device nodes represents the partition used to store the kernel image (often called the boot image) - and we need to figure out which one. This is an area that can get annoying, as there doesn't seem to be a simple generic way to determine which partition the kernel is stored on.
(NOTE: If someone can give me a good way to determine the boot/kernel partition regardless of platform, please let me know and I'll document it here.)
If we poke around the directory tree in /dev/block/platform, we might be able to find a sub-directory buried in there called "by-name" and, at least on some platforms, we can determine the boot/kernel partition from there. We need to be somewhat careful, as the boot LOADER is most certainly not something we want to mess with - and many platforms can make it confusing when they refer to the kernel partition as the "boot" partition. On the Galaxy Note II, that "by-name" sub-directory is in /dev/block/platform/dw_mmc, and you can see the full list of named partitions by copying the following command to a rooted adb shell running on your device:
Code:
ls -l /dev/block/platform/dw_mmc/by-name
The result of running that command will include the following (or something similar)
Code:
lrwxrwxrwx 1 root root 20 Nov 18 12:39 BOOT -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 20 Nov 18 12:39 BOTA0 -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 20 Nov 18 12:39 BOTA1 -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 21 Nov 18 12:39 CACHE -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 20 Nov 18 12:39 EFS -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 21 Nov 18 12:39 HIDDEN -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 root root 21 Nov 18 12:39 OTA -> /dev/block/mmcblk0p15
lrwxrwxrwx 1 root root 20 Nov 18 12:39 PARAM -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 21 Nov 18 12:39 RADIO -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 20 Nov 18 12:39 RECOVERY -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 21 Nov 18 12:39 SYSTEM -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 root root 21 Nov 18 12:39 TOMBSTONES -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 root root 21 Nov 18 12:39 USERDATA -> /dev/block/mmcblk0p16
This gives us the information we need to determine the kernel partition. It's called "BOOT" and the actual device node is /dev/block/mmcblk0p8. Similar information can be found for other device types as well. For example, on a Galaxy Nexus running CM10, the sub-directory containing this information is /dev/block/platform/omap/omap_hsmmc.0/by-name and on a Nexus7 running pure AOSP 4.2, a similar (but more crytpic) set of information is at /dev/block/platform/sdhci-tegra.3/by-name. Sometimes, we just need to search to find the proper partition.
Once we have the name of the device node for the partition containing the boot/kernel partition, we can use that to actually convert and copy the entire partition to a normal file. The command for doing this is "dd" and the parameters we use need to be typed carefully. A simple typo here can result in overwriting a valid kernel unintentionally. Be paranoid! The following command, which should be copied to a rooted adb shell, assumes that the "boot" (kernel) partition is mmcblk0p8, and stores a copy of that entire image to a file called orig_boot.img on the internal user storage (/sdcard):
Code:
dd if=/dev/block/mmcblk0p8 of=/sdcard/orig_boot.img bs=4096
"if" designates the "input file", "of" designates the "output file" and "bs" is the block size. The block size parameter isn't really needed here, but it tends to speed up the copy by telling "dd" to copy 4096 bytes at a time (instead of 1 byte at a time.)
We now have a boot image (kernel image) that we can use to extract an initramfs from. One last step is needed to get that file transferred to our linux build machine. Open a new terminal window and copy the following commands into it:
Code:
cd
cd kernel-howto
adb pull /sdcard/orig_boot.img ./orig_boot.img
This will change into the kernel-howto directory on your build machine, and pull the recently made image to your build machine. (If using the 'Terminal' program in Ubuntu, you can open a new terminal window by right-clicking on an existing terminal window and selecting "Open Terminal." You can also right-click on the 'Terminal' icon in the Launcher bar and select "New Terminal.")
If you are using a different starting image, such as from an ODIN compatible tar file or CWM Recovery compatible zip file, please find the kernel image within that archive, extract it, and place it in the proper directory, renaming it to match. If you can't find a stock image (or don't feel like searching for one) just execute the following commands to get a kernel image that was extracted from a stock LJ2 SGH-i317 (AT&T variant):
Code:
cd
cd kernel-howto
wget https://github.com/garyd9/kernel-howto-misc/raw/master/boot_orig.img.gz
gunzip boot_orig.img.gz
When Things Go Wrong...
Before going any further, there's something extremely important we must do: We must plan for things to go wrong. No matter how careful we might be, and no matter how smart or talented a person might be, something can (and often will) go wrong. Perhaps a kernel will get corrupted when building, or maybe it will accidentally be copied into the wrong partition on the phone. Bad Things happen all the time, and it's best to be as prepared as possible.
If the bootloader partitions get overwritten or corrupted, there isn't much we can do. Without the bootloader, nothing else can work. If that happens, the only resort might be an actual repair service. That repair will likely cost money, as no warranty covers damage like this caused by the customer - not even the "accidental" things sold by companies like SquareTrade. It's one of the risks that people take when working at this level. (There are people working on modifications that would allow booting the phone even if the bootloader is overwritten, but I'm not aware of any of them being available for the SGH-i317.)
Most of the other partitions can be backed up and restored with a recovery tool. At the present time, I'd recommend using TWRP over CWM Recovery for two reasons: First, it supports backing up the EFS partition that CWM Recovery doesn't. Second, it allows restoring individual partitions instead of restoring an entire backup. If you corrupt the kernel, you can use TWRP to only restore the corrupted boot partition without restoring everything else. It is my understanding that the TWRP people are working on adding support for backing up the RADIO firmware partition as well.
It's possible to accidentally overwrite the recovery partition when performing certain actions. With no recovery, any backup made with TWRP or CWM Recovery would be hard to restore. To deal with that, we'll go through some steps later in this section to make images of certain partitions (including the recovery partition) in order to be able to restore them later if they are overwritten. As well, for most Samsung devices, there are ODIN compatible images containing only the recovery partition. Nexus devices can use a tool called "fastboot" to boot into a recovery image that isn't even installed on the phone.
Finally, at least with a Samsung device, a last resort is to fall back to ODIN to restore the phone to a factory state. That's only useful if a full ODIN firmware is available (or at least an ODIN image containing the partition you need to restore.) At the time of writing this guide, there's no full ODIN image available for the SGH-i317. When you see one, be sure to download it and keep it around. Also learn to use the ODIN tool. Having the image doesn't do much good with you can't use the tool for flashing it! ODIN relies on the bootloader of the device not being corrupted, so even ODIN is useless if you corrupt the bootloader.
In order to manually create images of some of the device partitions, first determine which partitions you want backups of. Keep in mind that the size of the images can get quite large, so don't use this method for the USERDATA (/data) partition. I'd suggest backing up the boot/kernel, recovery, radio, param, and efs partitions using this method. Use the information in the previous section to determine the device nodes for each of those partitions, and then use a command nearly identical to how we copied the stock kernel image to a file. If you have an external sdcard in your device, this is the perfect place to store those images. If we are backing up partitions from a SGH-i317 to an external sdcard, here are the commands we'd copy into a rooted adb shell to get those images:
Code:
cd /mnt/extSdCard
mkdir backup_images
cd backup_images
dd if=/dev/block/mmcblk0p3 of=mmcblk0p3.img bs=4096
dd if=/dev/block/mmcblk0p7 of=mmcblk0p7.img bs=4096
dd if=/dev/block/mmcblk0p8 of=mmcblk0p8.img bs=4096
dd if=/dev/block/mmcblk0p9 of=mmcblk0p9.img bs=4096
dd if=/dev/block/mmcblk0p10 of=mmcblk0p10.img bs=4096
Notice that we're naming the images the same as the device nodes they came from (the of= parameter.) A person could also name them efs.img, param.img, boot.img and recovery.img if they want. For the SGH-i317 device, the 4 images will use a combined 132MB of storage space.
To restore one of these images, we'd use the same 'dd' command, but reverse the "if" and "of" parameters. For example, if we corrupted our recovery partition (perhaps by copying a normal boot kernel to it), we could boot the phone normally, get a rooted adb shell, and type the following commands:
Code:
cd /mnt/extSdCard/backup_images
dd if=mmcblk0p9.img of=/dev/block/mmcblk0p9 bs=4096
Again, be paranoid. I can't possibly stress enough the need for backing up, and doing so frequently.
Now that we have a copy of a factory boot image, we'll unpack that image into it's component parts. There are three tools used for manipulating boot images that we should download and place somewhere on our path. The following commands, copied into a terminal window on our build machine, will take care of that:
Code:
cd ~/bin
wget https://github.com/garyd9/kernel-howto-misc/raw/master/mkbootfs
wget https://github.com/garyd9/kernel-howto-misc/raw/master/mkbootimg
wget https://github.com/garyd9/kernel-howto-misc/raw/master/unpackbootimg
chmod a+x mkbootfs
chmod a+x mkbootimg
chmod a+x unpackbootimg
Before going on, it's important to give credit where due: The three boot image utilities were compiled from sources in the cyanogenmod 10 repository. mkbookimg and mkbootfs appear to originate from AOSP, and unpackbootimg appears to originate from Koush (of ClockworkMod fame.) The sources for cyanogenmod can be found at https://github.com/CyanogenMod.
The three tools are:
unpackbootimg - used to unpack a full boot/kernel image into the ramdisk, kernel, and other files containing certain parameters.
mkbootfs - used to combine or archive a directory structure into a ramdisk image. (The same thing can be accomplished with the cpio utility)
mkbootimg - used to combine a kernel and initramfs image into a boot image that can be installed on a device.
To unpack the parts of the stock boot image, open a terminal window on your build machine and copy the following commands. As always, if paths or filenames have been changed from this guide, the commands should be altered to correspond to those changes.
Code:
cd ~/kernel-howto
mkdir stockbootimg
unpackbootimg -i boot_orig.img -o stockbootimg
ls -l stockbootimg
Here, the -i parameter is used to specify "boot_orig.img" as the image to unpack, and the -o parameter specifies that the results of unpacking the image should be placed in a sub-directory called "stockbootimg".
In the list of commands above, the last one just will list the files unpacked in the "stockbootimg" sub-directory. At this point, the only one of those files that is significant to us is the one named "boot_orig.img-ramdisk.gz." That file is the actual compressed ramdisk image used as the initramfs in the stock kernel. The file ending with "zImage" is the actual stock kernel, and the remaining files contain boot image values that are beyond the scope of this guide. (If someone is planning on manipulating things like the page size or base address, they likely have a skill/knowledge level far exceeding the audience of this document.)
There's really nothing special about the compressed ramdisk image. It's simply a directory structure archived with the "cpio" utility and compressed with gzip. In fact, if you copy the following command to your terminal window, you'll be able to see what's inside:
Code:
gunzip -c ~/kernel-howto/stockbootimg/boot_orig.img-ramdisk.gz | cpio -it
Later, we'll extract the files from the stock initramfs and make some changes. For now, however, we'll just use the compressed ramdisk as it is and combine it with the kernel we built earlier. (Normally when rebuilding the kernel, the kernel modules in the initramfs are replaced with ones from the new kernel compile, but we'll skip that step for now.)
Assuming you've already built the kernel (as described a few sections ago), the finished kernel should exist as ~/kernel-howto/linux_kernel_sgh-i317/arch/arm/boot/zImage. The following command will combine that kernel we compiled with the stock initramfs image we just unpacked:
Code:
cd ~/kernel-howto
mkdir first_bootimg
mkbootimg --kernel ~/kernel-howto/linux_kernel_sgh-i317/arch/arm/boot/zImage --ramdisk ~/kernel-howto/stockbootimg/boot_orig.img-ramdisk.gz -o first_bootimg/boot.img
The "--kernel" and "--ramdisk" parameters should be pretty obvious, and the "-o" parameter specifies where to put the final boot image. There are several other parameters for mkbootimg, but none of them are needed here as the defaults work fine. In most cases, the values for the parameters can be found by examining the files unpacked after running unpackbootimg.
We now have a fully functional kernel that we can install on our device and test with. Connect your phone to the build machine, and run the following commands to copy the new boot image to your phone (but not yet installed it.) This uses adb to first create a new sub-directory to place the image, and then to push the new image into that location
Code:
adb shell mkdir /sdcard/first_bootimg
adb push ~/kernel-howto/first_bootimg/boot.img /sdcard/first_bootimg/boot.img
WAIT! DON'T INSTALL THIS KERNEL IF YOU DON'T HAVE A BACKUP. THIS KERNEL WON'T WORK PROPERLY AND YOU WILL NEED TO RESTORE A BACKUP KERNEL FOR FULL FUNCTIONALITY
The first step to installing a new kernel should always be to ensure that a backup has been made of the device. Once a good backup has been made, there are actually multiple ways to install the kernel. Each, however, just copies the boot image to the devices boot/kernel patition device node. This was identified in an earlier section and for the SGH-i317 is /dev/block/mmcblk0p8. To do this manually, and assuming the device is already connected to the build machine, get a rooted adb shell and copy the following command making any required change to the device node. Make sure to be in a rooted adb shell first!
Code:
dd if=/sdcard/first_bootimg/boot.img of=/dev/block/mmcblk0p8 bs=4096
That's it - it's installed. We can unplug our device and reboot the new kernel into existance.
If a person is using a Samsung device that's supported by Mobile ODIN (developed by Chainfire), they can also use that program to install the boot image directory by simply selecting it as the kernel to flash. This actually tends to be a bit safer than using the 'dd' command, as there's no risk of typing the wrong device node filename. However, the boot image MUST be named "boot.img" for this to work.
When it is done rebooting, you'll be using your new kernel. As we haven't made any changes to the kernel at this point, the only way to tell the difference will be to go into Settings (on the device), and tap "About device" The line for the "Kernel Version" should now include the username you use on your linux build machine. In this particular case, there's another way to determine if we're using the new kernel: Try using the "soft" keys (the 'menu' and 'back' keys on either side of the home button.) They don't work.
Welcome to the Wonderful World of Kernel Development. There's a reason why those soft keys don't work, and we'll discuss that reason (and a resolution) in the next section. For now, we should just restore our kernel backup and wait for the next section to be posted.
After a fully functional kernel is restored, copy the following commands into a terminal window with the device connected to clean up the mess:
Code:
adb shell rm -r /sdcard/first_bootimg
cd ~/kernel-howto
rm -rf first_bootimg
Hello,
I'm the proud owner of an hybrid monster, called THBK1-10.
This is basically an affordable tablet, running both Windows 8 and Android 4.2.2.
10.1 display, running x86 Atom 4cores, 2Gb RAM, 32Gb eMMC, USB host enabled. It is shipped with an external keyboard/touchpad (no port, no battery, no extended storage on it). More informations: http://www.thomsoncomputing.eu/dualboot.html
Windows 8 comes in x86 flavor...
The boot process let you choose Windows or Android.
There is no play store. My main goal actually is:
- (ok) rooting Android part
- (ok) installing Play Store
- (ok) increasing space
- (nok) installing a recovery (CWM/TWRP) allowing you to flash non-signed updates
- (nok) running Linux from an external USB drive
Partition layout: http://forum.xda-developers.com/showpost.php?p=54095052&postcount=8
Rooting / play store guide: http://forum.xda-developers.com/showpost.php?p=55513404&postcount=23
Known clones: http://forum.xda-developers.com/showpost.php?p=54282229&postcount=10
Increasing space with external SD: http://forum.xda-developers.com/showpost.php?p=54914759&postcount=17
Timezone issue Android/Windows: http://forum.xda-developers.com/showpost.php?p=54945950&postcount=19
BIOS default (SlateDroid): http://www.slatedroid.com/topic/106594-thbk110-default-bios-values/
Have fun !
I know there are EXT2 drivers for Windows, and EXT3 is just EXT2 + Journaling (the journaling is an important feature, but it's not part of the security model). However, I'm not sure if any of those drivers can modify file permissions. Alternatively, one could of course hex-edit the Android partition and try to tweak the file permissions that way, but that would require much more understanding of the EXT filesystem than I have. The source code is all open, though...
Thank you. Here is what i did:
a) trying to handle EXT3 fs from Windows
-> with Ext2Fsd, i have accesses to all the partitions, including /system and /data, but unfortunatly, permissions are not correct
-> i trying with other tool (Explore2Fs) not luck
-> ltools seems to provide a lattr util that could do it, but i'm unable to see the files (certainly because of the GPT partition
b) trying to use VirtualBox with raw disk access for handling, with a linux guest, permissions:
-> up to partition 7, this seems correct
-> from partition 8 (/system), i can mount it in RO but it crashes in RW
c) trying to boot to any linux supporting EFI32 and GPT
-> thanks to paperwastage, i could achieve it (thread here: http://forum.xda-developers.com/showthread.php?t=2500078 )
-> i have strange troubles: the system only detect mmcblk0 to mmcblk7, and is throwing an error (error -110 + unknow command)
-> both, in clonezilla and ubuntu
d) tryed to use so android local tricks to force change mode, but once, i'm stuck with no eXecute flag. I dig around the local.prop or any stuff that would help me to achieve this goal. The recovery is not available (nor i found it) and the only thing i can do is factory reset.
It really seems only Windows got the proper drivers for this eMMC. This could explain why i had hard time to dump it (and, actually, i would not try to restore b/c i'm not sure everything is backuped correctly and don't want to brick my tablet), and why i could only write from Windows and why it cuts at partition7 (i have at least 12 partitions. NTFS windows main is the #11 iirc)
What i could try actually:
-> double check with newer ubuntu (when i started "install to disk", it seems it could detect the whole disk, have to look again)
-> double check with local THBK install (copy 3 apks bundled with the tablet, but perhaps a command script is available to be executed ?)
-> double check with virtual box & raw disk acces (i focused on /system, but perhaps /data is ok ?)
-> recompile Ext2Fsd to have different default properties
-> dig the hardware to see if a real recovery boot is not available, or change the recovery to something more usefull than factory reset
Thank you if you have more and more ideas
Quick notes:
- THBK1 does NOT connect to PC/MAC
- THBK1 does NOT have USB Debug activated. The micro-usb is aimed to put a (normal) cable, not an OTG one nor a charging cable. You can reach ADB only over Wireless.
-> Currently trying TowelRoot with different parameters, but for now not successfull. Basically this is a 4.2.2 kernel so i could expect a low resistance at exploits, it worths to be tested
Good news, i was able to boot from an USB stick (with EFI), and while the MMC is not accessible, i found a trick to change permissions.
I have now full R/W support on EXT3 partition.
But sadly SU is not enough to gain root accesses.... damn.
Anyone able to find doc or explain how root access is triggered ?
I found an update, and i'm now able to flash the whole system partition. Sadly, i could not flash another update.zip, so i guess this is signed (and sadly it is).
I have also tryed z4root, towelRoot exploits, not working.
Basically i could somehow bypass the sign system in applying myself the content of the update.zip (as long as it deals with /data and /system files & perms). I'll try that for at least google apps.
edit: ok i have now play store and the whole google suite is working after a big playstore update (talkback, vocal syntgetisis and so on). Only google+ is FCing but it should only be a matter of installation. I should remove it and reinstall it from the market.
Only thing missing is root
Status on Android forum side: http://forum.xda-developers.com/android/help/hacking-thbk1-10-getting-root-t2804631/post53896017
As today, the tablet is now rooted. It works flawlessly.
Next step is the handling of recovery to flash non-signed zip files. It would ease the process of installing GAPPS or rooting the tablet.
But i'll take a break before
TODO list, from top to crazy:
- recovery
- test and deploy various system tweaker sur as Xposed framework
- bugfix vibrator (only working when you hit Windows button, not in apps)
- new rom, new kernel
Here is the actual partition layout:
Code:
Model: MMC BIWIN (sd/mmc)
Disk /dev/mmcblk0: 30.9GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 269MB 268MB fat16 ANDROID!bootloader boot, hidden, legacy_boot
2 269MB 337MB 67.1MB ANDROID!panic
3 337MB 873MB 537MB ext4 ANDROID!factory
4 873MB 2484MB 1611MB ANDROID!fake
5 2484MB 2618MB 134MB ext4 ANDROID!config
6 2618MB 4229MB 1611MB ext4 ANDROID!cache
7 4229MB 5303MB 1074MB ext4 ANDROID!logs
8 5303MB 7450MB 2147MB ext4 ANDROID!system
9 7450MB 11.7GB 4295MB ext4 ANDROID!data
10 11.7GB 11.7GB 1049kB ANDROID!misc
11 11.7GB 11.8GB 33.6MB ANDROID!boot
12 11.8GB 11.9GB 134MB ANDROID!recovery
13 11.9GB 11.9GB 33.6MB ANDROID!droidboot
14 11.9GB 12.3GB 315MB ntfs Basic data partition diag
15 12.3GB 12.5GB 273MB fat32 EFI system partition boot
16 12.5GB 12.7GB 134MB Microsoft reserved partition msftres
17 12.7GB 30.9GB 18.3GB ntfs Basic data partition msftdata
I'm not able to read the partition w/o filesystem (2, 4, 10, 11, 12, 13).
I tryed with yaffs2, but i'm not able to see them (and since it is not MTD...)
I'm working on dd image of the 32Gb MMC.
In example, hexdump of partition 12 shows it is a kernel. Certainly the recovery kernel directly flash, i should dig this.
Guide: installing Google Apps and Rooting the tablet
THIS POST IS DEPRECATED. See http://forum.xda-developers.com/showpost.php?p=55513404&postcount=23
:good: /!\ Please click thanks or offer me a coffee with donate if it was usefull for you /!\ :good:
This is rather technical, but i can help if you are stuck. Thank you for your comments.
Here is how you could install Google App suite to the THBK1-10 and certainly many ones based on Inside H2O bios, board name: CARD_B (see above for detailled specs)
Basically, to install some stuff, the concept is to get rid of all the caveats (special MMC drivers, EFI 32 bits with GPT, etc...) through actual Windows 8.1 installation. Everything takes place through classic Windows desktop. For convenience, personnally worked with TeamViewer, doing this with the dock/touchpad is pain in the ass. You can void your warranty and break the android part of your tablet, so operate carefully, i'm not responsible of what you do !
This leads to 3 phases:
a) accessing EXT4 Android partitions
b) transfer files from Windows to Android
c) change permissions
a) Accessing EXT4. I used coLinux to access and handle Android EXT4 partitions:
- download and install coLinux http://sourceforge.net/projects/colinux/files/latest/download?source=files. At the 'Choose components' screen, uncheck 'Root filesystem image Download', and accept everything (including TAP drivers)
- download and unzip Debian Squeeze image in coLinux folder (c:\program files\colinux). Warning, this leads to a 2Gb file, ensure you have proper space. You could unzip it in your external SDcard, but you would have to change the path to rootfs and swap in above squeeze.conf
http://sourceforge.net/projects/col... 6.0 Squeeze/Debian-6.0.1-squeeze.7z/download
- test it: click on the squeeze.bat file into c:\program files\colinux (if you have an error co-slirp, simply close colinux and restart it). Once you have the 'debian login:' prompt simply type root then enter. You are now under coLinux.
First, install your local keyboard (if needed)
Code:
apt-get update
apt-get install console-setup locales console-data
In case you miss the point for the keyboard:
(choose select keyboard from full list / pc azerty or whatever...)
Code:
dpkg-reconfigure console-data
- you should now update your /etc/apt/sources.list file:
Code:
nano /etc/apt/sources.list
- fill with the following lines (remove all before)
Code:
deb http://ftp.fr.debian.org/debian/ squeeze main contrib non-free
deb http://security.debian.org/ squeeze/updates main contrib non-free
- update your apt repository:
Code:
apt-get update
- you would like to sync the clock from Linux with Windows: edit /etc/default/rcS and change UTC=yes to UTC=no
Code:
nano /etc/default/rcS
You can exit coLinux, we have things to tweak now.You can then download the attached Squeeze.conf, and put it into your colinux folder, replacing the old. Remember, if you have changed the path for rootfs and swap, you must change them to reflect your current installation.
Squeeze.conf:
Code:
kernel=vmlinux
cobd0="c:\program files\coLinux\rootfs_2gb.img"
cobd1="c:\program files\coLinux\\swap_128mb.img"
cofs0="C:\share"
cobd8=\Device\HarddiskVolume8
root=/dev/cobd0 ro
initrd=initrd.gz
mem=256
eth0=slirp
b) transfer files from Windows to coLinux
We would create a share folder at the root of C:\.
You must have C:\share folder.
- Create a directory in /mnt
Code:
mkdir /mnt/win
- then mount the folder into your coLinux
Code:
mount -t cofs cofs0 /mnt/win
FOLLOW THE ABOVE ONLY FOR GAPPS:
- You must now download the google apps files. The operation is done under Windows:
download Android 4.2.2 ones: http://goo.im/gapps/gapps-jb-20130812-signed.zip and extract all the file into C:\share
This folder must contains the whole gapps (you 'll see folders named: system, META-INF, optional...).
You must directly DELETE 3 files and 1 folder:
file system\app\GooglePlus.apk
file system\app\LatinImeDictionary.apk
file system\lib\libjni_latinime.so
fodler system\tts
If everything is ok, browsing /mnt/win/ from coLinux (not windows)
Code:
ls /mnt/win
should show the share directory content (META-INF,system,optional,...).
FOLLOW THIS ONLY IF ROOT:
- You must now copy su binary to your tablet: download attached files, unzip, copy it to your windows desktop shared folder
Nota: this file is extracted from Koush' superuser APK. This is the x86 su binary. Feel free to replace with newest version if available or if you fear something
FOLLOW THIS IF ROOT & GAPPS
c) access to Android partition
- create a system folder in /mnt
Code:
mkdir /mnt/system
- mount android to system
Code:
mount /dev/cobd8 /mnt/system
- check you are ok with
Code:
ls /mnt/system
You must see app, bin, usr, etc .... folders.
*** at this point, /mnt/system contains ALL your android system. NO MISTAKE ! ***
FOLLOW THIS ONLY IF GAPPS
- part 1: removing files. Browse to /mnt/system/app and CAREFULLY delete the 8 files (some could be missing, don't bother):
Code:
cd /mnt/system/app
rm Provider.apk
rm Provider.odex
rm QuickSearchBox.apk
rm QuickSearchBox.odex
rm SetupWizard.apk
rm SetupWizard.odex
- part2: copy. Copy the files from Windows to Android - it could take up to 2 minutes -
Code:
cp -rp /mnt/win/system/* /mnt/system
- then fix the permissions:
Code:
chmod -R 755 /mnt/system/addon.d
chmod 755 /mnt/system/app/*
sync
At this point, this is over. You can exit from colinux, reboot to Android, and come back to windows uninstalling coLinux, if anything is ok
The whole GAPPS are installed. Enjoy !
FOLLOW THIS ONLY IF ROOT
- copy attached x86 su binary to android
Code:
cp -p /mnt/win/su /mnt/system/bin
- then fix the permissions:
Code:
chmod 755 /mnt/system/bin/su
chmod u+s /mnt/system/bin/su
ln -s /mnt/system/bin/su /mnt/system/xbin/su
sync
At this point, this is over. Reboot, you can now download and install superuser https://f-droid.org/repository/browse/?fdfilter=superuser&fdid=com.koushikdutta.superuser
Your tablet is now rooted. Enjoy !
Know clones (feel free to help):
- Danew i1012 dual boot (strictly identical to Thbk1)
- VOYO A1 (Windows 8 only).
- Cube U100GT (Windows 8 only)
Certainly clones:
- Ramos i10 pro (dual boot)
- Pipo W1 / Work W1 (Windows 8 only)
- ColorFly i106 (Windows 8 only)
- Toshiba WT8-AT01G (Windows 8 only)
Graveen said:
Know clones (feel free to help):
- Danew i1012 dual boot (strictly identical to Thbk1)
- VOYO A1 (Windows 8 only).
- Cube U100GT (Windows 8 only)
Certainly clones:
- Ramos i10 pro (dual boot)
- Pipo W1 / Work W1 (Windows 8 only)
- ColorFly i106 (Windows 8 only)
- Toshiba WT8-AT01G (Windows 8 only)
Click to expand...
Click to collapse
Considering getting a voyo a1 or a pipo w2. But 99% of my interest in windows 8 tablets is running old windows games on them. What's your experience with win 8 and older games for windows? Touchscreen make anything unplayable? Thinking old command and conquer or Warcraft 1-3 etc. With some RPG thrown in.
I hate the idea of being limited to just windows, but I'm hesitant to spend too much on what might not work like I hope.
StridAst said:
Considering getting a voyo a1 or a pipo w2. But 99% of my interest in windows 8 tablets is running old windows games on them. What's your experience with win 8 and older games for windows? Touchscreen make anything unplayable? Thinking old command and conquer or Warcraft 1-3 etc. With some RPG thrown in.
I hate the idea of being limited to just windows, but I'm hesitant to spend too much on what might not work like I hope.
Click to expand...
Click to collapse
Honestly,i installed Steam and played some to test. But, alas, it is not successfull. If you can wire a BT pad, let's say it is ok, but else, generally, the touchpad is not suitable, really.
Of course some point'n clic games should work nicely. But except theses, you 'll be forced to add keyboard/mouse. Or, as i mentionned, a bluetooth gamepad, with some keyboard mapping, such as XPadder, could work fine.
Graveen said:
Honestly,i installed Steam and played some to test. But, alas, it is not successfull. If you can wire a BT pad, let's say it is ok, but else, generally, the touchpad is not suitable, really.
Of course some point'n clic games should work nicely. But except theses, you 'll be forced to add keyboard/mouse. Or, as i mentionned, a bluetooth gamepad, with some keyboard mapping, such as XPadder, could work fine.
Click to expand...
Click to collapse
So basicly, the hardware ran things OK, but the interface sucks, oh well. Probably not worth the headaches of dealing with windows again. I'd imagine it's a real PITA to fix things if it gets a virus.
StridAst said:
So basicly, the hardware ran things OK, but the interface sucks, oh well. Probably not worth the headaches of dealing with windows again. I'd imagine it's a real PITA to fix things if it gets a virus.
Click to expand...
Click to collapse
Like a windows. The 'dock' is allowing light computer use, and Office 2013 home is shipped for free with the tablet. But yeah, Windows legacy is the key when dealing with windows
Hey mate,
I have one of these - http://www.ebay.co.uk/itm/390900023783?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649
are you implying that I should be able to get it to dual boot Windows and Android following your guide?
Thanks
Karl
Hello Karl,
Yes it should be possible if strictly identical.
Increase data space with Link2SD
You can dedicate a part of external SD to increase /data size. Link2SD is ok for this, and will, in the free version, allows you to move APK to external partition.
Your tablet MUST be rooted !
1) ensure you have a FAT32 partition (primary, 1st position)
2) ensure you have an EXT2 or EXT4 partition (primary, 2nd position)
3) install Link2SD https://play.google.com/store/apps/details?id=com.buak.Link2SD
You can now use Link2SD which 'll create links and move your APKs to your new EXT partition.
Personnaly, i have a 32Gb SD with 24Gb FAT + 8Gb EXT4 partition.
Increase data space with Link2SD : Good news !!! You are the Boss. THNK1-10 is available at Carrefour (an another good news)
Time is changing between windows and Android
You can simply set timezone to GMT+0 and disable network time.
On Debian, you set UTC to YES, but need to seek where it takes place in Android.
bu3304 said:
Increase data space with Link2SD : Good news !!! You are the Boss. THNK1-10 is available at Carrefour (an another good news)
Click to expand...
Click to collapse
carrefour or conforama.
thomson carrefour and /danew in conforama.
even saw on internet that MSI is also having this tablet and just sticking there logo on it. atleast looked like this tablet.
---------- Post added at 12:05 AM ---------- Previous post was at 12:01 AM ----------
hum. i think i will go for the new asus transformer book t100 with atom z3775 processor.
i like the battery life of the asus.
but prefer the acer switch 10 in terms of look and the magnetic dock
but yeah choice of 11 hours of battery or 8. makes a difference
and the new 3775 or 3745. cpu
Asus T100-TA Magic Stick
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Since development and hacking for the Asus T100 tablet has been rather slow these past few months, due to the many problems that plagued the kernel and missing drivers, I decided to make a simple-to-use toolchain that works well on the device out-of-the-box. Thus, I have bundled a fully working Ubuntu live CD image and an Android-x86 build into a single usb stick format (I call it the "Magic Stick"), to allow easy testing, booting and updating stuff on the tablet. You can also use it to recover your device and perform maintenance activities without the usual hassle. And you can use it for showing off to your friends and co-workers by triple booting your tablet.
T100 Magic Stick Features:
Dual-boot directly from USB stick into Android or Ubuntu!
Test and play with both systems to see if you like them
Ubuntu 15.04 Live:
Updated 4.0 kernel (thanks to Kirill Belyaev for the kernel build)
No more internal HDD errors (no more rpmb issues)
Suspend working!
Installer working with grub installation! Finally!!
microSD Card working correctly
Wi-Fi working stable since boot
Battery reporting
Hardware buttons
Additional tools by default (gparted, mc, uefi, efibootmgr, grub2)
Android CM13.0.2-rc1 Live:
No more internal HDD errors (no more rpmb issues)
Wi-Fi working
Bluetooth working
Battery reporting
Hardware buttons working
Google Services! (Play Store etc.)
Pre-rooted!
Writable system partition
Persistent data saving on stick (1GB internal storage)
Rotation sensor working
Shrink and change partition layouts
Install and repair bootloaders, grub2 and UEFI
Install, repair, debug and update any operating system
Download and Install:
The installation procedure is extremely simple:
Download the Magic Stick zip file from here: T100 Magic Stick download
Extract the ZIP file
Copy the contents of the extracted folder to a USB stick (at least 3GB free space required)
Disable secure boot in the UEFI firmware configuration (tap F2 at startup to enter configuration)
Boot from the USB stick (tap F2 at startup and choose the stick as boot device from the menus)
Thanks and credits:
Kirill Belyaev, Povilas Staniulis, rbg, Chih-Wei Huang, Brain WrecK, pstglia for their work and contribution + their dedication and their builds.
The whole Asus T100 Ubuntu Google+ Community (chck us out!);
The whole Android-x86 Google Group (check us out!);
Everyone else who contributed patches, fixes, ideas and suggestions!
Download:
v2.0-beta1: Download
Cheers,
C.
Changelog:
v1.5: Ubuntu: no changes or improvements, sorry...
v1.5: Android: microSD card support
v1.5: Android: no more FC bugs at boot...
v1.5: Android: display driver improvements (some games and apps which didn't work will start working now)
v1.5: Android: better overall performance (+2500 points in Antutu than previous version)
v1.5: Android: better browser support (chrome, firefox etc.)
v1.5: Android: streaming support less buggy
v1.5: Android: latest 4.4.2-r3 build included (much more stable)
v1.5: Android: improved bluetooth support (some issues still reported, though)
v1.4: Ubuntu: added bluetooth support (seems unreliable)
v1.4: Ubuntu: updated packages to latest versions
v1.4: Ubuntu: fixed Software Center problems
v1.4: Android: data is saved to the stick (1GB internal storage only!)
v1.4: Android: added bluetooth support (tethering not working, yet)
v1.4: Android: added accelerometer sensor support
v1.4: Android: added rotation sensor support
v1.3: Ubuntu installer does not crash anymore!
v1.3: Added suspend support in Ubuntu
v1.3: Updated to Ubuntu 15.04
v1.3: Added sound for Ubuntu
v1.2: Initial release
Known Issues:
Ubuntu: suspend doesn't work as it should, no bluetooth, no rotation, no camera, no microphone;
Android: suspend doesn't work as it should, no bluetooth, no rotation, no microSD, no camera, no microphone;
Android: at boot, Google text-to-speech will FC a couple of times. This is fixed once you log into google play and update the GApps;
[*]Android: sometimes the keyboard dock is not enabled at boot. This is caused by a race condition at boot and I won't fix it. If you run into it, reboot and try again; (didn't encounter it anymore)
You tell me...
Frequent Questions:
Can I remove the stick after boot?
Answer: No. This works like a live CD.
Will my data be saved?
Answer: In Ubuntu no. This works like a live CD. In Android yes, you can store up to 1GB of data (due to popular request).
Can I install Ubuntu?
Answer: Yes. This works like a live CD.
Can I install Android?
Answer: Yes, but not using the built-in installer.
How can I install Android-x86?
Answer: Manually, but it's easy. Maybe I will create a step-by-step guide later...
Will Android work with ART (before or after install)?
Answer: No.
Can I install xposed framework?
Answer: Yes, but not on the live version, you must install Android locally first.
How can I update the Android-x86 version on the stick?
Answer: Replace the files in the "x86" folder on the stick.
How can I update the Ubuntu version on the stick?
Answer: You can't (not easily anyway).
Windows Tools:
I recommend you download these and save them onto the USB stick you create yourself, to always have them on hand. I did not include them on the stick as they are licensed separately (even if "free") and all credits go to their respective authors. I also recommend downloading the Windows 8.1 drivers for the T100 and saving them to the same stick, just in case you have to re-install Windows. Just make a separate folder on the stick and save whatever you want there. It won't break any functionality.
EasyUEFI - Download
A tool which helps you manage UEFI boot entries, paths and configuration for booting with ease
Ext2Fsd - Download
A tool which helps you mount ro/rw the Android/Linux partitions in windows as regular drives
unsqashfs 4.0 - Download
A tool to extract the ".sfs" and ".squashfs" images to regular ".img" files (to make system.img writable, mountable etc.)
Advanced reboot script - Download
A Windows batch file that reboots the system so you can select the boot device using your touchscreen (boot in Android/Ubuntu directly without the dock attached etc.)
Linux how-to resources:
Unsquash FS: http://unix.stackexchange.com/questions/80305/mounting-a-squashfs-filesystem-in-read-write
Update grub: http://askubuntu.com/questions/281119/how-do-you-run-update-grub
Grub install to separate partition: http://askubuntu.com/questions/472669/install-grub-on-a-different-partition-on-triple-boot-system
Make IMG files: http://ubuntuhak.blogspot.ro/2012/10/how-to-create-format-and-mount-img-files.html
More grub: https://docs.oracle.com/cd/E26502_01/html/E28983/gkvif.html
Even more grub: http://superuser.com/questions/376470/how-to-reinstall-grub2-efi
Android How-to / guides section:
This section contains a set of guides to help you with some basic tasks and activities to easily manage your own installation(s) of Android. This is the part where the Magic Stick itself will prove to be useful and how you can use it to customize and repair or update anything. The Ubuntu related stuff is not documented here, as documentation and forums are available on the internet.
WARNING: These guides are not extremely detailed and include only the activities which have to be performed. Each configuration is different and you need to understand what you are doing to make sure you don't break anything. Worst case scenario is that you will lose all your data. However, you will still be able to boot the Magic Stick to repair or re-install everything (thank me later!)
DISCLAIMER: I am not responsible for any loss of data and you are at your own risk while using the tools, guides and information provided here. Back up your data and do not play around with systems that you use on a daily basis. Only follow these guides if you feel comfortable with the instructions and completely understand what you need to do at each step.
Make the Android system partition writable
When you download an Android-x86 release, you will find in the ZIP or ISO a bunch of files, including a file called "system.sfs" or "system.img".
If you have a file called "system.img" you can stop now, your Android system partition is writable and you can skip to the final step.
If you have a file called "system.sfs", then use the unsquashfs command to convert it into a writable format:
If you are using Windows, download the unsqashfs tool above and extract the zip. Drag and drop the "system.sfs" file on top of the unsqashfs executable to extract the system.img (you can find it inside the generated folder)
If you are using Linux, make sure squashfs-tools are installed and run this command from the folder containing the "system.sfs" file:
Code:
unsquashfs ./system.sfs
That's it, now you can mount the system.img file generated under linux using this command:
Code:
mount -o loop ./system.img /path/to/destination/
Resize the system partition
Usually, the system partition of Android-x86 is made as small as possible (you don't want to download "free space", right?) so if you want to add gapps or other packages to the system partition there will be no space left. Here's how to increase the size of the system partition:
Boot the Magic Stick into Ubuntu
Open a console using the Ctrl+Alt+T shortcut
Browse to the folder containing the system.img file (using 'cd' or 'mc')
Extend the system.img file by 200MB. Replace 200 with the amount of MB you want to add:
Code:
dd if=/dev/zero bs=1M count=200 >> ./system.img
Run gparted to also extend the partition inside the file:
Code:
sudo gparted system.img
In gparted, right click on the partition and select the option to shrink it down by only one MB (so it registers a change) and apply the changes
Close gparted. You're done.
Make space to install Android
Creating a new partition onto which to install Android usually requires shrinking an existing partition. If you want to install Android on the tablet (not the dock base) you will have to shrink the Windows system partition. Here's how to do it in a reasonably safe way:
Boot the Magic Stick into Ubuntu
Open a console using the Ctrl+Alt+T shortcut
Run gparted as root:
Code:
sudo gparted
In gparted, right click on the Windows system partition and select the option to shrink it down by at least 2GB. Make sure the partition actually has 2GB of free space, otherwise the process will not work.
Right click the free space and create a new partition and select to format it as ext4. It's important to make it ext4, so keep this in mind. Also give it a name such as "android".
Apply the changes and wait for the partition to be created.
Close gparted. You're done.
To have the partition available in Ubuntu Live, you have to mount it manually or just reboot (to have it mounted at boot automatically)
Install Android locally
Make sure you have the system.img, kernel, ramdisk.img and initrd.img files available. Make sure you have an ext4 partition mounted. The Android-x86 installation is in fact a simple process of copying the ISO/ZIP files onto the destination partition:
Boot the Magic Stick into Ubuntu
Open a console using the Ctrl+Alt+T shortcut
Copy the four relevant files to the ext4 partition using your method of choice
That's it, Android-x86 is installed (but not yet bootable!)
Enable data saving for Android
To enable data saving for Android-x86, you have many choices. However, the simplest one is to use an ext4 partition and create a dedicated "data" folder for android. Make sure Android-x86 is installed onto an ext4 partition:
Boot the Magic Stick into Ubuntu
Open a console using the Ctrl+Alt+T shortcut
Navigate to the root of the partition (the mount point folder)
Create a folder called "data":
Code:
mkdir -p data
You're done, Android will save data persistently across reboots.
Note that this only works for ext4 partitions.
Note that using ext2 or ext3 will output errors for Google Play if you use Lollipop builds.
You have been warned.
Install the grub2 boot loader
Resizing partitions and copying (read installing ) Android is a very simple process. However, the bootloader installation is a much more complicated business (usually!). Here's how to make sure everything is installed correctly:
In progress...
Add the Android menuentry to grub2
Once we have grub2 installed and ready to go, it's time to make Adroid-x86 bootable as easily as possible:
In progress...
Update Android with new releases
Once Android is set up and ready to go, all you need to do to update it properly is to overwrite the existing files and reboot. Make sure you have the updated system.img, kernel, ramdisk.img and initrd.img files available. Make sure you have the Android ext4 partition mounted:
Boot the Magic Stick into Ubuntu
Open a console using the Ctrl+Alt+T shortcut
Copy the four relevant files to the ext4 partition using your method of choice, overwriting the existing ones
That's it, Android-x86 is updated
Cheers,
C.
Reserved....
I am having some problems with this. Granted I am trying to use it for install on the Dell Venue 8 Pro. This tablet is a bay trail base, with most of the same hardware, minus the wireless/bt card. This works fantastic as a live cd, but when I install it I get problems. Is the ubuntu image only i386? When I was trying to change the kernel from the G+ group I kept getting the architecture mismatch (Kernel.deb file is amd64 and system is i386). Also the bootloader is kind of weird. All of the grub settings are correct, but if I want to boot ubuntu from the mmc I have to enter the advanced menu, then boot recovery mode. When recovery mode boots, I hit resume boot and then I am magically loaded into my installed system. Am I doing something wrong here?
The live image is i386 only. For the grub boot loader, try copying the entry contents into the stick boot menu and see if it works as intended. The menuentry file on the stick is in ./boot/grub/grub.conf.
I'll be releasing a new version of the stick with Ubuntu 15.04 (i386) and some additional sound fixes in the next few hours as well.
Cheers,
C.
Ok, v1.3 with new updates and fixes has been posted. Let me know of any improvements and/or problems.
Cheers,
C.
Thank you for great work! One promise: please, fix bug for HP Omni 10. My tablet can't boot in Ubuntu (but works perfectly with Android). Here is a link to the G+ posts with bug disc.
https://plus.google.com/105824122847813147186/posts/4G1BQgD5LNQ
https://plus.google.com/105824122847813147186/posts/gxqsVsNNJoq
The HP omni problem comes from the kernel, which I did not build and I do not maintain. Also, I don't have a HP omni, so I can't test it out.
The bottom line is that I can not promise to make it work, but I will update the kernel when possible. Keep in mind that this is a Asus T100 tool. Follow the thread and when an update for the kernel is posted, try the new version.
Cheers,
C.
Everything runs perfectly. Flawless Android and I'm still testing around Ubuntu. You've helped revitalize my T100! thanks!
Now I just need to figure out how to install the bootloader. Seems simple enough but your instructions say it may be a bit complicated so maybe I'm missing something
For some reason, after Ubuntu installed coulnd open the software manager and didnt have synaptics, also is there a way to turn of the white led,
second do i copy all the android files into the Ubuntu drive or i need to partition the ssd for another partition for android( what are the chances of 5.0/5.1)
thanks for the files and works good, only issue, not home dev but Linux/Ubuntu, that is not finger scroll friendly, and click and hold for right click(context menu) beside chromium that scroll with out having to hold the scroll bar like the rest of the system
It will be great, if you fix it. Thanks for reply!
""Login failed, impossible to establish a reliable connection to the server. This could be a temporary problem or your Android device may not be suitable for data services. If the problem persists, contact customer service. ""
Gives me this error every time I try to log in with my google account. Solutions?
Installation on hdd
I have installed ubuntu on my t100 on the hdd. It works great so manu thanks for that but I have on issue, I need to let the usb stick in on boot in order to make it boot. If I don't grub is in rescue mode saying that : "error : no such device : 25dc1ad7-c268…"
Is there any way to get touch screen working on a Toshiba Encore 2 Write? I know this thread is for the Asus T100, but I tried this flash drive image out on my device and it ran, minus touchscreen. It booted up fine and everything. If anyone is able to help me out, it would be greatly appreciated! I think the issue stems from the device having a Wacom touchscreen, but I can give any information needed!
@feduss: The connection problem did not appear in my tests and I am able to log into Google Services without any problems. Skip the account creation during the initial setup wizard and create it later and see if it works.
@alphaeagle777: try installing plasma-active. You can see it in action here: https://www.youtube.com/watch?v=mOMmp8iEaqY
@Macro le noir: Make sure you select /dev/mmcblk0 as the drive to install the grub2 boot loader during installation. Otherwise, the installer may detect the USB stick grub boot loader and install the OS selection menu for Ubuntu from there.
@FiendFyre: The stick will never have Encore 2 support unless one of the kernel developers include it in the configuration. I am not building the kernels myself, so it is best to ask the Android-x86 group for more info.
Cheers,
C.
I tried already to login later...maybe i'll solve the problem creating a new account
cheatman said:
@Macro le noir: Make sure you select /dev/mmcblk0 as the drive to install the grub2 boot loader during installation. Otherwise, the installer may detect the USB stick grub boot loader and install the OS selection menu for Ubuntu from there.
Cheers,
C.
Click to expand...
Click to collapse
Thanks for the reply. It was the correct issue, I didn't pay attention during installation. To solve the problem I juste reinstall grub at the right place.
edit : I speak to fast. Just reboot work, not after a shut down.
edit2 : after reinstalling ubuntu with grub at the rigth place, it still doesn't work. Can you explaim me how to install grub correctly ?
Grub entry
Hi cheatman, thanks for your great work and nice tutorials. Now I am trying to figured out, how to edit grub to add entry for android. It is situated in /dev/mmcblk0p5 in folder android. I have alrready installed ubuntu on keyboard HDD. Thanks.