[Android-tools-devel] Doclava Is Highly Unreliable and We Should Find Another Way to Build android.jar

[殷啟聰]

Doclava is highly unreliable and causes great maintenance burden because:

  * The latest Doclava generates uncompilable code.
  * The current Doclava generates uncompilable code from android-25.
  * Finding a way to fix Doclava errors and figuring out AOSP's build
process is error-prone, takes lots of time and very difficult.

I think we should find another way to build `android.jar`, otherwise
there'll be unlikely any other `android-sdk-platform-xx` coming out to
meet the sun. Here are the ideas I have come up:

Option A: Build from the Java source tarball provided by Google [1]
combining `android-platform-frameworks-base`. Compiling
`AndroidManifest.xml` and `resources.arsc` and other resource files
still needs the code from AOSP, but we will no longer need to deal
with Doclava, AIDL or logtags.

Option B: Build from the unmodified Java sources of AOSP. This is very
hard to achieve since it needs a large amount of third-party
dependencies (conscrypt [2] and okhttp, etc.) and some non-existing
classes with no idea how to generate (e.g. com.android.internal.R).

Option A largely simplifies the maintenance but I am afraid there will
be license problems. The ZIP file itself is licensed under the
proprietary "Android SDK License", but all source code inside that ZIP
file are licensed as free software. My guess is, as long as our
tarballs include free software code rather than that proprietary ZIP
file, our package is still free software.

In the worse case where this package is still considered non-free, I
would prefer moving it into contrib than maintaining such
unmaintainable code. I strongly propose Option A to build android-25
and the other API Levels.

Cheers,
Kai-Chung Yan

[1]: https://dl.google.com/android/repository/sources-25_r01.zip
[2]: https://conscrypt.org