[guardian-dev] call for help: Java/Gradle advice so we can keep the Android SDK in Debian/buster

Hans-Christoph Steiner hans at guardianproject.info
Wed Mar 6 12:02:05 EST 2019


This was the tip that finally solved it!  Here's the commit:

https://salsa.debian.org/android-tools-team/android-framework-23/commit/a54bfa906afc9b139f1f6c1a99f76effec301a3e

.hc

Michael Rogers:
> Hi Hans-Christoph,
> 
> As far as I can tell, "javac --patch-module" won't get you where you
> need to go. You could create (perhaps using symlinks) the directory
> structure it's expecting, where the root of the package namespace is
> inside a directory named after the module (e.g.
> src/main/java/java.base/java/lang), which contains a suitable
> module-info.java. But even so, --patch-module would result in the code
> being compiled as a module. You'd then need to modify the rest of the
> toolchain to get every java call to consume that module. I don't know if
> that would even be possible for d8, ProGuard, etc.
> 
> I think what you probably want is for the code to be compiled as Java
> 8-compatible class files. If I've understood the email thread correctly,
> that should be possible, and it's encouraging that adding "--release 8"
> to the compiler options has reduced the scope of the problem to just the
> doclava call. In other words, it did solve the problem for the other
> javac calls.
> 
> This is just a random guess that you've probably already considered, but
> is it possible that the "--release 8" argument that's passed to javac
> isn't being passed to javadoc when running doclava? Perhaps the task
> type for javadoc isn't JavaCompile, for example? (The same might apply
> to -source and -target, I guess - I don't know if sourceCompatibility
> and targetCompatibility set those arguments for javadoc as well as javac.)
> 
> Cheers,
> Michael
> 
> On 31/01/2019 08:25, Hans-Christoph Steiner wrote:
>>
>> The Debian Android Team has been packaging the Android SDK with 100%
>> free software and reproducible builds.  The standard Android SDK
>> binaries from Google have a non-free license and are built with ~13GB of
>> mystery binaries they call "prebuilts".
>>
>> There are two key packages from the Debian Android Tools suite of
>> packages that are currently not going to make it into the buster
>> release.  The core of the problem is that buster is using Java 11, and
>> the Android AOSP code base still uses Java8 and, only in some cases,
>> Java9.  As far as I can tell, just rebuilding the current stretch
>> package or updating will have more or less the same problems there.
>>
>> So far, apo of the Java Team, seamlik of Java/Android teams, and I have
>> all tried quite a bit to get something working.  Now we are banging our
>> heads against details in Java builds that none of us have ever dealt
>> with before.  So we're putting out the call for help, to find someone
>> with this knowledge.  Right now, I think we need to figure out the new
>> Java9 "modules", specifically using the --patch-module= flag to javac
>> and java.
>>
>> Lots more details here:
>> https://lists.debian.org/debian-java/2019/01/msg00052.html
>>

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556


More information about the guardian-dev mailing list