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

[Denis 'GNUtoo' Carikli]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20200311/3a1cc202/attachment.asc>