ROM Android: Membuat Custom ROM menggunakan Android Kitchen

From OnnoWiki
Jump to navigation Jump to search

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.







How to make your own Android ROM – Part 3: Boot Animation

by Darren Yates January 7, 2014

How to make your own Android ROM - Part 3: Boot Animation


Look at any of the Android forums whether it’s Xda Developers (www.xda-developers.com) or the equally fanatical FreakTab.com aimed at mini PCs and you’ll find a kind of reverence is reserved for those who can develop a custom ROM. Flashing your Android device with CyanogenMod will get you geek status among your non-technical mates but even those who know what an SDK is will be impressed if you can bake your own ROMs.

So far in this masterclass series we’ve looked at how to create a working Linux environment within a Windows computer system through a virtual machine using the free VMware Player 5.0.2 software. We’ve also shown you how to take a compatible ROM and pull it apart using the free Java/Python app Android Kitchen. In part 2 of this masterclass we looked at the concept of odex and deodexed apps and ROMs and finally at how to give the ROM root access and install a Superuser-style root access manager.

In this class we’re taking a slight detour to look at one of the more glamorous parts of creating your own ROM and that’s adding your own custom bootup screen animation. While there are plenty of boot animations on the web you can mod yourself nothing says master geek more than creating your own boot animation from scratch. Make a splash

The boot animation is the video-like display you see when you first turn on your smartphone or tablet. They can be made as simple or as complicated as you like but whether you make yours a single image or a video-quality animation like CyanogenMod the process is still the same. And it’s reasonably simple to do. At the most basic level all you need is an image editor (anything from Windows Paint to Photoshop will work) a text editor and some creativity. How it works

An Android boot animation is a pretty simple affair: all it is is a ZIP file that contains a series of JPEG images in specific subfolders which the device ROM loads and displays as described by the text-based descriptor file.

While clever animations like the CyanogenMod splash may look like a video playing they’re just a series of discrete images being played at a set resolution and frame rate. All of this information comes from the descriptor file. Build a descriptor file

The descriptor file is the ‘desc.txt’ file in the root of the ‘bootanimation.zip’ file and its structure is fairly basic. The first line contains three numbers: the horizontal resolution in pixels the vertical resolution in pixels and the image display frame rate in frames per second (fps). Let’s say you’re creating a boot animation for a smartphone. In that case you’d set it up to display in portrait mode in which case your first line would be something like this:

480 800 10

This means a 480 x 800-pixel frame size displayed at 10fps.

After that the following lines describe the various animation sections and how they’re displayed in sequence. While the frame rate is fixed by this first line you can split your animation into sections and display each one differently – you can choose the number of times each section is played or repeated before the next section begins you can set the delay in seconds before repeating or moving onto a new section and you can set the subfolder location for the pics of that section.

There doesn’t appear to be a limit on the number of animation sections you can have although you don’t want it to go on for two hours either. For example the code to display three sections of animation could look like this:

p 1 0 part0

p 2 3 part1

p 0 0 part2

Decoding those lines the first says play (p) once (1) with zero delay afterwards (0) the images in subfolder (part0). The second line says play (p) twice (2) with a three-second (3) delay after the images in subfolder (part1). And finally the third line says play (p) repeat infinitely (0) with zero delay afterwards (0) the images in subfolder (part2).

The images in those subfolders need to be numerically sequenced; for example ‘image001.jpg’ ‘image002.jpg’ ‘image003.jpg’ and so on. Make sure you include those leading zeros otherwise you’ll get strange things like ‘image10.png’ being played before ‘image2.png’. That’s because the system is designed to logically think ‘1’ comes before ‘2’ even if it’s meant to be ’10’. The last thing is to make sure you leave an empty line at the end of the file.

How you create those images is entirely up to you. The simple slow way is to create and save the images one by one. The alternative is to extract them from a video using a video-to-image extraction app. The command line audio/video transcoding app FFmpeg can do this (check out the ‘Convert videos to images’ section at the bottom of this page for details).

While it won’t necessarily work for capturing frames from videos one tip we do recommend if you’re creating animations from scratch is to follow the square frame size used by CyanogenMod. We like this option because you don’t need full-screen resolution for an animation to look good and using a square frame will allow you to still achieve a high-resolution look without needing to update more screen pixels than necessary. That cuts down on the CPU time required ensuring your device spends most of its time loading the ROM which is really what you want anyway. The only other thing that we think helps is if you’re making an animation from scratch start with a black background – it just looks better. Why multiple sections?

If you’ve never seen the CyanogenMod 10 splash animation take a look at it over at tinyurl.com/cdmlnnn. It’s a really clever simple design but how does it work? You can actually download this one from tinyurl.com/ma996tj and using 7-Zip (7-zip.org) decompress it and take a look. The CyanogenMod team has created numerous animation versions in that one file ranging in frame size from 240 x 240 up to 720 x 720 pixels in both vertical and horizontal aspect. Look in one of the folders grab the specific ‘bootanimation.zip’ file and expand it. We grabbed the ‘vertical720bootanimation.zip’ file and inside you’ll find the ‘desc.txt’ descriptor file and two folders: ‘part0′ and ‘part1′. The ‘desc.txt’ file looks like this:

720 720 24

p 1 0 part0

p 0 0 part1

In this case it’s a 720 x 720-pixel image set played at 24fps. The first part0 plays once and immediately launches into the second part1 which it plays indefinitely until the device desktop appears. Why multiple sections? Look at the YouTube clip of the boot animation and you can see there are two distinct parts: the fade-in at the beginning and the repeated spinning loop.

All of these images are in those folders but rather than just looking at them individually you can preview the whole ‘bootanimation.zip’ file with a specially developed app called Boot Animation Factory (see ‘Using Boot Animation Factory’ section towards the bottom of this article). This Windows app will preview the ZIP file showing the frames and the actual image numbers and locations. You can also adjust the frame rate and watch the whole thing in slow-motion to see how it’s created. It’ll also build a finished ZIP file from your completed animation folders and ‘desc.txt’ file. Boot Animation Factory can be downloaded for free over at db.tt/cYSGtjn1.

The trick with any good animation loop is that the last frame in the sequence has to meet up with first. That way it looks like a never-ending video loop despite being made from a finite number of frames. For example look at the three frames we’ve taken from the CyanogenMod boot animation below – we’ve included the first (048) and the last two (070 071) from the part1 section folder. ‘CM10_071′ steps nicely back into ‘CM10_048′ so that as the animation loops you can’t tell where it begins or ends. Playback speed

When creating your own boot animation one of the first things to think about is how many images you’ll need. Remember it’s just a splash display to give you something to look at while your phone is booting up so you don’t really want 1080p images displaying at 30fps otherwise the phone is spending more CPU time playing an HD-grade animation slowing down the bootup process. Also older phones have less reserves of CPU power available to play animation so you need to consider these things when working out how complex to make your animation.

Since the frame rate in the first line sets the playback speed it’s also the number of images you’ll need for each second of play. So clearly creating a 10fps animation takes a lot less work than a 20fps one.

But how high a frame rate for a boot animation is too high? In the end it’s not necessarily how high the frame rate is but how many pixels your phone has to display each second since that’s what the CPU is effectively doing; for example a 1080 x 1920-pixel animation at 5fps equals the same number of pixels as a 480 x 800-pixel animation at 27fps. Obviously your device has to have a screen size that can display the whole animation frame but overall you want to err on the side of simplicity. This is one case where it’s good to think less is more. Compress the file

The last step to making a functioning animation file is to compress the ‘desc.txt’ file and image subfolders into a ZIP folder. You can use 7-Zip for this but most importantly remember to use the ‘store’ option only. You don’t actually want to compress anything otherwise the ROM won’t be able to open and retrieve the files. When you’re done load it into Boot Animation Factory to test that it works as you expect. Add your animation to the ROM

Depending on your device this can be complicated. Android Kitchen has an option for adding custom boot animations into your ROM. Go to the ‘Main Menu’ in the Kitchen select ’00’ for legacy options and then ’27’ (add custom boot animation functionality). This will enable the ROM to look at the ‘datalocal’ subfolder. Next copy the ‘bootanimation.zip’ file into that subfolder which should be located in ‘WORKING_<date>_<day>’ folder and that’s it. The rest will be done when you build the ROM.

However Samsung uses a proprietary animation system that works differently. If you’re working from a stock Samsung ROM (we’re using a Galaxy S3 ROM in this masterclass) here’s what you do. 

   Check the ‘systembin’ subfolder in your ‘WORKING’ ROM folder and look for the files ‘samsungani’ and ‘bootanimation’.
   Download ‘bootanimation4u.zip’ from the bottom of the first post at tinyurl.com/ncjhcwl. Unzip it and inside the ‘systembin’ subfolder of that ZIP file you’ll find replacement ‘samsungani’ and ‘bootanimation’ files. Back up the originals of these files from the ‘WORKING’ folder and copy these replacements over the top.
   Grab your newly minted ‘bootanimation.zip’ and copy it into the ‘systemmedia’ subfolder.
   Build your ROM.

If you look in the ‘systemmedia’ subfolder in your ‘WORKING’ folder Samsung stock ROMs use a proprietary boot animation format for most things. The fix we’re using here allows Android-standard ‘bootanimation.zip’ files to also be used again.

We tested this technique with our Samsung Galaxy S3 phone flashing a custom ROM built from a Samsung stock release with modded ‘bootanimation.zip’ support and it worked the first time. If you want to go back to the genuine boot animation just replace the ‘samsungani’ and ‘bootanimation’ files you added with the originals you backed up in step 2 above.

The first and last two images in CM10’s boot animation – the last frame loops back to the first for seamless playback. 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’ve 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 the warranty so do this at your own risk.


Using Boot Animation Factory Step 1:

Grab the app from db.tt/cYSGtjn1 install it and run it. On the main window click the ‘Preview a boot animation’ button.


Step 2:

Click the ‘Choose boot animation’ button and load in the ‘bootanimation.zip’ file you want to check. The ‘Preview boot animation’ button at the bottom of the window will go live once a compatible animation ZIP is loaded.


Step 3:

Click that button and the animation should appear in its own control window where you can set the frame speed and note the image locations.

Convert videos to images with FFmpeg

FFmpeg is a wonderful do-all audio/video transcoding tool and it can also be used to extract images from video. Grab the latest Win32/static version from tinyurl.com/lrcvz7k and in the bin folder you’ll find the ‘ffmpeg.exe’ command line executable. Start by opening up Windows Explorer and launching a Command Prompt within that ‘bin’ subfolder (hold down the Shift key right-click in the ‘bin’ subfolder area and select ‘Open command window here’ from the context menu.) Next use the following command line:

Ffmpeg -i "c:pathtofilevideo.file" -r 1 -s 480x480 -f image2 "c:pathtoimage-=.jpg"

Here’s what that does:

-r 1 tells FFmpeg to capture one frame per second of video.

-s 480x480 tells it to create 480 x 480-pixel images from each of the captured frames.

-f image2 tells FFmpeg to create images from each captured frame.

image-=.jpg tells it we want images stored numerically with three-digit numbers created in JPEG format.

Replace pathtofile paths with the appropriate paths for your files.

It’s important that you include the full path to your video input file and the location where you want the images stored. If the file path includes any spaces you must surround the whole path with double quote marks; for example: ffmpeg -i "c:new pathvideonext.avi" . If you don’t it won’t work. Also the save location folder path must exist already – FFmpeg won’t create the folder for you and will simply fail.

The other important thing is that the frame size you select will also set the aspect ratio. For example 480 x 480 pixels will produce square frames that will probably look a bit ‘tall’. In this case 480 x 270 or 720 x 406 would be a better option if you’re using a 16:9 aspect ratio video. For 4:3 aspect video you’d use something like 480 x 360 or 720 x 540. Just divide the horizontal resolution you want by 1.7778 to get the correct vertical resolution for 16:9 video and by 1.333 for a 4:3 video.


FFmpeg can extract frames from your videos and save them as numbered images.



The results from the FFmpeg command run on a video clip.










How to make your own Android ROM – Part 4: Custom Scripts

by Darren Yates January 21, 2014

How to make your own Android ROM - Part 4: Custom Scripts

Android Kitchen Advanced Options

Android Kitchen helps you implement scripts ­- but you must write them yourself!

Over the course of this make your own Android ROM masterclass we’ve looked at how you can take an existing smartphone ROM and modify it to create your own custom ROM showing you how to add in root-access deodexing files and even removing corporate bloatware. So far we’ve used a free Linux-based app called Android Kitchen to perform most of the dirty work for us. But the app also has an extra feature that enables you to take ROM customisation to a new level by adding in your own DOS-like scripts.

If you hark back to the age of Windows 98 one of its most useful features was the ability to run your own custom scripts on boot through the old config.sys and autoexec.bat files. You could run anything from CD-ROM drivers to your own DOS batch files as Windows booted up.

Running custom scripts might seem old-fashioned but it’s still huge today. Moreover it’s one of the most powerful tools in an Android ROM developer’s arsenal. Through scripting you can achieve all sorts of tweaks to improve everything from performance to memory management to battery life. In terms of ROM customisation scripting is close to the ultimate option. Using /etc/init.d

Scripting is nothing new to Android because it’s been in Linux since the year dot – and it essentially works the same way too. Rather than having your basic script execution files in the system drive root folder like you did with Windows Android can be made to look for script files in a particular folder the most common being the /etc/init.d folder. Scripts use the Linux Shell script language (sh or bash) in a similar way to DOS and its batch programming language. They launch after the kernel has finished initialising.

There are new apps appearing on Google Play and xda-developers.com that are starting to achieve some of the functionality of scripting – Universal Init.d Init.d Installer and Init.d Toggler are just a few. But the great thing about scripting is that it allows you to bake your custom modifications straight into the ROM so that they run automatically.

Choose ‘yes’ to enable scripts to run from the /system/etc/init.d folder. Setting it up

In order to run scripts in your Android ROM you’ll need to initialise the /etc/init.d folder – it doesn’t exist normally. You’ll also need to install the Busybox collection of Linux command-line apps if you’ve not done so already.

Assuming you’ve been following this series and you have your Linux PC or virtual machine set up with the Android Kitchen app installed and a working ROM folder you can use Android Kitchen to set this up automatically. From the main menu select ‘0 – ADVANCED OPTIONS’ and choose ’14 – Add /etc/init.d scripts support (busybox run-parts)’.

Back in Part 2 of this series we briefly looked at Busybox as an option to build into your ROM and how it provides access to a multitude of those handy little Linux applets. Run-parts is one of those applets that can launch executable files and Android Kitchen uses it here to launch your custom boot scripts. How Android boots

While Android Kitchen makes setting this up relatively straightforward you don’t want to end up as just another ‘ROM jockey’ so it’s worth your while understanding what’s happening in the background. In practice Android Kitchen performs a number of steps to enable scripting and it’s all based on how Android loads up in your device.

Turn on any Android device and you’ll be greeted by its splash screen animation (we showed you how to make your own animation in Part 3 of this series) but while that splash screen whirrs around Android is loading itself into your device’s memory. Very briefly here’s what it’s doing.

The first thing that happens is that the main bootloader fires up and starts sorting out the basics of the device’s hardware typically RAM wireless and other features. From there it looks for the Android kernel which it finds in ROM’s BOOT.IMG image file. Once the kernel is loaded the bootloader switches control to the kernel it takes over and begins loading the RAMdisk and the root file system that also live in the BOOT.IMG file. With that done the kernel begins to load the OS through the main initialisation script called init.rc found in the RAMdisk. After that the Dalvik virtual machine is setup and finally the system server which launches all of the top-level phone features such as Wi-Fi telephony and so on kicks in and takes over.

The kitchen has to pull apart the BOOT.IMG file to insert our script redirection.


Once inserted the BOOT.IMG file has to be stitched together again. Modifying init.rc

If we rewind the process the point at which scripts are launched is when the init.rc file is called by the kernel from the BOOT.IMG boot image. In a normal Android ROM init.rc is locked down tight and only the processes listed in the file are loaded. But what Android Kitchen does is modify the init.rc file and create a service within it called sysinit (system initialisation) which launches Busybox and uses run-parts to launch whatever scripts are found in the /system/etc/init.d folder using the following script command:

service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d

In plain-english? It’s telling Android that while running the main init.rc launch script we also want it to launch whatever scripts it finds in the /system/etc/init.d folder. The good thing is that once you’ve added this to the init.rc file you don’t need to go near it again to get any script you want to run. But what about handling multiple scripts?

The initial init.rc boot script with its new redirection to our folder location. Script execution order

Android’s scripting system is a somewhat simplified version of that found in Linux but just as in Linux you can also set here what’s called the script execution order. There may well be times when you want one script to run before another and you can set the order simply by how you name the script file. Android looks at the first two characters of the filename – the smaller the number the earlier it executes.

However this is where we get to the limit of Android Kitchen’s capabilities – it doesn’t write scripts nor does it move them to the /system/etc/init.d folder for you. These are things you’ll have to learn how to do yourself. Writing your own custom scripts

Now that we’ve set up scripting functionality what can you do with it? There are all manner of ready-made scripts you can use – in this series we’ve been using the Samsung Galaxy S3 and there’s a huge list of scripts over here at this XDA Developers forum thread. Some of them will work with any Android OS; others will require specific modified kernels.

You can also write your own if you know how – just make sure to use a standard Linux text editor to write scripts and not a Windows-based editor. The problem with Windows text editors is they add in extra spaces and characters that can break the script. If you’re using Xubuntu as your Linux distro just use Mousepad.

With scripting you can do anything from changing CPU performance to changing how memory works and more. Boost Android SD card speed

One very common script is used to improve SD card performance by changing what’s known as the ‘read ahead’ block size. You’ll find this parameter is set in many Android devices to 128KB or less. However you can achieve higher read speeds by setting it to a higher level such as 1024KB or 2048KB. Like most things it’s a compromise because you are now forcing Android to load up more data to fill the new ‘read ahead’ size which may be wasteful if you’re dealing with mainly smaller files. Whatever the case write this change into your ROM by writing it into a script.

If you’re making a ROM for the Galaxy S3 smartphone you can open up a Linux text editor and type in the following:

  1. !/system/bin/sh

echo "2048" > /sys/devices/virtual/bdi/179:0/read_ahead_kb

What that tells Android to do is to reset the read_ahead_kb parameter to 2048KB. Save the file as 99sdcardfix and copy it to the ROM working folder’s /system/etc/init.d directory.

If you install Terminal Emulator from Google Play on your stock Samsung Galaxy S2 or S3 smartphone for example and then type:

cat /sys/devices/virtual/bdi/179:0/read_ahead_kb

You’ll likely get a result of ‘128’. After you install and run the script it should become ‘2048’. You can use an app like SD Card Tester from Google Play to do before/after performance tests to see the difference – just remember that while speed tests can be intoxicating real world performance mightn’t be as dramatic. While you probably won’t see any write speed differences you should see a decent improvement in read speeds provided you’re using a Class-6 or Class-10 card. In any event this will give you a pretty decent idea of how scripts work how to install them and get them to run automatically on boot.

If you want more than just the basics the best way to learn is to follow in the footsteps of others. One of the best universal scripts going around at the moment is V6 Supercharger which is a memory management script that improves the way Android handles memory. Thousands swear by its effectiveness and one of its tricks is the same that we’ve just performed here. SD card speed tests BEFORE (128KB setting) A1 SD Bench (MB/sec) SD Card Tester (MB/sec) Write speed 13.77 14.03 Read speed 13.25 12.12 AFTER (2048KB setting) Write speed 13.23 14.48 Read speed 25.81 21.67 Before and after tests

Just to see what difference the script actually made we tested it with before and after tests using two benchmarks A1 SD Bench and SD Card Tester. In both cases increasing the read-ahead setting from 128KB to 2048KB gave well on the way to double the read speed from our test 16GB Kingston Class-10 MicroSD card. Chances are you won’t see the same gains with slower cards. Changing CPU speed

Another script you can run is to lock down the clock speed range. Android uses what’s called a ‘speed governor’ that automatically sets the clock speed between the CPU’s maximum and minimum levels based on the software load. Our test Galaxy S3 phone’s Exynos 4412 CPU has a clock speed min/max set of 200MHz/1400MHz. But you can change those levels by creating another script.

In the same Linux text editor create the file 98cpufreq and type the following :

  1. !/system/bin/sh

Echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq;

Echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq;

This will adjust the min/max set to 250MHz/800MHz. Copy the script to the /etc/init.d folder as before. When your new ROM is eventually installed you can monitor the CPU frequency range in real time using CPU-Z from Google Play. It’ll show you the clock speed of each core in the CPU. To revert to the Galaxy S3’s original settings change the numbers above to ‘200000’ and ‘1400000’.

The jury is still out on whether underclocking a CPU makes a real difference to battery life but it does make a difference to heat production. Whichever side of the fence you sit on we’ve seen that the script does work and limits the CPU speed to between these min/max settings.

Writing your own scripts can be simple – this one speeds up SD cards.


The 98CPUfreq script lets you set minimum and maximum CPU core speeds. Do away with apps!

If you head over to Google Play and look up the app SD Card Increase you’ll see that it does the same thing we did here in our first script ­- changing ‘a parameter in the operating system’ according to the notes to let you change the look-ahead size by moving a slider. Now sure you can bypass this whole ‘customise your own ROM’ idea and just use that app. But given the app does the same thing as our script you no longer need the app.

Our CPUfreq script locks all four cores to a maximum speed of 800MHz.

And this is one of the keys to understanding Android as an operating system ­- there are plenty of tweaks around that offer all manner of improvements but many of them can be implemented by simply installing and setting up your own scripts. And by understanding how to get scripts built into the OS you’re now well on your way to creating your own high-performance Android ROM without the need for any further apps.

Left: Read/write speeds on our 16GB Class-10 MicroSD card with 128KB read-ahead setting. Right: Increase read-ahead to 2048KB and read speed increases significantly on fast cards.




Tools



Referensi

Retrieved from "https://onnocenter.or.id/wiki/index.php?title=ROM_Android:_Membuat_Custom_ROM_menggunakan_Android_Kitchen&oldid=41263"