ROM Android: Membuat Custom ROM menggunakan Android Kitchen

How to make your own Android ROM

by Darren Yates November 8, 2013

How to make your own Android ROM

APC's custom Galaxy S3 Android ROm

Our special APC magazine Galaxy S3 ROM build.

You’ll need this:

   Android Kitchen – xda-developers.com has all the info you need.
   Vmware Player 5 – grab the latest version from filehippo.com.
   Xubuntu – get the 32-bit 13.04 ISO image

You know you’re a hardcore Android user when you buy a new smartphone and your first thought is to see if there’s a CyanogenMod ROM available for it yet. Custom ROMs have become a bit of an underground industry as users worldwide look to try and ditch the corporate bloatware and create a lean phone experience.

CyanogenMod would easily be the most well-known community ROM maker and it has a brilliant track record of being able to create incredibly lean ROMs at a fraction in size of their stock corporate counterparts. But as good as CyanogenMod is for shrinking ROMs sometimes the cost can be a bit high.

CyanogenMod is based on the Android Open Source Project (AOSP) – if you like a vanilla version of the latest available Android release. However it means the CyanogenMod team has to build a custom version for each phone baking in the device drivers for each phone’s functionality and it doesn’t always include everything. For example a recent CM10.1 ROM I loaded into my Galaxy S III didn’t support MHL (Mobile High-definition Link) so I lost the ability to watch Netflix on my big-screen TV from my phone. As much as I wanted to use CyanogenMod losing my big-screen video streaming was a bit of a deal-breaker.

Generally there are two ways you can create a custom ROM for your phone: you can start from scratch with AOSP or you can build on an official stock ROM and customise it yourself. AOSP is a lot of work so props to CyanogenMod for the work it does but we’re going to look at how to create a custom ROM from a stock release and at the same time introduce you to the Kitchen. Getting into the Kitchen

Customising a ROM is a complicated process on one level but on another it’s like working on a multi-layer ZIP file. In a nutshell you extract a ROM’s contents out of its archive into a working folder remove the ROM parts you don’t want (the bloatware) and make any other changes you want (root access for example) stitch the ROM back up and archive it.

We’re grossly simplifying it but that’s roughly what you do. You can choose to do all of this by hand although in the Aladdin’s cave that is the XDA Developers forum (xda-developers.com) you’ll find a very convenient tool to help simplify the process. It’s called Android Kitchen.

Android Kitchen isn’t going to turn you into a ROM god overnight but even if you never actually flash your phone with your own customised ROM it’ll still open up the world of ROM development and give you a taste of how Android works underneath. That said I’ve now used it to create custom ROMs for a number of devices – my now-deceased HTC Desire (deceased because I dropped it) and my Galaxy S II and S III. So if I can do it how hard can it be? Phone support

There are a few ‘kitchen’ tools available but Android Kitchen is one of the best around and has a surprisingly good list of supported phones including (but not limited to):

   Samsung Galaxy S4 S3 S2
   Samsung Galaxy Note/Note 2
   HTC One/S/X/XL/V

For the full list of supported phones check out the XDA developers Android Kitchen thread and search out the device support in the first post. Android Kitchen is now under part-time development yet it still covers most of the popular phones released over the last couple of years.

There’s a way to add other phones not listed in the compatibility list but that’s beyond the scope of this series for now. Still if you have one of these supported phones you have the potential to create your own custom ROMs with Android Kitchen.

Galaxy S3

Samsung’s Galaxy S III is one of a number of phones supported by Android Kitchen. Building the platform

Before we start the first thing we need is a development platform – Android Kitchen is a Java-based Linux console app that works in Mac OS X Linux or Windows. To use Windows you need to create a Cygwin environment first. Cygwin is a set of tools that creates something of a Linux environment and includes a Linux API (application programming interface) to allow some low-level Linux code to run under Windows. As Cygwin itself is keen to point out it’s not a way to make Windows aware of Linux’s peculiar ways or to run Linux apps natively on Windows.

The problem with Cygwin however is that it can have problems with symbolic file links that often exist within ROMs and can occasionally muck up which is a bit disastrous for you if you’re trying to make a ROM to run your phone. The last thing you want is a flaky ROM. Android Kitchen app developer [dsixda] has done plenty to make the app work as well as it can under Cygwin although we think the safer option and the one we’ll go with is to use a native Linux system. [dsixda] recommends Ubuntu and we’re using Xubuntu which is almost the same thing just a bit smaller and uses the old school Xfce desktop which is a little more Windows-like. Creating a virtual machine

If you already have a Linux computer ready to go that’s great. If not rather than build a separate Linux box we’ll recommend you cheat and go with virtualisation. Using VMware Player 5.0.2 we’ll build an Xubuntu 13.04 virtual machine (VM) that runs as an app on your existing Windows computer. You’ll need your computer running at least Windows XP SP3 or later then grab the latest version of VMware Player 5 from filehippo.com and follow the instructions to install it. Don’t do anything else with it for now.

VMware Player virtual machine

Create a VMware Player virtual machine from an ISO image or Live CD.

Next you need a Linux distro. We’ve had a couple of these over the last year or so on our APC cover discs but really any Ubuntu-based distro will be fine – it doesn’t have to be the latest release. If you don’t have anything grab the 32-bit Xubuntu 13.04 ISO image from tinyurl.com/l4o5ron. It’s 827MB and we’ll use this to build a complete Xubuntu Linux VM that you can use to run almost any Linux software. (You can use the 64-bit version but for our needs the 32-bit option will be simpler and we’ll use this instead.) VM requirements

VMs run in software but they need real hardware to work – you’ll need a PC with at least 3GB of memory (preferably 4GB) and a minimum of 40GB of drive space free. Using VMware Player we’re now ready to build a VM with 1GB of RAM and 20GB of hard drive space. That’s enough room to install Ubuntu Linux the Android Kitchen and make a couple of ROMs. It’s also enough RAM to ensure Ubuntu (known in this virtualisation setup as the guest operating system) runs well enough without compromising Windows (the host). Creating an Xubuntu VM

To begin fire up VMware Player and click on ‘Create a New Virtual Machine’. This will launch the setup wizard that will guide you through the process.

The first step is to point VMware Player to your Linux distro – it can either be an ISO image you’ve downloaded or grabbed from a cover disc or a Live CD/DVD if you’ve already burned it to disc. Choose your option set the location to the distro and click ‘Next’. On the next screen add details to create a local account with a username and password – these will be used automatically during the installation process. Make sure you write down the username and password as you’ll need them later. When you’re done click ‘Next’.

On the ‘Name your Virtual Machine’ screen call it whatever you want but the more important setting to take note of is to decide the folder location you want to store the VM files in. The Ubuntu OS files are installed into what’s best described as a self-expanding ZIP file – it sits on your computer as a single file that expands as required. The important thing is the installation is separate from your Windows install. It obviously loads onto the hard drive but to Windows it just looks like a big compressed archive file. So choose the location you want to use to store the files wisely (it should have about 30GB free) and hit the ‘Next’ button.

Now choose the disk space you want to allocate to the VM – we recommend 20GB. Also set the virtual storage as a single file not split files. When you’re done click ‘Next’ again.

On the final ‘Ready to Create Virtual Machine’ screen you’ll get an overview of the settings to be used. You can even change them if you click the ‘Customise Hardware’ button although there shouldn’t be any need to. When you’re done click’ the ‘Finish’ button. Installing Xubuntu

The VM will then launch and automatically begin installing your chosen Linux distro. The installation will take around 20 minutes depending on your system and how many updates it needs (or you choose) to download. When it’s completed you’ll not only be ready for Android Kitchen you’ll have a Linux computer on your Windows desktop that you can fire up and run both at the same time.

Xubuntu 13.04 installing as an app on a Windows 8 PC.

One tip: make sure you select to download and install the VMware Tools for Linux app when the pop-up box appears. Ubuntu won’t start correctly until it’s installed. Once it’s in restart the VM (in the top menu go to ‘Player > Power > Reset’) and the VMware Tools app should automatically install. Eventually your Ubuntu install should kick up ask for your password and load up the desktop. When you see that your VM is up and running.

Before we go any further if you’ve not used Linux before have a play around and get used to the controls. Launch the web browser (Firefox) and you should be able to head to your favourite web site and browse. Load up Thunar – Xubuntu’s Windows Explorer equivalent – and get used to folder navigating. Take your time here as it’s better to learn how to navigate your way around at leisure than try to find something in a panic later on. Installing Android Kitchen

When you’re ready the next step is to install the Android Kitchen and we’ll be working exclusively within the VM from now on.

The first step is to launch the ‘Ubuntu Software Center’ and in the search box on the top-right type Java . Select the latest ‘OpenJDK Java Runtime’ option and install it. When it’s done launch a Terminal box (‘Menu > Accessories > Terminal Emulator’) and type java –version to ensure it’s installed. Launch your Linux browser and head over to Android Kitchen on GitHub to download the latest version of the ROM Kitchen (at the time of writing this was version 0.224). Click on the zip icon and download it – it’ll be about 27MB and should make its way to your /home/<username>/download/ folder.

install java

Android Kitchen needs Java; you’ll find it in the ‘Ubuntu Software Center’.

Once it’s downloaded extract the files and you should end up with an Android-Kitchen-0.224 folder or similar for your version. Now in your user folder create a new folder called ‘kitchen’ and copy the contents of the ‘Android-Kitchen-0.224′ folder into that new folder. You should end up with a /home/<username>/kitchen folder and inside you should see subfolders ‘original_update’ ‘scripts’ ‘tools’ and a ‘menu’ file.

Another tip: it’s important that the full path of the Kitchen folder has no spaces – ‘darren yates’ is bad; ‘darrenyates’ is good – otherwise the Kitchen won’t work properly. If your username has spaces create the ‘kitchen’ folder in the ‘home’ folder and copy the contents there.

The Android Kitchen menu: everything you need to customise a ROM. Running the kitchen

If you’re using Xubuntu right-click the ‘kitchen’ folder in the Thunar file manager and select ‘Open Terminal Here’. This is a quick way to launch a Terminal screen that automatically opens in the ‘kitchen’ folder. Type ./menu and press Enter. You should then see the Android Kitchen menu appear on the screen. If so congratulations – you’re just about there. Finding ROMs

Before we can start cooking ROMs we need a ROM to start with. Just for this example we’ll use the latest Android Jelly Bean (4.1.2) ROM for the Galaxy S II I9100 smartphone. If you have a Samsung phone Sammobile is about the best place to grab stock ROMs. The sample ROM file we’re using as it was downloaded is ‘i9100xwlsh_i9100opslsb_ops.zip’. Copy that file to your /home/<username>/downloads/ folder.

Now we get to a slight bump in the road. There are a number of ways phone ROM archives can turn up and you have to treat each one differently. Most Samsung ROMs come as ZIP files with a ‘.TAR.MD5′ archive inside. Grab this file and copy it to the Kitchen’s ‘original_update’ subfolder. Use the Thunar file manager to rename the file and drop the ‘.MD5′ extension so it just becomes a TAR file.

Head back to the Terminal with the Kitchen app running and select ‘Option 1′ – we need to create a working folder for our customised ROM. Use the default working folder option provided and press the Enter key to continue. Android Kitchen should then show your ROM file in its list of ‘Available ROMs’. Select the ROM number and press Enter. Android Kitchen will begin expanding the ROM into the working folder ready for us to start customising.

When it’s done you’ll have the option to see an information panel about the ROM including whether it already has root access and other useful extras. Next time

We now have the Android Kitchen up and running and our stock ROM expanded laid out and ready for customising. Next time we’ll start looking at the various options such as how to root the ROM enable installation of apps to the SD card and even add the option of customised boot animation. And not to mention how to ditch some of that pesky bloatware!

In the meantime get familiar with your new Linux VM. With the VMware Tools app installed you should now be able to copy and paste files from Windows to Linux with a simple Ctrl-C/Ctrl-V flick.

WARNING!

Customising your own ROMs can be potentially hazardous to the health of your smartphone. Be warned: an incorrectly built ROM may brick your phone. We present this information having tested it ourselves but offer no warranty on its fitness for use. Use it at your own risk.

How to make your own Android ROM – part 2

by Darren Yates December 23, 2013

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. Running the Kitchen

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. Getting the right ROM file

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. 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

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. 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’.

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.

Choose between Chainfire’s SuperSU or ChainsDD’s Superuser apps. BusyBox

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. Adding & removing apps

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.

Odex or deodex?

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. Zipaligning all apps

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.

Zipaligning your ROM is something you should do to minimise RAM usage. Removing apps

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. Android Kitchen options

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.

This shows the final build message from Android Kitchen when your new ROM is done. Rebuilding the ROM

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.

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.

Referensi

• http://apcmag.com/how-to-make-your-own-android-rom.htm
• http://apcmag.com/how-to-make-your-own-android-rom-part-2.htm
• http://apcmag.com/how-to-make-your-own-android-rom-part-3-boot-animation.htm
• http://apcmag.com/how-to-make-your-own-android-rom-part-4.htm