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!