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

[殷啟聰]

Turns out I was wrong, `sources-25_r01.zip` [1] is as useless as the
current code base since it's full source code instead of stubs.

So we have to switch to use the `android-stubs-src.jar` bundled in
`platform-25_r01.zip` [2]. I pushed the initial packaging to GitLab
[3]. This attempt still uses Doclava to generate the sources of
`uiautomator.jar` because I can't find its stubs anywhere.
Surprisingly, Doclava works on `uiautomator`!

In the branch `drop-doclava` [4], Doclava is completely dropped and
`uiautomator.jar` is built from its full source. This works nicely and
I prefer this attempt because I want to get rid of Doclava.

The problem is that only android-24 and beyond contain an
`android-stubs-src.jar`, which means we can't build other API Levels
before android-24. But this is the best way so far. Hopefully Doclava
works perfectly on android-22 and those before it.

If no one objects, I will push the code to Alioth and finish the copyright file.

Cheers,
Kai-Chung Yan

[1]: https://dl.google.com/android/repository/sources-25_r01.zip
[2]: https://dl.google.com/android/repository/platform-25_r01.zip
[3]: https://gitlab.com/seamlik/debianpkg_android-framework-25_no-doclava
[4]: https://gitlab.com/seamlik/debianpkg_android-framework-25_no-doclava/tree/drop-doclava

2017-03-03 20:41 GMT+08:00 殷啟聰 <seamlikok at gmail.com>:
> 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