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

[Hans-Christoph Steiner]

Sorry for the slow response, this seems fine by me.

.hc

殷啟聰:
> 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
> 
> _______________________________________________
> Android-tools-devel mailing list
> Android-tools-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
>