Back

Fixing up a custom Android build: Pitfalls and possibilities

Although Android and iOS mobile application development is an exciting and rewarding job by itself, sometimes we need to go deeper and fine-tune a whole operating system so that it satisfies certain business requirements. As this is not something done very often, there are quite many pitfalls and not much advice over the Internet on how to overcome them.

First of all, there are different types of custom-building a fork of Android operating system. The easiest one would be to create new firmware while leaving the main feature set of the target device intact; a good example of this are various non-stock ROMs for smartphones and tablets built by enthusiast developers or bigger companies like CyanogenMod.

Another kind of customization is forking the OS in order to install it on a new, often self-developed piece of hardware. This is the way of Amazon with its Fire family of tablets and smartphones, as well as many lesser companies, mostly building devices for various e-commerce uses, like Clover.

Finally, the third type is to modify Google’s mobile OS  so that some of its fundamental principles change, allowing new ways of using it to achieve business goals. That’s where we at Stanfy have gained a valuable if somewhat painful experience in interaction with Android’s seamy side.

Welcome, Mr. John Doe

The project that challenged our mobile development team to dig deeper into Android’s entrails is Keypr, where Stanfy is responsible for building the software for hotel in-room tablets.

Although similar products are usually implemented by the means of an application installed on an iPad or Android tablet, capabilities of this solution were not enough to satisfy all needs, especially those related to security, user-specific experience and role-based access to the device. So the decision was made to create a product that would feel truly personal to each hotel’s guest — and this proved to be the difficult part.

Looking for possible ways to build the required product, Roman Mazur’s team discovered there wasn’t much choice in operating systems. Today, Android seems to be the only mobile open-source OS that is mature enough to be used for business needs. In the realm of Android, however, there’s a bunch of forks, including the famous CyanogenMod that could be used to build the necessary functionality upon.

The team, however, ended up working with the official Android Open Source Project, or AOSP supported by Google. It is supposed to be installed on Nexus 7 (2013) tablets in hotels’ rooms. When a guest checks in, a new account is created on the device, making it possible for the user to change settings as she pleases. Of course, all personal data is removed when the guest checks out.

Main struggles

So, what problems should you expect to rise when trying to use Android in a way that wasn’t exactly foreseen by its creators?

The main one is the hassle around user management, Roman says. Although Android (in this case KitKat) allows you to create additional users on a tablet, it’s supposed to be a manual operation. Automatization of it makes quite surprising bugs to appear that would never be possible on a personal device.

In particular, a nasty bug showed itself when the team tried to create a password for a new user. It turned out that if you need to set up a user’s password from under another user’s account (a scenario that never happens “in the wild”), the salt for storing the password on the device will be taken from the details of the current user. This, of course, means that the password won’t work for the user it was intended for, as the system will try to decrypt it with the wrong salt.

Another pain could be hidden in the process of creating a new launcher, and particularly widgets to use with it. The way Android’s framework is built leaves a myriad of ways for a mobile app developer to create memory leaks that are hard to detect but can easily render the target device unusable in the course of a few hours. Unfortunately, the longer it takes to discover an issue, the harder it becomes to realize its existence and come up with a fix.

Lessons learned

To sum up the developers’ experience gained while working on the project, here’s a few pieces of good advice for those looking to build a customized version of Android.

  • Don’t be afraid of going deep into the OS’ internals. The beauty of open source is that you can solve virtually any problem, however it might (and usually does) require good knowledge of how Android works. It’s also time-consuming. But rewarding.

  • Be aware of the high possibility of leaving memory leaks. If you’re working on Android widgets, always think about it, and test your code when you can.

  • Use the latest version of the OS if possible — many issues could be solved for you by Google. The Keypr project was started way before the release of Android 5.0 Lollipop, however it already can be seen that Google has done quite a bit to address user administration issues and make things easier for third-party developers.

  • Nothing is impossible. Seriously. Development tasks and projects can be difficult or time-consuming, but with the mobile technology in its current state it seems possible to implement the most extravagant ideas. It’s just a matter of time, determination and imagination.

Image credit: Keypr, danishdynamite

January 14, 2015

androidAOSPcustom ROMKeyprtabletsTips