How to make your own Android ROM – part 2
Android has quickly become the operating system of the ages and is
loaded into everything from cheap $50 tablets to the latest eight-core
smartphones. But with the right tools you can customise official
firmware releases (ROMs) meant for some of the latest phones changing
how the ROM works adding in new apps and removing the unwanted
bloatware.
In the first part of this series we looked at how to set up a virtual machine on Windows using VMware Player 5.0.2 installing Xubuntu 13.04 Linux and the Android Kitchen app. If you’re a late arrival you can grab VMware Player 5.0.2 here the 32-bit release of the Xubuntu 13.04 Linux distro ISO image from xubuntu.org/getxubuntu and Android Kitchen on GitHub. You’ll also need the latest Java runtime engine but you can install that when you have your Linux virtual machine up and running from the ‘Ubuntu Software Center’.
We won’t go over the whole thing again but the idea is that even though the Android Kitchen app we use requires Linux you can do all of this on a Windows computer by creating and working inside a Linux virtual machine.
Finally be aware that Android Kitchen doesn’t support ROMs for every Android device – you can find the compatibility list and the app’s home thread over at XDA Developers Forum.
The very last thing we did in part 1 of this masterclass was look at
how to grab a ROM file for a Galaxy S2 smartphone and how to get the
Android Kitchen to disassemble it into a working folder.
You might remember that Android Kitchen is a Python-language/Java-powered script that allows you to take an existing ROM pull it apart make changes and stitch it back together again so you can load it into your compatible phone or tablet. This time we’re going to switch over to Samsung’s Galaxy S3. Samsung’s ROMs for the Galaxy S3 certainly aren’t small – they measure up at around 1.2GB so it’s no wonder there isn’t quite as much internal storage available as you might have thought.
In some ways the most complicated part of the process of creating a
custom ROM is actually finding the right ROM file – not just the right
ROM for your particular Android device but the right archive file in
that ROM download. For Android Kitchen to work what we need is the basic
ROM TAR file. TAR is roughly the Linux equivalent of an ISO image in
Windows – it’s a single file archive containing lots of files inside it
but it retains the file system of those files. However sometimes you’ll
find ROM TAR files stored as ‘TAR.MD5′ files which Android Kitchen can’t
recognise. The solution is nice and simple – just drop the ‘.MD5′ bit
with a simple rename in the Thunar file explorer so that you end up with
a TAR file again and you should be fine. That file needs to be copied
to your /home/<username>/kitchen/original_update/ subfolder.
Remember that Android Kitchen can’t work if your username has spaces in
it. You must move the kitchen file path to /home/ instead.
With the ROM TAR file in the right location you can launch Android Kitchen (open a Terminal inside the /kitchen folder and run ./menu ) and select option ’1′ to create the working folder from your ROM. Follow the basic prompts (you’ll need your username’s password) and when you’re done you’ll get an info panel on what extra features are inside your ROM.
Now that you’re set up the first thing you’ll want to do if you’re
customising your own ROM is to give it root access. Root access allows
apps to access the root folder of the Android operating system to
perform extra features not normally allowed by Android. For example you
need it if you want to run Samba Filesharing or if you want to connect
your PlayStation 3 DualShock gamepad to your phone via Bluetooth. You
may just want it because you don’t like being locked out of your own
phone.
There is a security downside in that if you can get to the root folder of your phone so can any rogue app that may try to steal credit card details your contact list you name it. Is it a problem? If you know what you’re doing and you’re not in the habit of loading in every app under the sun no it shouldn’t be a problem. However it’s one of the ‘use at your own risk’ features of most custom ROMs like CyanogenMod.
When you’re ready to add root access to your ROM press ’2′ on the main menu. As soon as you do you have to decide which superuser app you want installed. Superuser is essentially an app that allows you to control how other apps interact with your root access. The most common option you see in custom ROMs is the app named Superuser although this free version is fairly limited. The alternative is called SuperSU and is more for Android fanatics with more options and some nice extras including claimed greater notification speed.
If you’re just after the ability to run apps that need root access
Superuser is fine and all you’ll need. If you’re a more serious user
give SuperSU a go. To make your choice in Android Kitchen press C for
SuperSU or D for Superuser.
Another option you can add to your ROM is BusyBox. It’s a tool that
combines hundreds of Linux command line tools into one app such as the
commands mkdir (make directory) mv (move) gzip (file compression) and
loads more. Do you need it? If you’ve never used the command line before
then probably not but it’s as close as you’ll get to turning your
Android ROM into a more Linux-ified operating system. BusyBox doesn’t
turn your Android ROM into a generic Linux distro it just gives you
access to those Linux command line apps.
If you don’t root your ROM there’s little reason to install BusyBox because the program needs root access. However if you do root your ROM installing BusyBox is a good idea as some root access apps need access to BusyBox commands. Also you’ll likely need to install a Terminal emulator to run BusyBox commands. You can grab Android Terminal Emulator from Google Play.
For me the fun bit of making/baking your own ROM is choosing to add –
or remove – apps and truly making it your own. In the case of Samsung’s
most recent Galaxy S3 ROM at the time of writing it could be that you
simply want to reduce its huge 1.2GB size into something a little more
manageable by removing some of the apps you neither want nor need.
When you create an Android app using the Android SDK and the Eclipse IDE you end up with a single APK archive – essentially a ZIP file – which you can then install onto any appropriate Android device. Apps baked into a ROM are just packed in as their original APK files which greatly simplifies both adding and removing apps.
When Android Kitchen pulls apart your initial ROM file it puts everything in a subfolder of the /home/<username>/kitchen/ path called ‘working’ following the date and time; for example /WORKING_061913_181512/. Bundled apps are stored in the /system/app/ subfolder; however inside that folder you’ll probably find not only APK (Android Package) files but also ODEX files too.
Now is a pretty good time to introduce the idea of the ODEX file and
the concept in custom ROMs of odexed and deodexed apps. When you create
an Android app using the standard Android SDK/Eclipse compile method you
end up with a single APK archive file; inside that file is a
‘classes.dex’ (Dalvik Executable) file. It’s essentially the compiled
part of your Android app. We could spend days talking about the heart of
Android – it’s a Dalvik virtual machine – but keeping perspective all
you need to know for now is that the DEX file is run by the Dalvik
virtual machine so it’s a key part of your app.
That all exists inside the APK archive. The ODEX file is an optimised Dalvik executable. It’s compressed and contains parts of the app that Android can load when it boots up so as to speed up app loading times. Remember how it’s often been said you shouldn’t empty Android memory? This is one of the reasons why – the memory is loaded up with these ODEX files. However there are issues with odexed apps. First up your app now exists as two separate parts: the ODEX compressed file and the APK archive. While it’s easy to rip inside an APK archive ODEX files are much harder to get into. Also ODEX files get moved to another location when your ROM is installed so you’ll then have two locations of app files to sort through to fully remove an app if you tried to do it post-ROM install.
A deodexed app is one where the ODEX file has been decompressed and its components put back into the APK file as a standard ‘classes.dex’ file. If you write your own Android apps using the standard Android SDK/Eclipse IDE method no separate ODEX file is created so essentially your apps are already deodexed.
The bottom line is odexed apps supposedly load faster; deodexed apps are easier to manipulate.
There’s one other trick that can make up for that faster loading time
difference between odexed and deodexed apps and that’s called zipalign.
Google recommends that every app developer runs their final key-signed
app through the zipalign command line tool before uploading it to Google
Play. It’s a way of ordering the contents of the APK file so that all
uncompressed raw data (images or whatever) are aligned on four-byte
boundaries. In short it reduces the amount of RAM an app chews up when
it’s running.
So in the end its suggested that deodexed zipaligned apps run just as fast as odexed apps but with lots of advantages: you get an app that’s a single APK file it’s stored in one location it’s easier to manipulate and it uses less RAM. For these reasons you’ll find most custom ROMs are both zipaligned and deodexed for your Android computing pleasure.
If you’re wondering what all that has to do with customising ROMs go
back and re-read it. At the very least in our context it means that to
remove an app if you see an APK file accompanied by an .ODEX file of the
same name in the /system/app/ folder you need to remove both.
The next big question is: which apps do you remove? If the ROM has been built well the apps should still have their clear-language names so you’ll get some idea as to what they do. The best way though is to go through your ROM’s /system/app/ folder look at each app research what it is what it does and where it comes from. Based on that you can decide whether it stays or goes. If that sounds too complicated well with over 800000 different app possibilities you could find in your ROM that’s the only sane way to do it. As it is our test Galaxy S3 has some 355 files and 570MB of apps in that folder to go through.
Here’s a quick tip: set your Thunar view of that folder to show the largest files first. That way you research the largest files first that can gain you maximum space by removing them. Notice we’ve been saying ‘remove’ not ‘delete’ – ideally you should just move these unwanted files to a folder outside of the Kitchen’s working folder for safekeeping. Why? Rather than starting the Android Kitchen process from scratch it’s always easier to just add in any apps you’ve removed.
If you have a Samsung Galaxy device there’s a list over at the xda-developers.com web site that gives you a pretty reasonable starting point for apps you can remove. By the looks of it it’s quite aggressive in its suggestions and we can’t guarantee it won’t stuff up your ROM build but if you need a starting point head to this XDA Developer’s forum thread.
Note that Android Kitchen doesn’t need to know anything about apps
you add or remove – you do all of this in the file manager of your Linux
distro (Thunar if you’re using Xubuntu like me).
When you’re done with that and go back to the Android Kitchen menu you’ll see option ’5′ which is to zipalign all APK files to optimise RAM usage. Hopefully after our discussion it now makes sense what this does and why you’d want to do it. The following option (‘change wipe status of ROM’) determines what the ROM will do to your onboard data when it’s flashed onto your phone. The default option is ‘do nothing’ meaning it won’t touch your existing data and will be like doing a Windows upgrade rather than a fresh install. The alternative is that installing the ROM also wipes your data from the phone.
As we said the default is to do nothing but if you decide you want data removed as well you need to tell users that’s what your ROM does if you decide to distribute it. In reality we don’t think there’s a need to wipe data upon ROM installation as it’s easy enough to reset a phone within the Android OS itself if it’s later required.
Finally the last step we’ll look at is simply rebuilding your ROM. To
do that you just select option ’99′ from the Android Kitchen menu. The
great thing is that the Kitchen maintains your working folder even after
the ROM build is complete so you don’t have to disassemble the ROM
every time you want to come back to it to modify it.
Building your ROM will take some time of course but it’ll appear in the ‘OUTPUT_ZIP’ subfolder as a ZIP file ready to install onto your phone using your phone’s ‘Recovery’ menu (and ideal option is something like ‘ClockworkMod Recovery’). We’ll look at this and other ROM customisation options next time.
Just remember that flashing your Android device with a customised ROM will void its warranty. We won’t be answering emails or requests for help so if you do make and flash your own ROM you do so at your own risk.
Creating your own customised ROM isn’t difficult to do with Android Kitchen but if you muck it up it can brick your phone in extreme cases. We have tried this method with no problem on our Galaxy S3 smartphone; however we’re providing this information for educational purposes only. It comes with no warranty or support if you try this and brick your phone. Note too that flashing your phone with a custom ROM will certainly void your phone’s warranty so do this at your own risk.
How to make your own Android ROM – Part 4 : Adding custom scripts
How to make your own Android ROM – Part 1
In the first part of this series we looked at how to set up a virtual machine on Windows using VMware Player 5.0.2 installing Xubuntu 13.04 Linux and the Android Kitchen app. If you’re a late arrival you can grab VMware Player 5.0.2 here the 32-bit release of the Xubuntu 13.04 Linux distro ISO image from xubuntu.org/getxubuntu and Android Kitchen on GitHub. You’ll also need the latest Java runtime engine but you can install that when you have your Linux virtual machine up and running from the ‘Ubuntu Software Center’.
We won’t go over the whole thing again but the idea is that even though the Android Kitchen app we use requires Linux you can do all of this on a Windows computer by creating and working inside a Linux virtual machine.
Finally be aware that Android Kitchen doesn’t support ROMs for every Android device – you can find the compatibility list and the app’s home thread over at XDA Developers Forum.
Running the Kitchen
You might remember that Android Kitchen is a Python-language/Java-powered script that allows you to take an existing ROM pull it apart make changes and stitch it back together again so you can load it into your compatible phone or tablet. This time we’re going to switch over to Samsung’s Galaxy S3. Samsung’s ROMs for the Galaxy S3 certainly aren’t small – they measure up at around 1.2GB so it’s no wonder there isn’t quite as much internal storage available as you might have thought.
Getting the right ROM file
Setting up the working folder
With the ROM TAR file in the right location you can launch Android Kitchen (open a Terminal inside the /kitchen folder and run ./menu ) and select option ’1′ to create the working folder from your ROM. Follow the basic prompts (you’ll need your username’s password) and when you’re done you’ll get an info panel on what extra features are inside your ROM.
Set your file manager to show the largest files first and select from these to maximise space.
Adding root access
There is a security downside in that if you can get to the root folder of your phone so can any rogue app that may try to steal credit card details your contact list you name it. Is it a problem? If you know what you’re doing and you’re not in the habit of loading in every app under the sun no it shouldn’t be a problem. However it’s one of the ‘use at your own risk’ features of most custom ROMs like CyanogenMod.
SuperSU or Superuser?
When you’re ready to add root access to your ROM press ’2′ on the main menu. As soon as you do you have to decide which superuser app you want installed. Superuser is essentially an app that allows you to control how other apps interact with your root access. The most common option you see in custom ROMs is the app named Superuser although this free version is fairly limited. The alternative is called SuperSU and is more for Android fanatics with more options and some nice extras including claimed greater notification speed.
You start the rooting process by selecting option ’2′.
BusyBox
If you don’t root your ROM there’s little reason to install BusyBox because the program needs root access. However if you do root your ROM installing BusyBox is a good idea as some root access apps need access to BusyBox commands. Also you’ll likely need to install a Terminal emulator to run BusyBox commands. You can grab Android Terminal Emulator from Google Play.
Adding & removing apps
When you create an Android app using the Android SDK and the Eclipse IDE you end up with a single APK archive – essentially a ZIP file – which you can then install onto any appropriate Android device. Apps baked into a ROM are just packed in as their original APK files which greatly simplifies both adding and removing apps.
When Android Kitchen pulls apart your initial ROM file it puts everything in a subfolder of the /home/<username>/kitchen/ path called ‘working’ following the date and time; for example /WORKING_061913_181512/. Bundled apps are stored in the /system/app/ subfolder; however inside that folder you’ll probably find not only APK (Android Package) files but also ODEX files too.
Odex or deodex?
That all exists inside the APK archive. The ODEX file is an optimised Dalvik executable. It’s compressed and contains parts of the app that Android can load when it boots up so as to speed up app loading times. Remember how it’s often been said you shouldn’t empty Android memory? This is one of the reasons why – the memory is loaded up with these ODEX files. However there are issues with odexed apps. First up your app now exists as two separate parts: the ODEX compressed file and the APK archive. While it’s easy to rip inside an APK archive ODEX files are much harder to get into. Also ODEX files get moved to another location when your ROM is installed so you’ll then have two locations of app files to sort through to fully remove an app if you tried to do it post-ROM install.
A deodexed app is one where the ODEX file has been decompressed and its components put back into the APK file as a standard ‘classes.dex’ file. If you write your own Android apps using the standard Android SDK/Eclipse IDE method no separate ODEX file is created so essentially your apps are already deodexed.
The bottom line is odexed apps supposedly load faster; deodexed apps are easier to manipulate.
Zipaligning all apps
So in the end its suggested that deodexed zipaligned apps run just as fast as odexed apps but with lots of advantages: you get an app that’s a single APK file it’s stored in one location it’s easier to manipulate and it uses less RAM. For these reasons you’ll find most custom ROMs are both zipaligned and deodexed for your Android computing pleasure.
Zipaligning your ROM is something you should do to minimise RAM usage.
Removing apps
The next big question is: which apps do you remove? If the ROM has been built well the apps should still have their clear-language names so you’ll get some idea as to what they do. The best way though is to go through your ROM’s /system/app/ folder look at each app research what it is what it does and where it comes from. Based on that you can decide whether it stays or goes. If that sounds too complicated well with over 800000 different app possibilities you could find in your ROM that’s the only sane way to do it. As it is our test Galaxy S3 has some 355 files and 570MB of apps in that folder to go through.
Here’s a quick tip: set your Thunar view of that folder to show the largest files first. That way you research the largest files first that can gain you maximum space by removing them. Notice we’ve been saying ‘remove’ not ‘delete’ – ideally you should just move these unwanted files to a folder outside of the Kitchen’s working folder for safekeeping. Why? Rather than starting the Android Kitchen process from scratch it’s always easier to just add in any apps you’ve removed.
If you have a Samsung Galaxy device there’s a list over at the xda-developers.com web site that gives you a pretty reasonable starting point for apps you can remove. By the looks of it it’s quite aggressive in its suggestions and we can’t guarantee it won’t stuff up your ROM build but if you need a starting point head to this XDA Developer’s forum thread.
Android Kitchen options
When you’re done with that and go back to the Android Kitchen menu you’ll see option ’5′ which is to zipalign all APK files to optimise RAM usage. Hopefully after our discussion it now makes sense what this does and why you’d want to do it. The following option (‘change wipe status of ROM’) determines what the ROM will do to your onboard data when it’s flashed onto your phone. The default option is ‘do nothing’ meaning it won’t touch your existing data and will be like doing a Windows upgrade rather than a fresh install. The alternative is that installing the ROM also wipes your data from the phone.
As we said the default is to do nothing but if you decide you want data removed as well you need to tell users that’s what your ROM does if you decide to distribute it. In reality we don’t think there’s a need to wipe data upon ROM installation as it’s easy enough to reset a phone within the Android OS itself if it’s later required.
This shows the final build message from Android Kitchen when your new ROM is done.
Rebuilding the ROM
Building your ROM will take some time of course but it’ll appear in the ‘OUTPUT_ZIP’ subfolder as a ZIP file ready to install onto your phone using your phone’s ‘Recovery’ menu (and ideal option is something like ‘ClockworkMod Recovery’). We’ll look at this and other ROM customisation options next time.
Just remember that flashing your Android device with a customised ROM will void its warranty. We won’t be answering emails or requests for help so if you do make and flash your own ROM you do so at your own risk.
And finally check the info panel to ensure the ROM is now rooted.
WARNING!
Creating your own customised ROM isn’t difficult to do with Android Kitchen but if you muck it up it can brick your phone in extreme cases. We have tried this method with no problem on our Galaxy S3 smartphone; however we’re providing this information for educational purposes only. It comes with no warranty or support if you try this and brick your phone. Note too that flashing your phone with a custom ROM will certainly void your phone’s warranty so do this at your own risk.
See Also:
How to make your own Android ROM – Part 3How to make your own Android ROM – Part 4 : Adding custom scripts
How to make your own Android ROM – Part 1
No comments:
Post a Comment