On Tue, 10 Mar 2020 09:29:38 -0500 Joel Valenciano <[email protected]> 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.
pgpSpCYhDeuUO.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/replicant
