GSoC 2016 Week 1: Android SDK Tools in Debian
This is the starting week of Google Summer of Code 2016. As I am still
having school classes until mid-term evaluation, I have already
started the work before the coding phase. As my final exams are
approaching, my time spent on GSoC won't be more than about 18 hours
per week until 29 June.
I have been trying to build "android.jar", the Android platform
framework that comes with every "Android Platforms" in Android SDK and
is crucial to building an Android application. By several attempts to
compile the source code, I have found and packaged 5 dependencies:
* BoringSSL <https://boringssl.googlesource.com/boringssl>
* conscrypt <https://conscrypt.org>
* Okio <https://github.com/square/okio>
* OkHttp <https://square.github.io/okhttp>
* Templating Maven Plugin <http://www.mojohaus.org/templating-maven-plugin>
BoringSSL is required when building conscrypt, which only needs
BoringSSL's headers and generates some Java constants. After digging
into BoringSSL I found that Android has switched from OpenSSL to
BoringSSL since 6.0.0. Therefore I am planning to package the entire
BoringSSL libraries and let all Android packages use it. However lots
of people from the debian-security mailing list objected the
introduction of BoringSSL to Debian [1].
BoringSSL's package can be found at [2].
conscrypt is a compile dependency of "android.jar". The code
repository of this project resides in AOSP's "external" directory [3]
and do not has its own versioning. So I am treating this package as
other forked projects by AOSP like android-platform-external-libunwind
[4].
conscrypt's packaging can be found at [5].
Okio is a dependency of OkHttp. I have filed an ITP [6] and a RFS [7]
to Debian Java Team but no one is responding me...
OkHttp is a dependency of "android.jar". The latest version is 3.3.1
but it depends back on "android.jar" after version 2.5.0 which
introduced a circular dependency, so I am packaging version 2.5.0.
Templating Maven Plugin is a Maven plugin that filters Java source
codes using templates. It is used when building OkHttp.
After several weeks of try-and-failing, I have successfully compiled
all classes that make up "android.jar". There are other files inside
"android.jar" which need aapt to generate. However the aapt in Debian
fails to finish the job and shows:
```
aapt: tools/aapt/Images.cpp:811: void
checkNinePatchSerialization(android::Res_png_9patch*, void*):
Assertion `outPatch->getXDivs()[i] == inPatch->getXDivs()[i]' failed.
```
I have no idea by the time how to fix this, but the first reason came
to my mind is that probably 32-bit version of aapt won't fail.
dmtracedump, another tool in Android SDK, also fails to do its job in
64-bit version.
Next week, I will start to research for a workaround. I will first
build a 32-bit version of aapt and see if it works.
[1]: https://lists.debian.org/debian-security/2016/05/msg00009.html
[2]: https://anonscm.debian.org/cgit/android-tools/boringssl.git
[3]: https://android.googlesource.com/platform/external/conscrypt
[4]: https://packages.debian.org/source/sid/android-platform-external-libunwind
[5]: https://anonscm.debian.org/cgit/android-tools/android-platform-external-conscrypt.git
[6]: https://bugs.debian.org/825539
[7]: https://lists.debian.org/debian-java/2016/05/msg00057.html
--
/*
* 殷啟聰 | Kai-Chung Yan
* 一生只向真理與妻子低頭
* Undergraduate student in National Taichung University of Education
* LinkedIn: <https://linkedin.com/in/seamlik>
* Blog: <http://seamlik.logdown.com>
*/
Reply to: