This should be easy !● Get the source code

● Build it

● Flash on device

● Enjoy !

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

This should be easy, mostly. ● Get the source code

● Build it

● Make some changes

● Rebuild it

● Flash on device

● Enjoy !

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 !

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.

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

Setting up an Android OS Project

Source. Edit. Collaborate. Codereview. Build. Automate. Deploy.

- Arnav Gupta

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.

The important questions that come to mind ...

… 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 ?

… 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 ?

… 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 ?

… when we use our own ROM

Managing the sourceIt'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 & CodereviewGithub 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 distributeFor 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

Some numbers, before we begin

12 GBChecked out size of the inflated source tree

25 GBAndroid source code total git history size for Android 6.0

450Roughly the number of total repos in the AOSP manifest

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

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

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

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

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

42The answer to life, universe and everything

The SourceThere is just way too much of it.

‘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

‘repo’A tool made by Google to help in

managing the source of huge

projects like Android, Chromium

manifestAn xml file defining all the git

repos needed in the project

The BuildCompiled few million LoC, and takes an eternity

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.

What can speed it up ?

ccacheTo 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

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.

shared lib cacheCache 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.

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

Code ReviewWhere all the drama happens

Let’s see some code reviews

Some things are alarming

Sometimes there is caution

Sometimes people don’t want their own patch submitted

And sometimes . . . well…

But on a serious note

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.

Install GerritDownload 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

Gerrit Install WizardCreate '/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]

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.

On a separate note . .

Google Search and Angular● Google makes Angular.JS

● Angular is used to make single-page webapps

● Google search cannot index single-page

webapps

. . . but let’s not digress

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

The BuildbotFirst you build the bot, then the bot builds.

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

Installing Jenkins

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

OTA Updates

Full size updateAOSP ~ 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 updatesSmallest 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 updateAn 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