Resource: LCU13 Name: Android not in sync with upstream & external projects Date: 28-10-2013 Speaker: Bernhard Rosenkranzer / Khasim Syed Mohammed Video: http://www.youtube.com/watch?v=tgVmianNZrQ

1. Android and its upstream projects
Bernhard “Bero” Rosenkränzer, LCU2013

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

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

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

5. 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?

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

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

8. 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?

9. 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?

10. 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?

11. 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?

12. 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?

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

14. connect.linaro.org