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.
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.
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:
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:
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)|
|AFTER (2048KB setting)|
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 :
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.