Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Setting up an Android OS Project

Arnav Gupta
December 19, 2015

Setting up an Android OS Project

Whether you want to create a community based / open source Android custom ROM project, or you are from an OEM/ODM who is creating their own fork of Android, you’ll have the need for the following;

Hosting the source centrally, which can be checked out and committed back to easily
Host a code-review server, because you’ll have multiple engineers working simultaneously on multiple sub-modules
Set up a CI server for building the ROM (for both testing patches and generating nightlies/releases)

This workshop will cover these three main problem statements and will be consisting of 3 parts

Checking out the Android Open Source Project, and host your own fork (or a part of it); be able to download and sync it using repo
Setup and host code review using gerrit (A code review software made by Google and used by AOSP and Chromium project); managing repositories, user roles and rights, replication etc.
Setup a buildbot using Jenkins/Hudson. Setting up build tasks for testing of patches, and for generating nightly/snapshot/release builds.

Arnav Gupta

December 19, 2015

More Decks by Arnav Gupta

Other Decks in Technology


  1. This should be easy ! • Get the source code

    • Build it • Flash on device • Enjoy !
  2. Or more technically speaking. . . $ curl https://storage.googleapis.com/git-repo-downloads/repo >

    ~/bin/repo $ chmod a+x ~/bin/repo $ mkdir ~/android $ repo init -u https://android.googlesource.com/platform_manifest -b android- 6.0.0_r25 $ repo sync $ . build/envsetup.sh $ lunch full_hammerhead-eng $ make $ fastboot flash --all
  3. This should be easy, mostly. • Get the source code

    • Build it • Make some changes • Rebuild it • Flash on device • Enjoy !
  4. This should be easy, mostly, I guess . . .

    • Get the source code • Build it • Make some changes • Rebuild it • Flash on device • Test it works • Commit changes • Enjoy !
  5. This should be easy, mostly, I guess. Or is it

    really??? • Get the source code • Build it • Make some changes • Rebuild it • Flash on device • Test it works • Commit changes • Review everyone’s changes • Release your Android ROM • Enjoy ! Now fix all the reported bugs.
  6. Finally I can hack, build, deploy, and test ROMs with

    a wag of my tail ! Woof Woof !
  7. Setting up an Android OS Project Source. Edit. Collaborate. Codereview.

    Build. Automate. Deploy. - Arnav Gupta
  8. Before we begin, let me gloat about myself a bit

    . . . Undergraduate Student, Electrical and Electronics, Delhi Technological University Contributor to CyanogenMod, AOKP and other custom ROM projects. Developer Relations team, YU Televentures. Few contributions to AOSP - in Kitkat and Lollipop.
  9. The important questions that come to mind ...

  10. … when we start building • What architecture can you

    build on? What architecture can you build for ? • What packages are needed to build the Android source code ? • What environmental variables are needed ? • What are the minimum hardware requirements ? • How much time does it take to build? How to reduce ? • Any steps to improve incremental builds ? • How to build partially, or only some modules ?
  11. … when we start pushing and pulling • How to

    pull updates from upstream ? • How to collaborate as a team/community ? • How to make source available over LAN ? • How to reduce redundant data download when building multiple variant/version ? • How to contribute to your own project? How to contribute back to Google? • How to have a transparent, hierarchical, access-controlled code review ?
  12. … when we start distributing the OS • How to

    send updates ? OTA or not ? • Can OTA updates be delta ? • How to update system apps over the play store ? • How to make sure 3rd parties cannot exploit SignatureOrSystem perms ? • Rooted or not ? Debugging enabled or not ? • How to handle dirty flashes ?
  13. … when we use our own ROM

  14. Managing the source It's 25 GB. So let's not download

    what we don’t want. Building non AOSP devices means conflicting source trees If you are a company, you’d like to have a local copy of source, instead of each employee downloading it. Contribs & Codereview Github PR’s are great for a single repo. But Android spans across 400+ repos, many interdependent. One single patch might have dependencies on other patches on other projects. Managing rights to merge, make branches, approve. Automated verification that a patch doesn’t break the build. Build and distribute For frequent, multi-device builds, a fairly powerful build machine needed Make builds automatically available over a download server. Generate deltas for updates. Maintain proper versioning of builds. Differentiate between nightlies, betas, stable builds and releases. Keep track of bugs, and fix blames on build numbers correctly. The three problems, and the solutions
  15. Some numbers, before we begin

  16. 12 GB Checked out size of the inflated source tree

  17. 25 GB Android source code total git history size for

    Android 6.0
  18. 450 Roughly the number of total repos in the AOSP

  19. 188,000 Patches up for review on android-review.googlesource.com

  20. 197,300 Number of issues opened on code.google.com/p/android

  21. 750,000 Total lines of C/C++ code (without comments) in Android

    system and bionic
  22. 2,100,000 Total lines of Java code (exculding blanks, comments) in

    Android frameworks
  23. 50,000,000 Number of people using Cyanogen OS and CyanogenMod ROMs

  24. 42 The answer to life, universe and everything

  25. The Source There is just way too much of it.

  26. ‘repo’ A tool made by Google to help in managing

    the source of huge projects like Android, Chromium repo init -u http://url.of/manifest repo sync [-f] [-j 4] repo init -g a,b,-c,-d repo start newbranch . repo upload
  27. ‘repo’ A tool made by Google to help in managing

    the source of huge projects like Android, Chromium
  28. manifest An xml file defining all the git repos needed

    in the project
  29. The Build Compiled few million LoC, and takes an eternity

  30. The basic steps . build/envsetup.sh lunch [device-buildtype] lunch aosp_hammerhead-eng make

    make Contacts.apk cd packages/apps/Contacts && mmm Sets up the build environment. Initialises all env vars. Defines functions to various build tasks. Defines a target device. Generates makefiles and changes env vars accordingly. Well this one’s obvious Two ways to make the Contacts package. First one builds all dependencies. Second one works only for incremental builds.
  31. What can speed it up ?

  32. ccache To speed up low level file compilations (drivers, system)

    • Set USE_CCACHE=1 and CCACHE_DIR appropriately • First build will become longer. Subsequent builds will be shorter • Use separate ccache folders per device if you can afford. • Set a comfortably large cache max size
  33. prebuilt chromium * for versions prior to 6.0 (M) Instead

    of building inline, keep a prebuilt copy of webview.apk and libwebviewchromium.so Webview changes once every 2 months or so. Android 6.0 uses prebuilt Google- signed webview only.
  34. shared lib cache Cache the dynamic libs review.cyanogenmod.org/92967/ Caches the

    built up libs, per device. If no changes in source of a lib (or it’s dependencies), it won’t be built. Reduces 30-40% build times for recurring aarch64 builds.
  35. $$$ money $$$ So that you can ramp up your

    hardware 03:32:46 - Time taken for clean Nexus 5 build of AOSP 6.0 on Core i5 2.5 Ghz (2-core, hyperthreaded), 8 GB RAM, 5400rpm HDD. 00:24:03 - Time taken for clean Nexus 5 build of AOSP 6.0 on Core i7 3.0 Ghz (4-core hyperthreaded), 16 GB RAM, SSD.
  36. Code Review Where all the drama happens

  37. Let’s see some code reviews

  38. Some things are alarming

  39. Sometimes there is caution

  40. Sometimes people don’t want their own patch submitted

  41. And sometimes . . . well…

  42. But on a serious note

  43. Gerrit • A code-review server written to work on top

    of Git • Developed by Google to support large multi-repository projects like Chromium, Android etc. • Supports comments, voting (+1, +2), approval and verification. • Has REST API, can be accessed over SSH as well.
  44. Install Gerrit Download latest from : https://gerrit-releases.storage.googleapis.com/index.html $ wget https://www.gerritcodereview.com/download/gerrit-2.11.5.war

    Recommended to create separate user gerrit which will run the gerrit daemon. $ sudo adduser gerrit $ sudo su gerrit $ mkdir ~/gerrit_site $ java -jar gerrit-2.11.5.war init -d ~/gerrit_site
  45. Gerrit Install Wizard Create '/home/gerrit_test/gerrit' [Y/n]? Y Location of Git

    repositories [git]: Set anywhere, default $GERRIT/git Database server type [h2]: h2/mysql/postgres (default h2) Authentication method [OPENID/?]: OPENID/HTTPS/OAUTH Email Delivery : Use SMTP configs of Gmail/Hotmail etc, or use sendmail Listen on port [29418]: Port for SSH access to gerrit Http Daemon : Set up as per proxies and required port [8080]
  46. None
  47. Gerrit OAuth Plugin • Google makes Gerrit • Gerrit only

    supports OpenID • Google has deprecated OpenID and uses Oauth via Google+ Signin • Gerrit, by default, has OpenID, but no Oauth. So we need a plugin.
  48. On a separate note . .

  49. Google Search and Angular • Google makes Angular.JS • Angular

    is used to make single-page webapps • Google search cannot index single-page webapps
  50. . . . but let’s not digress

  51. Add Oauth login/signup to Gerrit • https://github.com/davido/gerrit-oauth-provider • Get latest

    .jar from releases • Add to $GERRIT/plugins/ • Create an app on Google Dev Console. Get an “Other Application” auth token. • Create an app on Github Dev Console. Get the auth tokens • Re-run Gerrit init, the wizard will ask for above keys
  52. The Buildbot First you build the bot, then the bot

  53. Installing Jenkins $ wget -q -O - https://jenkins-ci.org/debian/jenkins-ci.org.key | sudo

    apt-key add - $ sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list' $ sudo apt-get update $ sudo apt-get install jenkins
  54. Installing Jenkins

  55. Distributed Jenkins builds • We can use multiple slaves connected

    to a master Jenkins bot • Best way is the use SSH based slaves. All slaved need to be running sshd. • Add id_rsa.pub from master, and add to authorized_keys of slaves • Set up the slave using - ◦ Manage Jenkins -> Manage Nodes - > New Node
  56. OTA Updates

  57. Full size update AOSP ~ 350MB + Gapps ~150MB Enterprise

    OS can easily be 1 GB Cumbersome for end users to download Should be used only when a delta updates won’t work. OEM’s use full-size updates when updating via PC-suites. Hexdiff partition updates Smallest size updates. 5.0 > 6.0 can be as small as 100MB (for a 1 GB system image). Only safe for controlled environments. Won’t work on devices that are rooted and have a modified system partition. Ideally should check for partition integrity before getting applied. Filewise diff update An unconventional compromise between the two. Smaller than full-size update. Will work with modified system partitions too. http://gerrit.aokp.co/13262/ Different ways to do an OTA Update