Validation, fixing, commiting, repeat.

Context

I have a old phone an Motorola G9 Plus it runs with the Qualcomm SM6150 chipset, there is other phones with it but non Motorola were mainteined. Thats when I decided that the current AI tools likelly I could update the Kernel (with Backports, a term I didn’t know until I started working in this project).

A bunch of updates were made, and we had made the device boot into the “Welcome, to LineageOS”, except the touch didn’t work and still needs to flash the partition table in order to work…

Fixing and Testing

This and the next post(s) will be just Testing, maybe fixing like, the touchscreen, them the Wi-Fi, Bluetooth (that one also fixed the Fingerprint).

I (and the AI agents) had to fix a bunch of things, the GPS took some time like the Wi-Fi Hotspot.

Right now, I am trying to validate all paths and attributes, it needs to fit the LineageOS Device Support Requirements, also working in adding it to Wiki in parallel

Play Integrity and Root

After the sucessful install, and a good enough state, I reinstalled from scratch and added Magisk (root) and MindTheGapps (Play Store for Custom ROM). They both worked.

The tricky part was the Play Integrity, I read multiple articles on how to do it, but it came down to Installing the PlayIntegrityFix, ReZygisk (I could have used the native from Magisk but the tutorial said to use it), and Trick Store (+ an addon). And now it works fine.

Complying with the LineageOS AI Coding Assitants

Well, when I started the project, I didn’t read the fine-print so I needed to make ALL of my Commits (yeah this shit started REALLY vibecoded, I kinda thinked it wouldn’t work, right now I know WAY more than previously) comply with the guide, so which harness and which model did what.

I made a OpenCode thread with gpt-5.6-luna to check my ccusage and assign each commit to there creator, and I realized, I used WAY too many models (gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, kimi-k3, opus-5, MiniMax-M3), but they got the job done and this is almost finished…

“Built it, flashed it, bootlooped.” WAIT NO????

Context

Well, I like to thinker with shit, and recently I’ve come more used to AI Tools and how good they actually became at coding.

So I said, why not extend the previusly extend life of an Android Device by vibecoding the shit out of previous incomplete projects of a Motorola SM6150 kernel and make it work?

In the past we had a bunch of bootloops, kernel problems, incomplete API surfaces, almost bricking the device 6x times in a row. And much more (read past devlogs)

Faster Bootloops

Well, in Software Engineering the anwser always may be WAY more simple than it looks. In the case of the “flash” of the Motorola Logo (fast bootloop), it had something to do with in how the OTA package messes with the partition table. In those cases the anwser was just to do flash the Stock Partition table of the device (fastboot flash partition), and it would just boot.

This happened WAY too many times, so in the (spoiler: end of the post) that was just randomly fixed.

Boot stall?

After way too many back and forths with GPT, a new OpenCode config (abusing the heck out of GPT-5.6-Luna in Max Reasoning as a subagent) we had a phone that didn’t bootloop! (YAH!)

But… It didn’t do anything. We were only meet with a Motorola Logo for a LONG time. (I called it Boot Stuck but GPT said its actually called a Stall, like the thing with manual transmition cars)

LineageOS Boot Animation?

Like the past chapter, with a bunch of back and forths (and 14 tries) I was meet with three dots circling (and that felt REALLYY GOOD).
After a litle more it was the LineageOS Logo Animation, then the dots again, then it repeated… Looking through GPT logs, it was actually the GPU driver that was kinda broken, it fixed it!

WAIT, “WELCOME TO LINEAGEOS!” WTF!!!!!

In the TRY number 18, didn’t need to flash the partition table once more (that was strange), animation logo, LineageOS logo and, the “Welcome to LineageOS!” text.

I was astonished, the first step to having the phone, Android 16 and almost brand new.

The thing is… Touch of the screen didn’t work… So we need to work on that. Plus all the commits and changes.

Sleep, laziness, and vibecoding a dangerous mix.

Context

This project is my try on making a old phone a Motorola G9 Plus have the latest Android (16 because 17 is not yet released by LineageOS). In the past had bootloop problems, phone wipes problems, almost bricking it a few thousand times.

In some AI session (likely Claude) a try to fix the bootloop, created a faster bootloop. And since me and Claude, GPT and Kimi been trying to choose a path forward.

Kernel Update

In the last devlog, I said about possible paths forward to fix the BPF (Berkeley Packet Filter), and the easiest solution is to try using OpenEL Assosiation (openela) 4.14.x kernel.

Its going to be easier, plus the backport of the BPF would be painful but it has been done in the past, so I would likely succeed!

Faster Bootloops

I’ve spent all this devlog time, trying to find the culprit and the veridict is… I don’t know, I’ve speding my time looking back at Claude Sessions and I found that it had messed with zygote in one of its tries to fix the bootloop of ~20-30 seconds, and it made it bootloop faster, so…

It also could be other things but the Zygote angles was likely. I’ve researched the whole project, and I couldn’t find anything tracking his changes, so I guess it had messed somewhere deep into the repo, and we couldn’t figure out where.

Next Steps

I’ve decided to delete the whole lineageos directory, and start from “scratch”. Of course I would use the repos in my Github, but at least, I would be in a more stable directory.

I will also do a small rewrite (third time is a charm) to AGENTS.md, with the instruction “tell me all the places where you messed, and use YOUR FUCKING NATIVE TOOLS TO EDIT NOT BASH MTF”.

Linux Kernel sucks for Android Devices

Context

This project is my try on making a old phone a Motorola G9 Plus have the latest Android (16 because 17 is not yet released by LineageOS). In the past had bootloop problems, phone wipes problems, almost bricking it a few thousand times.

Semi-Bricking fix

Opus 5, fixed this problem really easily it realized that the Motorola Bootloader Menu (MBM) didn’t like LineageOS standart bootctrl, so it built one by itself!

Another bootloop problem!

After the fix, we tried the OS for the first time and it was AWESOME! It restarted the phone, the Bootloader Unlocked Warning appered (good sign that the OS exists), them I got stuck on the Motorola Logo for ~20-30 seconds and it bootlooped…

That wasn’t a good thing but it meant that the “Semi-Bricking” was fixed and now we had some Kernel problem again…

Bootloop fix (8x tries…)

I just smashed Opus 5, GPT-5.6-Sol, and Kimi K3 (which Weights became avaliable today!) at the problem and they all got stuck trying to make the Logger work.

In so many words and tokens they tried ALL kinds of loggers, and after ~2 days of trying to make some kind of logger work, they found that the problem…

Culprit

It was the “kernel 4.14 vs Android 16 BPF”, which means that the Android 16 requires a newer kernel in order to have a more up-to-date BPF (Berkeley Packet Filter, aka a Subsystem that allows User code to be ran at the Kernel Level) to work.

Possible paths forward

1. Try to use OpenEL Assosiation (openela) Kernel LTS, which has a longer support for the 4.14.x kernel (which had the official End-Of-Life at January 2024, with an extension to December 2024)
2. Vibecode the shit out of the kernel to try to update to the 5.10.x LTS (which has End-Of-Life December of 2026) or a newer version like 6.1 LTS, 6.6 LTS, 6.12 LTS, 6.18 LTS.
3. Give up…

Well, what I am going to do is likely the 2nd option. But I need to find out if is going to be 5.10, or one of the 6.x versions. I am going to start with what other developers at LineageOS did. Its likely the best option

How to not brick your phone 6x times in a row!

Context

This project has the objective of making an old device. A Motorola G9 Plus (codename: odessa) have a new life with Android 16 and the latest 4.14.x kernel.
In the last post I said about how GPT-5.6-Sol, helped me fix a USB device first-try.

Kernel Update

Well, after the fix to 4.14.282 was done we proceed to to 4.14.283 it bootlooped, so after giving the task to GPT it fixed and we were done!

With 4.14.283 fixed, I went to another midpoint this time was 4.14.310 and it also worked flawlessly! So we just merged 4.14.336 and also done!

Applying the OTA update!

Well, I did some of the clean-up to the OS and proceeded to appling the update, it didn’t work. The dumbass here didn’t read that the recovery warning that was an version older than the kernel itself.

Well after rebuilding and choosing the right one, I got an Installation Error with code 5. After giving AI a few more jobs to run it fixed it.

Almost bricking the device

After the AI fixing the Install error code 5 the install proceed as inteded and a popup appered saying something like “Reboot the device to proceed or to install addons” (addons can be Magisk/Root or Google Play Store).

Well after restart a red text appered screaming “NO VALID OPERATING SYSTEM FOUND”. And after going back to the bootloader the device was in a semi-bricked state, without being able to flash a Recovery or anything.

The GPT suggested using Motorola Software Fix tool to bring the device back to Android 11 and removing the bricked state. After trying the tool it basicly said “Well your device is now a paper-weight, if you want ship it to Motorola and they might be able to fix”.

Hopeless and at 01:00 AM I started googling and found a tool from a fellow developer called Gorniaky (I knew him from my Discord Bot days, really smart folk) called Flashfile-XML-to-Batch-Script-for-Windows and after converting the stollen previuous stock ROM files I was able to make then in a bash script that was able to restore the phone Partion Table and everything back to there to the stock ROM days.

Next steps

Well, I tried again making GPT work to fix the OS installation nuking problem but it didn’t work, my limits ran-out, my friend didn’t wanna give up his for mine so I bought the OpenCode Go and tried the newly release Kimi K3 model, pretty good one, that was heavly distilled by Fable.

Well, it didn’t work so well, it made a 200k+ tokens chat and ran out of my 5-hour limit. Next day I woke up and tried the “Hey, you kinda went too strong on my limits, what that hell did you did so far?” and it had fixed my problems.

Semi-Bricking the device once again (5x times)

Well, we came to the vicious cycle (the image, that is not mine, will haunt me for days…) for nuking everything and fixing it afterwards. The latest news are it is broken, I got my friend to give me access to his Claude Pro account and test Opus 5 and its currently working heavlly to fix this problem.

I love gpt-5.6-sol….

Well, if you caught off guard, let me tell about this project. I have a old phone a Motorola G9 Plus (codename: odessa) and in the last year I found a custom ROM to it which made it more up-to-date and faster. The problem is it was an unofficial build because the phone is not widely avaliable (only sold in Latin America with most of them in Brazil) so it didn’t get any updates.

Well, thats when I realized that we have heavly capable AI models that likely will be able to scrape from incomplete work and make this phone up-to-date again. Currently we are trying to update the android kernel (its linux but a bit different) to the latest 4.14 LTS (its already discontinued) for support on Android 16 (without any shortcuts), but just jumping from 4.14.190 to 4.14.336 its a big-leap and one that bootlooped the phone.

We tried multiple things and we came down to find a midpoint where things start to break more, and we find that is between 4.14.283–4.14.286, and while trying 4.14.282 we found that the ADB (a developer tool that allows to push a OTA build, applications, etc) wasn’t working.

I tried multiple times with gpt-5.6-terra (a cheaper version to the sol variant) to fix this USB problem but it couldn’t. So after 4 tries, I tried again with sol and it did it first try!

Sup nerds,
just finished inbound.rs with the structs based on schema.ts.
Took a while because @megarthur vibecoded the api first, i told him this implementation sucks, can you refactor it, and he ended up doing a much better job. i had already written the structs for the old version so i had to scrap all of it and wait for the refactor to land.
scaffolded a few crates along the way to keep things organized.

P.S: we set some rules on ai usage, it’s only allowed on the typescript side, not on the rust side, and only for searching docs and pulling examples.

Previously: Create an initial interface using Tanstack Start + ShadCN, then create a Node Auth and Node Jobs logic for the node system (basically the bare-metals connected to the system).

Update: @Gabriel-Hiss started coding the rust part of receiving the Job, turns out that the vibecoding I did sucked, so I refactored both the Authentication and Job, became really better!

Well, I am trying to figure it out why the kernel is crashing (aka: my phone is bootlooping before entering the recovery menu).

With some help of the AI agent, it figure it out that his attempt on jumping the kernel version from 4.14.170 to 4.14.336 wasn’t actually the best one. So right now where are creating midpoints to figure it out when it stops working.

Currently we are at 4.14.282 with the problem in between 4.14.283–4.14.286.

I have been using the agent to do it but there is only so much a AI Plan can give you in limits, so I might need to start figuring out how to do the whole merge process by myself. (I hate git cli…)

My working theory is that some of the basis I gave it to work such as sm7150-mainline, and the abandoned sm6150 kernel in the lineageos org, is actually starting to backfire because its really old and incomplete work. Also the problem might not be in a single version but in multiple of them.

Next dev-log will have more info.

Well, this is just a post to log the current hours.

On the previous days I got to build the “target-files-package” (basicly a ZIP with the data of LineageOS that is given to the recovery). A lot of errors occurred during building.

Since, I don’t know how to code in C, I always gave the problems to the AI Agent. But the build times was always too long, and everytime I got to a error, I got to rewait the whole thing.

Thats when @Gabriel-Hiss said to me “use sccache rather than ccache, that the LineageOS Wiki gives you”. I changed, build times were 100x faster.

After some back and fourths with the agents and a bunch of local testing, the AI said “well, now its time to try it”. So I went to the recovery (its not the LineageOS recovery, was from a previous unofficial public build for tequilaOS) put the LineageOS files (plus addons), and booted, and boot-looped and now I am back at tequilaOS…

Follow up for more!