[Replicant] Could we build the Android frameworks fo Linux?

[Joel Valenciano]

In AOSP's build system, Soong (https://source.android.com/setup/build)
is the Makefile generator. At least in the C and Java builders,
modules are sort of like make targets; you give them a list of source
files, some flags, and other details, and they'll output a massive
Ninja build file. The build files themselves are kind of like JSON; it
might be possible to use the same build files, but modify the build
system to work in a more friendly manner?

To be honest though, I don't really know that much about how Android
uses HALs. It looks like with Oreo, Google added HIDL and Project
Treble to make devices easier to update, but I don't know much about
before that.

On Tue, Mar 10, 2020 at 9:34 PM Denis 'GNUtoo' Carikli
<GNUtoo at cyberdimension.org> wrote:
>
> On Tue, 10 Mar 2020 09:29:38 -0500
> Joel Valenciano <joelv1907 at gmail.com> wrote:
>
> > Yeah, I was asking about running on top of GNU/Linux. I think it
> > should be possible; the Compatibility Definition Document
> > (https://source.android.com/compatibility/overview) only requires ABI
> > compatibility for a few native libraries, and most of that is covered
> > by, for example, libhybris.
> On one side it's meant to interface with the hardware specific
> libraries that usually implement HAL API. Do you have some ideas on
> what API it implements on the other side? Does it fully replace the HAL?
>
> For the framework there is also the issue of the JVM and things like
> that, and I don't know much standalone can the Android components be.
>
> I probably need to find the time to do some research to find out if
> there are other free software projects that have been or are doing that.
>
> > The build system does have "packages", I think, in the form of
> > modules. The names used in Makefile LOCAL_MODULE definitions and
> > Blueprint modules have to be unique, I think; a while ago I tried
> > running the build system with just the frameworks, libcore and art
> > repositories, and I got several "undefined module" errors. Maybe the
> > license information could be added there as variables or Blueprint
> > properties?
> What I mean by packages is that a given build system has files, with
> metadata about the package (like the license), that also has
> instructions to wrap a low level build system like autotools or cmake,
> and at the end a real package is produced.
>
> The package can then be used to construct an image that can be
> installed on the device.
>
> Having a package manager on the target device would also be nice but
> it's not strictly necessary yet as we didn't look into which process we
> could use to reduce up the amount of time between updates.
>
> The GNU/Linux equivalent of the Android build system would be to use a
> huge a repository with tons of submodules, each with the same build
> system (like automake) which at the end produce an image.
>
> This is probably done for software like Chromium for instance.
>
> The issue with that kind of approach for a complete OS distribution is
> that you start having huge issues when you want to integrate software
> that have other low level build system like autotools or cmake.
>
> Each time you run a build, it needs to run make in the Linux source
> code, even if nothing has changed. And the more we integrate GNU/Linux
> components in Replicant, the more the build becomes painfully slow.
>
> And for MESA it's way worse than that as some changes aren't detected
> at all.
>
> When moving a library in the target rootfs, the old library is also
> kept, which can cause issues.
>
> > And I think the host-side utilities are linked to the version of Glibc
> > in the AOSP's prebuilts repositories. Running "readelf -d" on adb says
> > it's linked to "libc.so.6".
> That's really interesting.
> Thanks a lot, I really need to look into it.
>
> Denis.