How to make your own Android ROM – Part 4: Custom Scripts
Android Kitchen helps you implement scripts - but you must write them yourself!
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
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
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
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
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
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
If you’re making a ROM for the Galaxy S3 smartphone you can open up a Linux text editor and type in the following:
#!/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
Changing CPU speed
In the same Linux text editor create the file 98cpufreq and type the following :
#!/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!
Our CPUfreq script locks all four cores to a maximum speed of 800MHz.
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.
No comments:
Post a Comment