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

[Hans-Christoph Steiner]

>From Michael of Briar:

-------- Forwarded Message --------
Subject: Re: [guardian-dev] call for help: Java/Gradle advice so we can
keep the Android SDK in Debian/buster
Date: Tue, 12 Feb 2019 12:32:54 +0000
From: Michael Rogers <michael at briarproject.org>
To: Hans-Christoph Steiner <hans at guardianproject.info>, Guardian Dev
<guardian-dev at lists.mayfirst.org>

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
>