Okay, so good afternoon everyone, my name is Abelete and I am the owner of a company called
Mithene, I have an embedded Linux engineer, I provide services for our clients and today
I'm going to talk about how I updated a few pixel phones to Android 16.
So don't get hang up too much on the versions on the slide, this is mostly for tickbait for the
internet.
So do we have an appellate sense problem in the consumer smart phone industry?
The short answer to that is yes, we do have recently, OEMs, I've been providing five
years of software update and more for the key players, but that was up until now generally around two
years.
And what happens when that turns ends, what happens is that your device is no longer supported,
which means you no longer receive major OS upgrades, and this expose you to security issues
and lack of feature improvements.
So you are no longer receiving updates that are shipped built into the OS itself.
I'm not talking about features that are delivered through application updates.
Thanks to supply and demand dynamics, there have been a rise in companies providing business
to business, alternative update channels to other companies, obviously.
And case in point, last year at first then there was a company called Interior that was
such a case.
So if you haven't seen that talk, I encourage you to go ahead and see that.
But what about you and me, individual users?
What can we do when we end up with devices that are no longer supported?
Is this a case for the custom ROM community?
And first, I would like to define what is an Android customer.
So we can compare custom ROMs to Linux distribution.
If I take the case of, for instance, lineage OS, which is one of the key custom ROM,
they can be compared to, so I would say that lineage is to Android what they then is to Linux.
So basically, they are doing most of the platform work upon which other custom ROMs are relying
to provide the reveals of Android.
So those, these projects are providing the reveals of Android.
And they give users the choice to run with or without Google Apps, depending on what you need to do with our device.
One other thing to note before being able to use an alternative system image is to make sure that your device and search your OEM allows it.
So the device needs to have a bootloader kit that can be replaceable.
That means that you need to be able, when you choose to do so, to unlock your bootloader.
Some manufacturer nowadays still does not allow that.
And some of them are backtracking on that authorization.
So some of them were allowing it up to now.
And they are reversing course because of economic incentives.
Also, you need to have access to some key software components.
You need to have access to the sources to the Linux kernel, because Android is big on the Linux kernel.
And you need to have access to the sources of the BSP for your device.
So all the sources to the drivers and specific components that needs to be built into your device in order to ensure that the peripherals can work as expected.
One thing to note is that Google has speedheaded project travel.
I think it's almost a decade now that has significantly improved the situation by unifying the bills of the Linux kernel for Android.
So it has improved the situation for us.
So how do we deal Android for commercial smartphones after the end of live support for these devices?
One thing you need to know is that the sources in Android for device are usually speeds in what we call trees.
So we have the device tree.
This is different from the semantic of device tree in the Linux kernel.
The device tree in Android is a set of configuration files that are needed to make sure that your specific device is configured for the build you are doing.
So you can have multiple device relying on the same board, on the same base, how to platform.
But there are different because they don't have the same IOs and the same territory for us.
So the device tree will take care for different configuration.
Then you have the Dendertree.
Those are generally binary blogs and include source files that are needed to ensure that the hardware still function correctly.
Typically, a camera hardware relies on vendor blogs.
And the way to get those is either to extract them from the original stock image files.
So within the community we have strips doing that nowadays.
It's easier.
Or if you're not a developer and not a kid to do that kind of work, you can search online for repository that already provide those kind of trees.
Almost finally you have the kernel tree.
So Android is based on the Linux kernel and you need to be able to read the kernel for your device to get a complete system image.
And depending on the device, you can also have extractories.
For instance, Samsung is known to have multiple extractories because they provide additional features that other manufacturers do not provide.
And also for instance, Google may release for a specific year, a single year, multiple devices that share a common code base.
So there will have some of that code base in separate trees, separating the common code base from the specifics of the device.
So in that case, you also need extra trees in your in your build.
Everything else apart from the device with the Vendertree and the kernel tree and those extra trees is a common code base for the Android custom ROM that you are building.
So it could be considered as the basis of the distribution.
So how did I end up choosing evolution X and for what device?
Short answer to that question is that I chose evolution X because I considered it to be one of the best custom ROM around.
I'm going to make enemies here, I think.
But it's true. And the reason why I did it for the pixel for a is that it is the device I had at hand at the time.
It was my daily device. And it started because two reasons.
The first was that I bought it at the time of release and I used it until it reached end of life support.
So that was around Android 13.
I was wondering if I was going to buy a new device.
I didn't want to because I very much liked that device.
It was small and it got features that you cannot see nowadays in the device with that form factor.
Have fun, jack, a reliable thing, a thing scanner.
And what triggered me is that one year after the end of the support, Google issued what you may recon as the battery killer update.
So basically one year after the end of support, they issued a mandatory software update.
So you cannot choose to apply or not to apply it.
And it was to mitigate a so-called issue about overheating battery.
I was not in that case. My battery was functioning perfectly fine. My device was fine.
And after receiving that update, I realized that my battery capacity was cut in half.
So I was based and I started looking into an alternative system image to continue using my device.
And the reason why I ended up using evolution X.
One thing to note is that most of the custom ROM are based on lineage OS.
As I said, they provide the tremendous work on the platform level for every mostly every other custom ROM to use.
The reason why I didn't choose lineage was that I was already relying on the Google ecosystem.
And I wanted to be able to get updates easily, not having to fiddle with installing the Google app separately.
And also by the time I started this experiment, the official mentor for the Pixel for a attribution X left.
So I need to be able to read the image for myself.
And this project provides very good documentation, which is very rare for developers to do so.
We like writing good. We don't like writing the documentation. They have very good documentation.
Could as to the team doing that.
So my learning curve was facilitated by the fact that they have a strong and helpful community.
People are very nice over there. And I started by first rebuilding the last known official release, which was 9.2.
So this was the one based on Android 14.
So they started before that, before the end of life, then they continue upon Android 14.
So I picked up from there. I successfully rebuilt it.
And I tried to keep up with the monthly security update because it mattered to me at the time.
And then I got hooked and tried to jump to one major release to another.
So let's see in more details how to do that.
So basically, what you need to know about Android is that the sources are managed by your tool called repo.
So repo is a superset on top of git.
So it managed multiple repositories at once where git only managed one repository at once.
So when you use repo, you need to first declare a manifest.
The manifest is a file, a next and a file that defines where from where you are going to fetch all your sources.
So as you can see, I'm declaring here the sources for my device tree, my inventory, my kernel tree.
And you realize that I'm fetching most of the sources from lineage as they are providing the platform work, right?
So who does for to do this job? Because it's a tremendous amount of work.
And it's not easy to keep up with the pace at which Google is releasing this update.
So once you have a working manifest file, you basically fetch all the sources with the command repo.
I'm not putting the complete command here because it doesn't matter.
You just need to know that repo repository with a specific set of arguments.
And it catches all the sources for you.
If you are, if you want to do this at truth by yourself, I encourage you to go to the week in the documentation of the project you are interested in.
And that's the specific arguments.
After fetching the sources, you need to configure the build.
And also this is taken care of by the name of the manifest.
So for my device, the specific common is lunch, lineage, some fish, which is the code name for the picture for A, AP2A, which is the code name for the release.
So AP2A is the code name for Android 14.
And then I'm doing a user debug deal here.
Then you start compiling with the command and evolution.
It basically started the build.
After which you wait.
And you wait some more.
There was a talk yesterday about why Android deals are so slow.
And there are, there are indeed very, very slow.
A typical build on my dedicated mission.
So not this laptop, but I have a dedicated build machine, which is an ND,
Reson 7 machine.
So it's not that all of a CPU.
I have 128 GB of RAM and all SSDs.
And it still takes me two hours and a half to complete a build from start to finish, which is a very long time.
To do a bit.
And this is, in the case where I only do one build at the time.
If I run multiple builds, that time gets up.
And the good side is that rebuilds are usually faster.
So they take 45 minutes to, I don't know, from 30 minutes to 45 minutes, in my case, unless it tears.
And when you are starting with that this kind of endeavor, it usually fails.
We are going to see why, what kind of issues you can face when you are starting to rebuild your own system image.
So this is the kind of issue I faced quite regularly from one release to another.
It is an issue with what is called in a USB in Android, the framework compatibility metrics.
Basically, those are external files that define which version of what software component you need to build into your system image to make use of your hardware.
It is a way for vendors to use multiple boards for a same family of hardware by doing different system deals.
So you want to do a build for the same family of boards, but with different iOS.
So the difference will be in the configuration of the software you are using.
And this is done in those FCN.
Basically here, it says that the device manifest does not follow the framework compatibility metrics.
So this is one of the issues.
Another one, which is less frequent, but it can happen, is failure to build the Linux kernel.
In this case, I ended up summing upon an issue where there was a breakage in the Linux UAPI.
So the user API of the kernel.
There was a specific type called structs.
That was defined in the user space API, which was also defined by the GVPC.
So we have two definitions by two different components.
So I needed to do a local definition of that type in my kernel.
And hopefully for me, this issue is already known, upstream.
It was fixed in the Linux kernel upstream.
But the picture for A is using kernel for the 14, which is quite old.
So at that time, the issue was not fixed.
So what I did instead of reinventing the wheel was I terri-picked the patch that was sent upstream to fix in the Linux kernel.
And lastly, another type of issue I important.
But this happens to me only once, which is a breakage of API.
This is quite rare.
What happened is that I have a software component written in C++, open source, which was pulling a library.
I didn't know of for the Wi-Fi direct functionality.
So this is related to casting in Android.
And when pulling that library in and linking to the library, it was missing a symbol.
That was not defined in the binary blob I was linking against.
Hopefully for me, it was written in C++ and open source.
So I just had to do a week definition in C++ of the missing library to fix the issue.
I don't know what I would have done if it was close source or not C++.
But I see how my finger crossed that this does not break.
And it's a significant feature in the future product device.
So it was a successful experiment.
I was able to read the Android 14.
And I took it upon myself to do the jump to Android 15, which was already at the time.
The version the maintainers were working on.
And then the jump to Android 16 using the same process.
I got hooked because I was able to get a very old hardware.
Very old according to the industry hardware.
And that very up to the software on it.
I had the Pixel for FID and Pixel 5 also in my cabinet.
Those are small phones and old devices.
So I did the same for those devices that are also abandoned on Android 13 or maybe 14.
Because I realized that there are people that are still using those devices.
I became maintainer at Evolution X.
And I was able to add my three devices to their processor.
And I think we have, after lineage, one of the biggest roaster of devices.
So I really think we have one of the best custom ROM after them.
One of the benefits for me joining as an official maintainer was to rely on the project CICD
Continuous Integration and Continuous Delivery Infrastructure.
So on a set of servers and infrastructure to have some kind of automated build pipeline.
Because having worked in the industry,
I know that there are companies that have not that kind of level of CICD infrastructure.
And having this allows us to provide OTA updates,
which means users can get updates over the air,
but without having to refresh their device every time.
This is a huge win.
And it means that we are at the level of OEMs.
And we're doing this basically for free.
This is huge.
And I also was surprised that there are quite a significant numbers of people that are interesting in still using their phone.
They don't want to follow the trend and just buy new devices just because the market says so.
And it is important for us to be able to keep this trend alive.
So what next?
I will personally strive for more monthly safety updates.
So right now I try to update my device at least once a month to provide security updates for my users.
And because I also use evolution X on the daily basis, my personal phone, personal and work phone.
So this is important to me.
And I also strive to do major OS upgrades.
So I went from 14 to 15 to 15 to 16.
And hopefully I will be able to do the jump from 16 to 17.
Hopefully.
But we need to keep in mind that Google is changing the name of the game.
So starting from 20 to 26, the announced that they will only do the code drop of the open source Android project twice a year instead of doing continuous release before.
So we are only going to get the the code drop in Q2 and Q4 of each year, which means we have we will get more what to do every year.
If they keep with the promises.
Finally, I would like to encourage you to contribute to project as users or as developers because our community is based on the fact that we need to keep contributing to open source software.
Without contribution to open source software, this kind of project cannot happen.
So evolution X rely on contributions and lineage OS rely on contribution.
So whatever you can do provided documentation, help testing or anything, please do so as long as you can and as much as you can.
Thank you very much.
That's it for me.
If you have questions, now will the point.
So I have a phone of 2014, I think.
Okay.
Problem going to update tomorrow.
And I thank you all incredibly for this for this project, I think it's amazing.
Something that I miss sometimes because I often handle these old phones are the kind of really shady structure out on look to bootloader.
It just like has the vendor for a specific code and then do this and this and this and this.
And this kind of stop me sometimes because I don't want to install a frame software.
I have some insights or something under the documentation for for this kind of cases that will allow more people to install custom ROMs.
Okay.
So the question is regarding to the status of bootloader when it is unlocked on devices.
Do we have a way to facilitate the installation of custom ROMs in the communication between our laptops and devices to do that kind of work?
So nowadays we basically rely on ADD and fast-world to write software to automate that process.
And there are two major custom ROMs graph in and colleagues who are providing web UI based in solution to us to automate this process.
So it's easy for people using this custom ROM to install it.
We still don't have it at evolution X but this would be a way to facilitate installation.
But keep in mind that if you choose a custom ROM that provides OT updates and you are following the official releases,
the hurdle you have to overcome it only once the first time after that you have OT updates.
So this is also a solution.
So yes, it's not easy but it can be done.
Thank you very much.