Android and its upstream projects

Bernhard “Bero” Rosenkränzer, LCU2013

www.linaro.org

• Android is, in many ways, just another Linux distribution• As such, it includes code from many FOSS projects...• … and quite frequently, isn't in sync with what upstreams are

doing.

Android's upstreams

www.linaro.org

• Android imports an external FOSS project into its git repository (sometimes a released version, sometimes a git or svn snapshot)

• Patches to make it work with Android (and sometimes to add, remove or modify some functionality) are added inside Android's git repository

• There is little or no effort made to upstream those changes, some changes are a little bogus (checking in a config.h generated by autoconf to avoid the need to call configure, ...)

• A newer upstream release may or may not be merged into Android – if at all, merges typically happen months after the upstream release

• Android has no concept of OS component packages, and cannot update an individual component (e.g. openssl) – often leading to important upstream updates being ignored by device makers

Current situation

www.linaro.org

• Patches needed for Android go upstream ASAP (#ifdef-ed if necessary)

• Upstream releases can be merged into Android quickly and painlessly because all relevant patches are already there

• Upstream releases actually are merged in a timely manner• Android adopts some sort of upstream packaging so e.g. an

OpenSSL security update can be pushed even to people who are stuck with an ancient Android version

Ideal situation

www.linaro.org

• Upstream Android will likely never use regular Linux style packaging because OEMs don't like the idea of having parts of their OS overwritten by an update too much, so – aside from maybe making sure rpm, dpkg and friends can run on top of Bionic – let's focus on what can be done:

• Try to upstream patches found in the Android source tree• Merge newer upstream releases into the Android source tree

and try to upstream that• Find solutions for projects that have been abandoned (or are

otherwise obsolete/bad choices) upstream

What can Linaro (and others) do?

www.linaro.org

• Toolchains:– Android 4.3 uses a modified version of gcc 4.6

– Linaro already provides alternative toolchains based on gcc 4.7 and gcc 4.8 (using Linaro performance patches + forward ports of Google's patches) and [unofficially] llvm/clang 3.4svn

• Kernel:– Android devices typically are released with a kernel that is slightly outdated at

device release time, and never get kernel updates (at best, they get updates from the -stable branch within their minor kernel release, e.g. v3.0.1 → v3.0.15)

– Linaro provides current kernels with patches needed to make Android work (Binder, ashmem, …) - but can't possibly release kernels for every device, and device specific changes are typically not upstreamed by handset makers.

Core components

www.linaro.org

● Freetype

– Android uses 2.4.9

– Current 2.5.x releases add Adobe's CFF engine (better TrueType rendering) and embedded bitmaps (color emoji etc)

What are we missing out on?

www.linaro.org

● Harfbuzz, Harfbuzz-ng

– Also on font rendering, Android uses a revision of harfbuzz from February 2012 (this tree is essentially unmaintained, but still needs to be watched for fixes – or better yet, get rid of it) and harfbuzz-ng 0.9.14

– Current Harfbuzz-ng is 0.9.22 with various seemingly important changes:

● Bug fixes (including a fix for an undefined memory access)

● Several Arabic mark positioning and width bugs

● Major speedups in OpenType processing

What are we missing out on?

www.linaro.org

● V8, WebRTC, Chromium, WebKit, WebP

– Outdated versions included in Android – v8 3.9.24.30 (current work goes into 3.21.x), WebRTC rev. 180 (current: 4933), Chromium 12.0.742.130 (July 2011)

– WebKit and WebP fairly current and synced frequently (last sync shortly before 4.3 release)

– Lots of work has gone into those projects since, e.g.

● Performance improvements, including better VFPv2 and VFPv3 support

● Bugfixes (including support for newer toolchains already backported by Linaro)

● Variable limit increased in v8

● Debugging improvements

– If I was wearing my tin foil hat, I'd make some comment about this being related to the push for binary-only Chrome for Android...But of course, any reasonable person knows this is just because nobody has time to work on it...There might also be binary compatibility issues

What are we missing out on?

www.linaro.org

● Image formats – libjpeg, libpng, libgif

– libpng 1.2.46 (current: 1.6.6/1.2.50)

● Potential problem: Binary compatibility. Soname has changed 3 times since Android's forking... But Android has no concept of sonames, so this is potentially dangerous for NDK users – workaround could be naming it libpng16.so (would require changing the linker command every time libpng is updated to a new major version though...)

● Fixes for important security backports were backported to 1.2.46, we're not affected by CVE-2011-3048 anymore

● Nevertheless, we can't stay on dead code forever, this needs to be addressed at some point.

● Changes include major cleanups and optimizations, support for some new chunks

– libjpeg 6 (current: 9a – better yet, switch to libjpeg-turbo unless we need SmartScale)

● Last synced with upstream in November 2009

● libjpeg-turbo is heavily optimized, among other things with NEON support

● Linaro has already made the switch to libjpeg-turbo...

– … but then fell into the same trap, no libjpeg-turbo updates since January 2012 (latest release: 1.3.0 from Sept 25, 2013)

– giflib 4.1.6 (current: 5.0.5/4.2.3)

● Many important things (reentrancy, ...) added in 5.x – but are gifs still relevant?

What are we missing out on?

www.linaro.org

● libusb

– Android's libusb derives from libusb 1.0.9

– libusb is essentially dead, with even its maintainers telling people to use the libusbx fork (currently at 1.0.17)

– libusbx is primarily about bugfixes

What are we missing out on?

www.linaro.org

● STL

– Parts of the C++ Standard Template Library (STL) are used by almost all C++ based projects and libraries, including those that are part of Android

– Android decided not to use GNU libstdc++ because of its GPL-with-linking-exception licensing

– So it chose STLport 5.2.1 (released 2008) instead... But STLport hasn't made any releases since (and seems to be almost unmaintained – the latest commit in the git repository is more than a year old). In the mean time, other STLs have moved on, speeding things up [and STLport wasn't known for its speed when it was still current] and implementing C++11, beginnings of C++14, …

– It may make sense to go with a viable alternative, such as GNU libstdc++ (not liked in Android because of licensing) or LLVM's libc++ (probably the best choice – small, fast, and under a BSD-like license)

– Issue with binary compatibility – source level compatibility is almost 100%, binary compatibility doesn't exist. Still, this may be the only way to not fall behind the rest of the world.

– Shipping 2 STLs is possible, but still causes issues (an application that links to stlport and to a library linked against libc++ is likely to see weird issues)

What are we missing out on?

www.linaro.org

● apache-harmony

– Android's core Java class library is derived from Apache Harmony svn rev. 1097236

– Apache decided to abandon Harmony on November 16, 2011 (last svn rev.: 1148509) – Android has made slight modifications on top of Harmony, but not enough to keep a dead project alive...

– Can Android stay on the Java 6 language level forever? This may seem feasible now with Java 7 and 8 not introducing too many important changes – but what about 9? 10? 50?

– What are possible alternatives?

● OpenJDK's class library (Unlikely to happen upstream because of Google-Oracle patent fighting)

● GNU Classpath (Unlikely to happen upstream because Android doesn't like GPL-with-linking-exception licensing)

A problem waiting to happen...

More about Linaro: http://www.linaro.org/about/More about Linaro engineering: http://www.linaro.org/engineering/How to join: http://www.linaro.org/about/how-to-joinLinaro members: www.linaro.org/members

connect.linaro.org