Android ROM Porting: A Review

Transcription

1 MIT International Journal of Computer Science and Information Technology, Vol. 5, No. 2, August 2015, pp Android ROM Porting: A Review Shubham Raj Singh er.shubhamrajs@gmail.com Rameez Arshad rameez.ars740@gmail.com Priyanka Goel Assistant Professor prie @gmail.com Pankaj Kumar noissypankaj@gmail.com ABSTRACT Android is a mobile operating system (OS) based on the linux kernel developed by Google. A ROM is the operating system software that runs an Android device. It is stored in the Read Only Memory portion of the hardware on the Android smartphone and/or tablet. All Android devices contain ROM installed by the manufacturer. But, we can gain the ability to install custom ROMs that will completely change the look and feel of the software. Android ROM porting refers to making a ROM compatible to our device. Flashing a ROM means installing the system image into the device s internal flash memory. This memory holds the Android s firmware just like the other devices with an embedded OS. Designed to improve the user experience and performance of the Android OS, a very popular custom ROM is Cyanogen Mod. Keywords: ROM, ROM Porting, Cyanogen Mod, Flashing ROM. I. INTRODUCTION Android is a mobile operating system (OS) based on the Linux kernel and developed by Google. It consists of a user interface which is based on direct manipulation. Android is designed primarily for touchscreen mobile devices such as smartphones and tablet computers. The OS uses touch inputs that correspond to real-world actions, like swiping, tapping, pinching, and reverse pinching to manipulate on-screen objects, and a virtual keyboard. Android OS is open source software which Google released the code under the Apache License. Android Open Source Project allows the user to modify and distribute it freely. Android also has application developer community that further extends the functionality of the device [1]. This is what makes Android to grow much more rapidly than its competitors. Kernel provides the basic system functionality such as process management, memory management and device management. Linux kernel provides device drivers which make our task easier while interfacing the android with peripheral devices. 2. Libraries: On the top of Linux Kernel another layer called libraries is present. It provides different libraries useful for well-functioning of android operating system. Libraries are java libraries which are built specifically for android operating system. Some of the libraries are listed below: Libraries Explanation II. ANDROID ARCHITECTURE Android operating system comprise of different software components arranges in stack. Different components of android operating system are: 1. Linux kernel: Bottom layer of android operating system is Linux kernel. Android is built on top of Linux 2.6 Kernel and few architectural changes made by Google. Linux SQLite SSL OpenGL It is used to access data published by content providers and includes SQLite database management classes. This is used to provide internet security. It is used to provide Java interface to the OpenGL/ ES 3D graphics rendering API.

2 MIT International Journal of Computer Science and Information Technology, Vol. 5, No. 2, August 2015, pp Libraries Media framework Web Kit Explanation It is used to provides different media codecs which allow the recording and playback of different media formats. This library is the browser engine which is used to display internet or HTML content. 3. Android Run time: It is third component of the android architecture and placed in second layer from bottom. It provides most important part of android called Dalvik Virtual Machine. Dalvik Virtual Machine is similar to JVM but only difference is that it is designed and optimized for Android. Dalvik Virtual machine uses core functions of Linux such as memory management and multithreading and enables each android app to run its own process. 4. Application Framework: It is second topmost component in android operating system stack Android applications which directly interacts with application framework. Application framework manages the basic functions of android device such as resource management, voice call management etc. 5. Applications: Applications created by third party users or developer will be installed on application layer. Below is architecture diagram of android operating system: III. ANDROID ROM The term ROM is misused, and a pseudonym. Up until recently, ROM s were storage chips consisting of Read-Only-Memory. The term which is closer to being correct with reference to Android, is Firmware. We can easily replace it all, if we choose to. Device manufacturers traditionally referred to a cell phone s included operating system as ROMs because they did not intend for us, the user, to replace it. Whether we call Cyanogen Mod a ROM or a firmware or an operating system or a distribution, it all means in this case the same thing. The ambiguous terminology is just the result of a decade-long transition from simple, non-replaceable software on hand-held devices to full-fledged, updatable operating systems on a small, portable computers that fits in the palm of our hand. This board has a few ROM chips, one of which tells the device how to boot the firmware. When people talk about installing ROM s on their devices, it refers to erasing or overwriting old Android software/system files, and replacing them with new ones to alter the behavior of Android and the device. A. Custom Rom A custom ROM is one that has undergone any modification from being a pure distribution of Android. Google make the Android source code available for anyone and people take this code and can change it for themselves. They can add features in it, or can redistribute it with fun additions. So a custom ROM can have some custom code modifications to make Android run better on a device, which may include changing the home screen, background services or default software. Many software experts collaborate together in communities to build the fastest ROMs or the ROMs having most of the features. The most popular now-a-days are Cyanogen Mod (which supports over 70 devices!), AOKP (a lightweight ROM with plenty of customization options), and Android Revolution, a heavyweight ROM which often focusses on looking great. B. Cyanogenmod Cyanogen Mod is an enhanced open source firmware distribution for smartphones and tablet computers based on the Android mobile operating system. It offers features and options not found in the official firmware distributed by vendors of these devices. Features supported by Cyanogen Mod include native theming support, FLAC audio codec support, a large Access Point Name list, an OpenVPN client, an enhanced reboot menu [3] [4], support for Wi-Fi, Bluetooth, and USB tethering, CPU overclocking and other performance enhancements, soft buttons and other tablet tweaks, toggles in the notification pull-down (such as Wi-Fi, Bluetooth and GPS), application permissions management and other interface enhancements. Cyanogen Mod does not contain spyware or bloat ware [3]. In many cases, Cyanogen Mod may increase performance and reliability compared with official firmware releases [4]. Cyanogen Mod is a free and open source software which is based on the official releases of Android by Google along with some added original and third-party code. IV. ROM PORTING A. Initializing A Build Environment (i) Setting-up a Linux Build Environment These instructions apply to all branches, including master. The Android build is routinely tested on recent versions of Ubuntu especially 14.04, but most distributions should have required build tools available. For Gingerbread (2.3.x) and newer versions, along with the master branch, a 64-bit environment is required. Older versions can be compiled on 32-bit systems [2] [9].

3 MIT International Journal of Computer Science and Information Technology, Vol. 5, No. 2, August 2015, pp (ii) Installing The Jdk The master branch of Android in the Android Open Source Project (AOSP) requires Java 7. On Ubuntu, use Open JDK. Java 7: For the latest version of Android [2] $ sudo apt-get update $ sudo apt-get install openjdk-7-jdk (iii) Installing Required Packages (Ubuntu 14.04) Ubuntu is 64-bit version and is recommended. Following command will work: $ sudo apt-get install bison g++-multilib git gperf libxml2-utils make zlib1g-dev:i386 zip (iv) Installing Required Packages (Ubuntu12.04) Ubuntu can be used to build older versions of Android. This version is not supported on recent releases. In this case, following commands will work: $ sudo apt-get install git gnupg flex bison gperf build-essential\ zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev \ libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386\ libgl1-mesa-dev g++-multilib mingw32 tofrodos\pythonmarkdown libxml2-utils xsltproc zlib1g-dev:i386 $ sudo ln -s / usr/lib/i386-linux-gnu/mesa/libgl.so.1 /usr/lib/i386-linux-gnu/ libgl.so (v) Installing Required Packages (Ubuntu ) Building on Ubuntu may be useful for building older releases of AOSP. Following commands will work: $ sudo apt-get install git gnupg flex bison gperf build-essential \zip curl zlib1g-dev libc6-dev lib32ncurses5-dev ia32-libs \ x11proto-core-dev libx11-dev lib32readline5-dev lib32z-dev\ libgl1-mesa-dev g++-multilib mingw32 tofrodos pythonmarkdown \ libxml2-utils xsltproc On Ubuntu 10.10: $ sudo ln -s /usr/lib32/mesa/libgl.so.1 /usr/lib32/mesa/libgl.so On Ubuntu 11.10: $ sudo apt-get install libx11-dev:i386 (vi) Using A Separate Output Directory By default, the output of each build is stored in the out/ subdirectory of the matching source tree. On some machines with multiple storage devices, builds are faster when storing the source files and the output on separate volumes. For additional performance, the output can be stored on a file system optimized for speed instead of crash robustness, since all files can be re-generated in case of file system corruption. To set this up, export the OUT_DIR_COMMON_BASE variable to point to the location where our output directories will be stored. Its command is: export OUT_DIR_COMMON_BASE=<path-to-our-outdirectory>. Or instance, if we have source trees as /source/master1 and / source/master2 and OUT_DIR_COMMON_BASE is set to / output, the output directories will be /output/master1 and / output/master2. It is important in that case to not have multiple source trees stored in directories that have the same name, as those would end up sharing an output directory, with unpredictable results. This is only supported on Jelly Bean (4.1) and newer, including the master branch. B. Downloading the Source Cyanogen Mod uses a special program for storing, distributing, maintaining, and synchronizing the thousands of source code files that make up Android. The system, known as a version control system, is called Git. Git was developed primarily by Linus Torvalds and is used not only by Cyanogen Mod, but by AOSP (Android Open Source Project the vanilla Android source code from Google), the Linux Kernel, and countless open source projects around the world. Git allows every developer to have their own full copy (called a Git repository ) of all the source code that is used to build Cyanogen Mod. The code base can be easily re-synchronized with a single command so that it is always kept up-to-date. Git also allows developers to easily contribute their bug fixes and enhancements back, where it may be accepted to become part of the official repository. The Android source tree is located in a Git repository hosted by Google. (i) INSTALLING REPO Repo is a tool that makes it easier to work with Git in context of Android. To install Repo: i. Make sure we have a bin/ directory in our home directory and that it is included in our path: $ mkdir ~/bin $ PATH=~/bin:$PATH ii. Download the Repo tool and ensure that it is executable: $ curl > ~/bin/repo $ chmod a+x ~/bin/repo For version 1.17, the SHA-1 checksum for repo is ddd79b6d5a7807e911b524cb223bc3544b661c28 For version 1.19, the SHA-1 checksum for repo is 92cbad8c880f697b58ed83e348d06619f8098e6c For version 1.20, the SHA-1 checksum for repo is e197cb48ff4ddda4d11f23940d316e323b29671c For version 1.21, the SHA-1 checksum for repo is b8bd1804f432ecf1bab730949c82b93b0fc5fede (ii) INITIALIZING A REPO CLIENT After installing Repo, we have to set up our client to access the Android source repository:

4 MIT International Journal of Computer Science and Information Technology, Vol. 5, No. 2, August 2015, pp (i) Create an empty directory to hold working files. If we are using Mac OS, this has to be on a case-sensitive file system. We can give any name like: $ mkdir WORKING_DIRECTORY $ cd WORKING_DIRECTORY (ii) Run repo init to bring down the latest version of Repo with all its most recent bug fixes. We must specify a URL for the manifest, which specifies where the various repositories included in the Android source will be placed within working directory. $repo init -u To check out a branch other than master, specify it with b for a list of branches. $ repo init u platform/ manifest -b android-4.0.1_r1 (iii) When prompted, configure Repo with real name and address. To use the Gerrit code-review tool, we will need an address that is connected with a registered Google account. Make sure this is a live address at which one can receive messages. The name that we provide here will show up in attributions for our code submissions. A successful initialization will end with a message stating that Repo is initialized in your working directory. Oour client directory will now contain a.repo directory where files such as the manifest will be kept. (iii) DOWNLOADING THE ANDROID SOURCE TREE To pull down the Android source tree to working directory from the repositories as specified in the default manifest, run: The Android source files will be located in working directory under their project names. The initial sync operation will take an hour or more to complete. (iv) USING AUTHENTICATION By default, access to the Android source code is anonymous. To protect the servers against excessive usage, each IP address is associated with a quota. When sharing an IP address with other users (e.g. when accessing the source repositories from beyond a NAT firewall), the quotas can trigger even for regular usage patterns (e.g. if many users sync new clients from the same IP address within a short period). In that case, it is possible to use authenticated access, which then uses a separate quota for each user, regardless of the IP address. The first step is to create a password with the password generator and follow the instructions on the password generator page. The second step is to force authenticated access, by using the following manifest URI: platform/manifest. It can be noticed how the /a/ directory prefix triggers mandatory authentication. We can convert an existing client to use mandatory authentication with the following command: $ repo init -u a/ platform/ manifest (v) USING A LOCAL MIRROR When using several clients, especially in situations where bandwidth is scarce, it is better to create a local mirror of the entire server content, and to sync clients from that mirror (which requires no network access). The download for a full mirror is smaller than the download of two clients, while containing more information. These instructions assume that the mirror is created in /usr/ local/aosp/mirror. The first step is to create and sync the mirror itself. Notice the --mirror flag, which can be specified only when creating a new client: $ mkdir -p /usr/local/aosp/mirror $ cd /usr/local/aosp/mirror $ repo init -u mirror/ manifest mirror Once the mirror is synced, new clients can be created from it. Note that it s important to specify an absolute path: $ mkdir -p /usr/local/aosp/master $ cd /usr/local/aosp/master $ repo init -u /usr/local/aosp/mirror/platform/manifest.git Finally, to sync a client against the server, the mirror needs to be synced against the server, then the client against the mirror: $ cd /usr/local/aosp/mirror $ cd /usr/local/aosp/master It s possible to store the mirror on a LAN server and to access it over NFS, SSH or Git. It s also possible to store it on a removable drive and to pass that drive around between users or between machines. C. BUILDING THE SYSTEM The following instructions to build the Android source tree apply to all branches, including master: (i) CHOOSING A BRANCH Some of the requirements for our build environment are determined by which version of the source code we plan to compile. We may also choose to download and build the latest source code (called master), in which case we will simply omit the branch specification when we initialize the repository. Once we have selected a branch, we can follow the appropriate instructions below to set up our build environment. (ii) INITIALIZE Initialize the environment with the envsetup.sh script. Note that replacing source with.(a single dot) saves a few characters, and the short form is more commonly used in documentation.

5 MIT International Journal of Computer Science and Information Technology, Vol. 5, No. 2, August 2015, pp $ source build/envsetup.sh or $. build/envsetup.s (iii) CHOOSE A TARGET Choose which target to build with lunch. The exact configuration can be passed as an argument. For example, the following command: $ lunch aosp_arm-eng refers to complete build for the emulator, with all debugging enabled. If run with no arguments lunch will prompt you to choose a target from the menu. All build targets take the form BUILD- BUILDTYPE, where the BUILD is a codename referring to the particular feature combination. (iv) BUILD THE CODE GNU can handle parallel tasks with a -jn argument, and it s common to use a number of tasks N that s between 1 and 2 times the number of hardware threads on the computer being used for the build. For example, on a dual-e5520 machine (2 CPUs, 4 cores per CPU, 2 threads per core), the fastest builds are made with commands between make -j16 and make -j32. (v) RUN IT We can either run our build on an emulator or flash it on a device. It should be noted that we have already selected our build target with lunch, and it is unlikely at best to run on a different target than it was built for. (vi) FLASH A DEVICE To flash a device, we will need to use fastboot, which should be included in our path after a successful build. Place the device in fastboot mode either manually by holding the appropriate key combination at boot, or from the shell with $ adb reboot bootloader Once the device is in fastboot mode, run $ fastboot flashall w The -w option wipes the /data partition on the device; this is useful for first time flashing a particular device but is otherwise unnecessary. (vii) READY TO USE Now the ROM is ready to use. The first boot may take some time as it optimizes the resources for the first time. After the Booting process is completed a setup application guides through the first use. V. CONCLUSION This paper is an innovative application and its main purpose is to get familiar with Android ROM and Android SDK. In future it can be extended further to take into consideration the optimality attitude of application. The next version can concentrate on remaining problems like portability between different kinds of device, adaptability with the change of API, friendlier interface, and also optimality in network usage. REFERENCES [1] [2] Overview of the sources by Google: [3] The Cyanogen Mod Learning Centre: org/ [4] XDA Community Forums: [5] XDA Learning Centre: [6] Essential Linux Device Driver Book [7] Tutorials on Android Internals by Marakana: com/watch?v=1_h4alqana0 [8] Github Repo: [9] Discussion over stack overflow forums: [10] A Documentary: Revolution OS