Welcome back to the third part.....
I'm gonna directly continue my previous article here so...
Another option you can add to your ROM is BusyBox. It’s a tool that combines hundreds of Linux command line tools into one app, such as the commands mkdir (make directory), mv (move), gzip (file compression) and loads more. Do you need it? If you’ve never used the command line before, then probably not, but it’s as close as you’ll get to turning your Android ROM into a more Linux-ified operating system. BusyBox doesn’t turn your Android ROM into a generic Linux distro, it just gives you access to those Linux command line apps.
If you don’t root your ROM, there’s little reason to install BusyBox because the program needs root access. However, if you do root your ROM, installing BusyBox is a good idea as some root access apps need access to BusyBox commands. Also, you’ll likely need to install a Terminal emulator to run BusyBox commands. You can grab Android Terminal Emulator from Google Play.
For me, the fun bit of making/baking your own ROM is choosing to add — or remove — apps and truly making it your own. In the case of Samsung’s most recent Galaxy S3 ROM at the time of writing, it could be that you simply want to reduce its huge 1.2GB size into something a little more manageable by removing some of the apps you neither want nor need.
When you create an Android app using the Android SDK and the Eclipse IDE, you end up with a single APK archive — essentially a ZIP file — which you can then install onto any appropriate Android device. Apps baked into a ROM are just packed in as their original APK files, which greatly simplifies both adding and removing apps.
When Android Kitchen pulls apart your initial ROM file, it puts everything in a subfolder of the /home/<username>/kitchen/ path called ‘working’ following the date and time; for example, /WORKING_061913_181512/. Bundled apps are stored in the /system/app/ subfolder; however, inside that folder you’ll probably find not only APK (Android Package) files, but also ODEX files, too.
Now is a pretty good time to introduce the idea of the ODEX file and the concept in custom ROMs of odexed and deodexed apps. When you create an Android app using the standard Android SDK/Eclipse compile method, you end up with a single APK archive file; inside that file is a ‘classes.dex’ (Dalvik Executable) file. It’s essentially the compiled part of your Android app. We could spend days talking about the heart of Android — it’s a Dalvik virtual machine — but keeping perspective, all you need to know for now is that the DEX file is run by the Dalvik virtual machine, so it’s a key part of your app.
That all exists inside the APK archive. The ODEX file is an optimised Dalvik executable. It’s compressed and contains parts of the app that Android can load when it boots up so as to speed up app loading times. Remember how it’s often been said you shouldn’t empty Android memory? This is one of the reasons why — the memory is loaded up with these ODEX files. However, there are issues with odexed apps. First up, your app now exists as two separate parts: the ODEX compressed file and the APK archive. While it’s easy to rip inside an APK archive, ODEX files are much harder to get into. Also, ODEX files get moved to another location when your ROM is installed, so you’ll then have two locations of app files to sort through to fully remove an app if you tried to do it post-ROM install.
A deodexed app is one where the ODEX file has been decompressed and its components put back into the APK file as a standard ‘classes.dex’ file. If you write your own Android apps using the standard Android SDK/Eclipse IDE method, no separate ODEX file is created so essentially, your apps are already deodexed.
The bottom line is odexed apps supposedly load faster; deodexed apps are easier to manipulate.
There’s one other trick that can make up for that faster loading time difference between odexed and deodexed apps and that’s called zipalign. Google recommends that every app developer runs their final key-signed app through the zipalign command line tool before uploading it to Google Play. It’s a way of ordering the contents of the APK file so that all uncompressed raw data (images or whatever) are aligned on four-byte boundaries. In short, it reduces the amount of RAM an app chews up when it’s running.
So in the end, its suggested that deodexed zipaligned apps run just as fast as odexed apps, but with lots of advantages: you get an app that’s a single APK file, it’s stored in one location, it’s easier to manipulate and it uses less RAM. For these reasons, you’ll find most custom ROMs are both zipaligned and deodexed for your Android computing pleasure.
If you’re wondering what all that has to do with customising ROMs, go back and re-read it. At the very least in our context, it means that to remove an app, if you see an APK file accompanied by an .ODEX file of the same name in the /system/app/ folder, you need to remove both.
The next big question is: which apps do you remove? If the ROM has been built well, the apps should still have their clear-language names, so you’ll get some idea as to what they do. The best way, though, is to go through your ROM’s /system/app/ folder, look at each app, research what it is, what it does and where it comes from. Based on that, you can decide whether it stays or goes. If that sounds too complicated, well, with over 800,000 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.
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.
To be continued...
No comments:
Post a Comment