Hey Stephen,

I took a brief look at GloDroid. It looks like just another AOSP tree but
with support for more devices like you mentioned. 
But SharkBait aims to build Android on the device itself, the flavour of
Android should not matter. And for the same reasons, I chose Lineage's
tree because of the massive device support it has.

To implement SharkBait, we will have to swap the toolchains AOSP offers 
with the ones supporting aarch64 host. Once that is sorted out, we could,
in theory, implement any flavour of AOSP, be it glodroid, or any other
fork, just by tracking SharkBait's toolchain sources.

On top of that SharkBait aims also to separate the AOSP modules and
provide updates via Portage. But I predict that this would be SharkBait
specific.

Targeting newer devices like the PinePhone would be like the normal way
AOSP forks like Lineage extend support to newer devices. I agree on a
PinePhone target.

Once again, I thank you for offering me help in getting such devices.
But I would politely ask for you to wait until I implement SharkBait on
a phone first (the Lineage sources for my phone are easily available).
Benda offered me an arm64 server for the project, I think that would be
enough to work on, once I succeed in building the toolchain (or fail to
do so because of hardware limitations).

Thanks,
Gunwant



On 20/07/24 01:07PM, UnderSampled wrote:
> You may find this useful: https://glodroid.github.io/
> This is a modern AOSP tree for OrangePi, RaspberryPi, and Pine64 devices. That includes the Pinebook and PinePhone: https://www.pine64.org/.
> 
> I can get you one of these devices if you think it could help.
> 
> We should definitely consider targeting a build of Shark Bait for the PinePhone.
> 
> 
> On July 24, 2020 11:02:57 AM EDT, Gunwant Jain <therealgunwant@gmail.com> wrote:
> >On 20/07/24 10:08PM, Benda Xu wrote:
> >> Gunwant Jain <therealgunwant@gmail.com> writes:
> >> 
> >> > This week, I started managing the structure for the modified
> >LineageOS
> >> > fork we would keep. Namely the modified `repo-manifest` [1] and
> >> > `llvm_android` [2], for now. No patches have been applied to them
> >yet
> >> > for the reasons discussed below.
> >> >
> >> > My plan for this week was to start with patching the `llvm_android`
> >> > build scripts. Android uses a prebuilt Clang (bundled with the
> >repo)
> >> > among other stuff to build the toolchain. So I had to emerge Clang
> >on my
> >> > phone.
> >> > Emerging Clang turned out not to be a breeze when I have a phone
> >with 3
> >> > gigs of RAM. So for about the longest time, I was busy trying to
> >make up
> >> > for it. I tried setting up distcc, increased swap/zram, but still
> >the
> >> > OOM killer got me.
> >> > Later last night(/day), I came across the tips for building
> >clang/gcc in
> >> > an embedded Android environment at [3]. So I followed that and as
> >of
> >> > now, me writing the mail, OOM has not got me, Clang is emerging.
> >> 
> >> Did it finally go through?
> >
> >Yes it did.
> >I can also report that llvm_android's stage1 clang is compiled for
> >aarch64, I am on the stage2 step currently.
> >
> >
> >Regards,
> >Gunwant
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.