VoLTE Implementation For Google Pixel 3a/3a XL

atarilinux

Thanks so much for the info and for building the port! My main Linux computer doesn't have enough power to run those specs natively unfortunately, but I can check what solutions I have. The virtual machine option would probably be the most promising thing for me rather than trying to run it on my local machine. I'll keep you posted as I work through it. Thanks again!

mr_growl

@atarilinux Ya, my first build was on a very low spec machine. It can be done but is not fun

I'm taking a page out of what you said earlier and am going on a mission to try to understand the process a bit more. I'm starting with building lineage os 19.1. The instructions seem pretty straight forward so seems like a good place to start.

Documenting the steps I ran to get a working lineage 19.1 bonito build on ubuntu server 22.04 here:
https://gitlab.com/mr-growl/ubports-ubuntu-touch-google-bonito-volte/-/wikis/Building-Lineage-19.1-for-Bonito

This is being run on a system with < 8GB ram, so included steps to make a big swapfile at the top. VM specs are 2 i5 cores, 240GB disk, 7GB ram, 24GB swapfile

atarilinux

@mr_growl

Yeah, max RAM I have is 16GB, but on an ARM based computer. With this one, I would have to virtualize x64 which would have a knock on performance. The main x64 Linux computer has 8GB. Not ideal. Let's just say I have been on the market for a better computer for a while. Hahaha

Let me see what I can work out. Thanks for the steps and the build!

atarilinux

@mr_growl

Looks like I got something running in a virtual machine, but it is very, very slow probably due to the instruction translations to the ARM processor among other factors. Needless to say, it can run, but it will take forever under these specs if it doesn't crash. I've been eyeing a desktop PC for a while. I might have to take the plunge when the means become available. If I can't get this to work on my hardware, I will let you know.

mr_growl

@atarilinux Memories of building linux kernel in the 90s

The lineage build is taking me a lot more time to build than the ubports one but I'm still plodding along on that for now. I'm hoping the lineage build will be an enlightening endeavour

One part about the ubports build that I'm unsure about is the vendor blobs. With the lineage build I extraced the blobs from my phone and added them into the source but I haven't noticed a step like that for the ubports build.

atarilinux

@mr_growl

Hahaha It definitely feels like the 90s! I better get some techno or grunge playing while I'm working on this. Hahaha

Yes, when comparing different alternative OS builds, I noticed the same thing. I got stuck on where exactly these should go as I didn't notice anything similar in the Ubuntu Touch documentation. That led me back to trying to trace the original port and other ports to see what happens where and where these vendor blobs should go. Also, I don't know the last time the documentation has been reviewed and updated. For example, I still see the Nexus being referenced and that is from 16.04. I'm not sure how much has changed since then on the porting side. Also, there may be some things that could be left out either by accident or "like, of course, you should know you have to do XYZ, why do I need to write that?" which may confuse the new or average user. This is not a problem limited to just Ubuntu Touch. Other systems have similar omissions in their documentation sometimes. Overall, the documentation so far is great, but I do notice there are some places where I'm having questions, and it sounds like it is not just me. Maybe reading additional material is confusing me? I'm not sure. Anyway, I'll see what I can find out, and if I notice anything, I'll post it here.

atarilinux

@mr_growl

I did find this in the forum as a Port QA Checklist. Still looking into the vendor blobs.

https://gitlab.com/ubports/community-ports/general/-/blob/master/DeviceChecklist.md

mr_growl

@atarilinux I've just finished and flashed my own build of lineage 19.1... for comparison, the ubports build takes me about 1 hour... the lineage build took closer to 20 hours on the same machine... so I really feel like something might be missing

That said, it may be that the lineage build is building everything where as the ubports build is downloading the GSI rootfs and such... I dunno... still learning.

I think my next step is to follow the halium documentation and correlate that with the Droidian porting documentation. I do have a suspicious about where and when the blobs might need to be added but just need to go over everything again and let it sink in a bit. Anything I discover I'll document on the wiki for the repo I'm working in on gitlab and will link to here.

mr_growl

@atarilinux Also worth mentioning for your setup... in the Droidian porting guide is mentions:

this guide assumes that you're going to cross-compile an arm64 Android kernel on an x86_64 (amd64) machine using the Android-supplied precompiled toolchain that's available in the Droidian repositories. It's trivial to disable cross-compiling and compiling using the standard Debian toolchain.

which says to me that you can compile it on your arm64 machine without having to use any x86 stuff.

atarilinux

@mr_growl

That's a huge time difference! I likewise feel like something is missing. Perhaps looking back at the original Pixel 3a/3aXL Ubuntu Touch 20.04 port could shed some light too. I'm assuming that these should have relatively the same file "structures." A vendor blob should be in there somewhere I'd imagine.

atarilinux

@mr_growl

Good to know! It is a Mac for whatever that's worth. At the time, I wanted to try something different, and now, I'm missing Linux every time. Hahaha

atarilinux

@mr_growl

I found some clarification on vendor blobs from this forum post. Perhaps we can glean something from here.

https://forums.ubports.com/topic/9392/xiaomi-redmi-note-12

mr_growl

@atarilinux I've made some progress, I think. I successfully built halium 12 for bonito and I now have the ubports recovery booting.

I flashed the system.img from the halium build, then formatted the data partition as ext4 and then sideloaded a droidian rootfs on to it but it just came back to recovery. The end of the log file is filled with messages like:

ueventd: Cannot get SELinux label on '/dev/block/mmcblk0p29' device: No data available

So I think it's time to start debugging. Will save that for another time.

I documented the steps for building halium 12 for bonito here:
Building-halium-12-for-bonito

atarilinux

@mr_growl

That's great news! Fantastic progress indeed! I think we will continue building off this port.

I think I've seen a message about SELinux before during my research. Let me see what I can find out on that error message.

atarilinux

Some info on ueventd and SE Linux Labels:

https://android.googlesource.com/platform/system/core/+/master/init/README.ueventd.md

https://source.android.com/docs/security/features/selinux/device-policy#label_new_services_and_address_denials

Two Additional Troubleshooting steps:

Look at the partitions to see how they are set up
Check out boot arguments and the kernel

I also found this which may or may not be helpful.

https://stackoverflow.com/questions/55163930/label-files-on-rootfs-ramdisk-with-selinux-context

JayH

@mr_growl

Granted, I'm not keeping completely current but I didn't think halium was the current/accepted/approved/supported/??? method of porting any more? I thought it was all being compiled into the kernel and done?

Anyway, kudos! I appreciate your efforts and am keeping an eye on this project as I'd like to be using that old Pixel3aXL I have lying around rather than the knoxed Galaxy I keep falling back to.

Fuseteam

@JayH said in VoLTE Implementation For Google Pixel 3a/3a XL:

Granted, I'm not keeping completely current but I didn't think halium was the current/accepted/approved/supported/??? method of porting any more? I thought it was all being compiled into the kernel and done?

fwiw Halium is still used, It is just that it is no longer needed to build halium itself

mr_growl

@atarilinux I suspect it's because I skipped the step in the documentation about setting up the fixup-mountpoints script. I could not find that script anywhere so skipped it just to try to get something booting.

Here's the part I'm talking about:

Include your device in fixup-mountpoints

Fixup-mountpoints replaces the aliases of block device nodes in /dev/block/by-name with their literal nodes under /dev/block. This prevents issues caused by by-name not being populated by systemd.

First check if the codename of your device is already included in the <BUILDDIR>/halium/hybris-boot/fixup-mountpoints script.

If it’s not already included, you will need to add it. Your device should be running LineageOS or another ROM where you can get root access over ADB.

    Find the fstab file for your device. For my Moto G5 Plus, this was fstab.qcom in device/motorola/potter/rootdir/etc

    Enable adb root access

    Create the skeleton for your device in fixup-mountpoints, right before the *):

    "[codename]")
        sed -i \
            [replacements, one per line]
            "$@"
        ;;

    For every line in fstab where the type is not auto, emmc or swap, run readlink -f [src] on the target device over ADB. [src] is the leftmost colum in fstab.

    Write all of our replacements, one for every mountpoint. Here’s the bones of one:

    -e 's [src] [return] ' \

Replace [src] with what you input into readlink and [return] with what it returns. The space after [return] is important. The build fails without it.

I don't have that in the location they mention. I found a fixup-mountpoints script in another project but I don't know that it'll actually be run if I put it in that location as that location doesn't currently exist.

So that's what I'm investigating currently.

mr_growl

I tried the halium-install script, too, with a ubports rootfs tarball but it stalled while pushing the system.img over adb (stopped at 5% and stayed there).

atarilinux

@mr_growl

That makes sense, and it does seem like that's the error. The good news is that it booted to recovery! Let me know if there is anything you need me to look at or research. I'll try my best to assist in any way that I can!