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
Tweet

More Decks by Arnav Gupta

Other Decks in Technology

Transcript

  1. This should be easy !

    Get the source code

    Build it

    Flash on device

    Enjoy !

    View full-size slide

  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

    View full-size slide

  3. This should be easy, mostly.

    Get the source code

    Build it

    Make some changes

    Rebuild it

    Flash on device

    Enjoy !

    View full-size slide

  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 !

    View full-size slide

  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.

    View full-size slide

  6. Finally I can hack, build, deploy, and test ROMs with a
    wag of my tail ! Woof Woof !

    View full-size slide

  7. Setting up an Android OS
    Project
    Source. Edit. Collaborate. Codereview. Build. Automate. Deploy.
    - Arnav Gupta

    View full-size slide

  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.

    View full-size slide

  9. The important questions
    that come to mind ...

    View full-size slide

  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 ?

    View full-size slide

  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 ?

    View full-size slide

  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 ?

    View full-size slide

  13. … when we use our own ROM

    View full-size slide

  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

    View full-size slide

  15. Some numbers, before
    we begin

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  18. 450
    Roughly the number of total repos in the AOSP manifest

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  22. 2,100,000
    Total lines of Java code (exculding blanks, comments) in Android frameworks

    View full-size slide

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

    View full-size slide

  24. 42
    The answer to life, universe and everything

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  27. ‘repo’
    A tool made by Google to help in
    managing the source of huge
    projects like Android, Chromium

    View full-size slide

  28. manifest
    An xml file defining all the git
    repos needed in the project

    View full-size slide

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

    View full-size slide

  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.

    View full-size slide

  31. What can speed it up ?

    View full-size slide

  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

    View full-size slide

  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.

    View full-size slide

  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.

    View full-size slide

  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.

    View full-size slide

  36. Code Review
    Where all the drama happens

    View full-size slide

  37. Let’s see some code
    reviews

    View full-size slide

  38. Some things are alarming

    View full-size slide

  39. Sometimes there is caution

    View full-size slide

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

    View full-size slide

  41. And sometimes . . . well…

    View full-size slide

  42. But on a serious note

    View full-size slide

  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.

    View full-size slide

  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

    View full-size slide

  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]

    View full-size slide

  46. 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.

    View full-size slide

  47. On a separate note . .

    View full-size slide

  48. Google Search and Angular

    Google makes Angular.JS

    Angular is used to make single-page webapps

    Google search cannot index single-page
    webapps

    View full-size slide

  49. . . . but let’s not digress

    View full-size slide

  50. 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

    View full-size slide

  51. The Buildbot
    First you build the bot, then the bot builds.

    View full-size slide

  52. 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

    View full-size slide

  53. Installing Jenkins

    View full-size slide

  54. 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

    View full-size slide

  55. 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

    View full-size slide