On this week's episode, we discuss how to overcome some of the challenges in building your own image of Android to use on any device, particularly where security is a concern. We're excited to be joined by one of the developers behind one such project that's made headlines recently, Gabriel of GrapheneOS.

• 01:02 - Are we talking about custom ROMs?
• 02:51 - What does GrapheneOS do that AOSP doesn't?
• 12:04 - Why can't I install a custom OS on my existing Android device?
• 19:15 - How can I get apps to work on my custom Android-based OS?
• 28:26 - Why are Android update guarantees still so lackluster?

You can learn more about GrapheneOS at grapheneos.org, and you can try it out on your Pixel device with their easy-to-use web installer.

Android Bytes is hosted by Mishaal Rahman, Senior Technical Editor, and David Ruddock, Editor in Chief, of Esper.

• Mishaal's Twitter
• David's Twitter

Esper enables next-gen device management for company-owned and managed tablets, kiosks, smart phones, IoT edge devices, and more.

For more about Esper:

• Esper Blog
• Mobile Device Management (MDM) Guide
• Android MDM Guide
• iOS MDM Guide
• MDM Solutions
• MDM APIs & SDK

New from the Esper blog:

• Edge AI
• Edge devices & edge computing

Our music is "19" by HOME and is licensed under CC BY 3.0.

Hello everyone.

And welcome to another episode of the Android bites podcast powered

by Esper I'm David Ruddock.

And every week I'm joined by my cohost Mishaal Rahman to explore

the wide world of Android and a lot of topics in the Android universe.

You probably wouldn't ordinarily see discussed this week.

We've got a very special guest.

And with that, I'll let Michelle introduce him.

Thanks David.

So this week I'd like to talk about graphing and S so if you are at all

security or privacy minded, you may have heard of this project before it's

been brought up by some very influential members of the InfoSec community as one

of the preferred alternative Android based operating systems for devices that

you can install that, people that are more secure and more private things.

AOSP and joining us today, we have one of the developers who

works on the project full time.

Gabe from graphene O S welcome to the show either.

I'm very happy to join you guys today.

hopefully we can get into the nitty-gritty details of graphing.

Yeah, definitely.

before we actually dive into those details, I really wanted

to clarify one thing with you.

So you've probably are very familiar with the term custom wrong.

It's a term that the vast majority of people use to refer to

Android based operating systems.

Aren't offered by Google or OEMs.

there are projects like lineage iOS, which is one of the most popular ones that's

referred to as a custom rom, there are many other projects that are referred to

as custom ROMs, but I wanted to know, what do you think of this term is graphene S

something we should call a custom rom or is there a better term we should be using?

I personally don't really consider it to make much sense.

my rationale for that being that.

The operating system isn't installed to rom chip anymore.

And mobile phones, maybe you have the exception of some older

feature phones don't really use a wrong for their operating system.

And the only real rom that's present on a modern smartphone is going to be

the boot rom, which is highly amenable and just starts the boot chain.

And I would describe craftiness and any other derivative of AOSP as operating

systems, because, that is what the.

Yeah.

And also , in my view, custom rom as a connotation of being like a

hobbyist project that you would download off the XDA forums, just to,

try out some new features or tweak the user interface, or maybe extend

the longevity of your old device.

It has that hobbyist, indie developer connotation associated

with it, in my opinion, at least.

And it feels like graphing.

This is different than that.

It feels like it's more.

Aimed at professionals and, people in the InfoSec community or people

who care about security in general.

I think yes, operating system would be a better term for any Android

based operating system, but graphene iOS in particular would be, a

great project to use that term for.

I mentioned just now that graphene S is it feels a bit different than

other Android based derivatives.

Aimed at people who care about privacy security, it advertises that it's more

private and secure than AOSP so many people who aren't familiar with graphing

OSTP may be wondering what are some of the privacy features that offers

that aren't available and it wispy.

And what are some of the changes that you guys made to make your

derivative more secure than AOSP.

So graphing us is intended as a security and privacy research projects,

which focuses on incremental and systemic improvements rather than just picking

apart minor issues and low-hanging fruit.

Although obviously that is anything that would be present in a project.

Focusing on systemic improvements rather than individual issues.

One of the things that we have is a hardened Lipsy and hardened memory

allocator, which we know as heart Malak.

And that helps deal with a specific type of class of vulnerability, which

is referred to as memory corruption and memory corruption makes up.

I would say the overall majority of.

Of high end critical vulnerabilities present within the AOSP and chromium.

we have found and fixed issues in the wild, and it also will actively

prevent vulnerabilities that would otherwise affect AOSP normally.

If you want an example of that, we actually found a real world issue

and that's currently being tracked as if anyone wants to look up the

CVE number, CDE 20 21 0 7 0 3.

And that was a use after free vulnerability found by hardened.

Obviously in addition to that, Graffina our ships have no tracking whatsoever

built into the operating system.

And we also have the auditor and attestation server projects and

those help to verify that your installation of graphene is the

real, genuine graphing of us project.

And that, works by using hardware attestation, which is

backed by the secure element.

And that verifies the authenticity and integrity of all the code on the device.

You also add the network and census permissions so that they are user facing.

Say you install, I dunno, PDF viewing app.

For example, the user can revoke the networking permission or the census

permission just as if they were to revoke the context or messaging permissions.

Additionally, we close off any access to.

to say device identifiers to Android, hasn't already done.

For example, legacy apps on AOSP can currently access the serial

number, but we closed that office.

So it can't be used for tracking.

We also build upon AOSP security features.

For example, Andrew 12 brought into production, the camera and microphone

indicators, and we enable the location indicators, which aren't

actually enabled on production.

Andrew 12 operating systems.

Similarly, we also enabled them before they were actually enabled

in production on Android 12.

And I believe they've been a feature since Android nine, if I recall properly.

And that's just a very brief summary of just the incremental systemic

privacy and security improvements that we do at graphing us.

And we have a full features list on our website.

thank you for high level rundown of.

Many of the security and privacy benefits that crafty nos offers on top of AOSP.

One thing I wanted to ask you to follow up on, these extensions that you guys offer

over AOSP is , why do you think AOSP.

Doesn't offer hardened Malik by default.

And what are the downsides of enabling it the way graphing OSS.

And are there any performance, downsides to enabling it?

ISP currently is using the scooter allocator instead of hardened Malak.

Now we're completely open to AOSP using hardened Mellon.

If they were to adopt it, it's permissively licensed and is inherently

compatible with the licensing of AOSP.

harden, Malak, compared to scooter, we'll use more memory and that's due

to the mitigations, which it deploys.

And also it can potentially lead to issues in applications, which do have memory

corruption, which simply isn't being exposed by traditional memory allocators.

. And honestly, that decision really lies with them.

bionic is inherently designed so that you can essentially swap in memory.

Allocators is I would properly crudely word.

Hot metal compared to school, though, when it comes to performance device

resource usage performance should not really be affected much from

a user's perspective, but it will involve in increased memory usage.

That's due to the mitigations, which pardon Malik deploys.

And obviously Google could potentially disabled some of the mitigations of

enharmonic if they wish to deploy it.

And that would still be an improvement, but obviously it remains to be seen

as it is ultimately a Google choice.

And we can't really show it.

So just taking a step back and trying to summarize, I think

you'll find is that, because Google is such a massive corporation that

develops, all of Android, which is used by billions of devices and they're

responsible to thousands of companies.

Tens of thousands of developers out there, any change that they have to make,

any performance impacting change that affects things on the millisecond scale is

something that they have to be aware of.

And because, such changes are scrutinized so heavily and they have

to be benchmarked and they have to be observed for changes, will this

negatively, in fact, 1% of our devices.

And if so, how badly will it impact them?

These kinds of considerations?

you know, hardening decisions, more difficult for Google to do, whereas

with a project like graph, it's possible to take more experimental approaches

that may impact performance a bit negatively, but would theoretically and

practically improve the security overall.

So just to give one example of this consideration that I'm aware

of personally, The application spawning process used by

Android, which is called zygote.

I believe graphene O us disables that traditional spawning model.

And, what happens normally is that Android creates a, if you go back

to like high school biology creates a psycho and then from there.

Application process or split off from that psycho and the benefit of having that

psycho processes, that it's able to start up some of the libraries and some of the

tools and et cetera, that are needed by applications when they're being spawned.

, this is not as secure as spawning every application freshly, but the benefit of

using Android traditional spot process is that it speeds up app launch times.

By disabling it, you get better security, but you also get slower app launches.

So that's an example of a, trade-off the kind of trade-off that graphene OSTP makes

to trade security, security above else.

Security is the most important aspect when it comes to designing and building

features for graphene graphing.

S would you say that's an accurate depiction of the design philosophy?

Gabe?

I would say that usability is something that we very heavily connect.

Which is why we've built things like assemble, assembles, legal

place services, and we're currently working on extensively documenting

its usage and we're making it even easier for users to use it.

And we've renounced to exact spawning.

, it is generally on newer hardware, very imperceptible, I would say.

Probably one device generation down the line, or honestly, even on modern

devices, like the pixel five and the pixel six, it's barely noticeable whatsoever

to the average user on legacy devices.

Like the third generation pickup.

Especially the free and free XL, which use EMMC.

It did lead to exec spawning, having a much higher impact compared

to newer generation devices.

And I think over time, , as devices get moved to more powerful

hardware, . It'll completely prevent being an issue completely.

Yeah.

And I think that . If you want to go even wider, you can say that this is

just computing at work it's Moore's law.

We're getting more powerful hardware, sequentially over the years here.

And as that hardware becomes more capable of executing within the

thermal or wattage envelope of your smartphone, you're able to do.

I think a good example of that.

If we're going to talk about EMMC and storage speed would be Androids move

to full disk encryption, which was painful and took a number of years.

I forget when it was introduced as mandatory.

Was that new get maybe when FDE became.

I don't specifically recall, but Google's reasoning was well, we're going to

impact performance so badly, and I think everybody can intuitively understand why

disc encryption can impact performance.

We saw that fight for a long time.

I think some phones allowed you to turn on encryption.

as an option when they received an iOS upgrade and it absolutely

destroyed performance.

So yeah, it's something that Google probably has to weigh

pretty frequently given diversity of devices in the ecosystem.

So just a up on encryption aspect, I believe your full disk

encryption was introduced in 5.0.

And then it was eventually replaced with file based in.

if you just Google those two terms, you'll find the, documentation

by Google on what they are.

I don't think they're really necessary for us to dive into right now.

so I just want it to.

Next, you mentioned a lot of different aspects scape that elevate graphing

OSTP as a privacy and security oriented operating system over AOSP.

so if I were, listening to this podcast and I want it to go and install a graph,

you know, us onto my own device and I visited graphene ios.org and visited

the releases section, I would notice that the operating system is only

available for Google pixel devices.

Can you tell me why.

the unfortunate reality is, and I'm going to be pretty blunt

about this, the vast majority of OEMs, they're pretty terrible.

The great thing about pixel devices is that they are essentially

the de facto reference devices for Android, and they are full

support within AOSP and they have.

Probably the best hardware security you can get on an Android device.

they rivaled that of an iPhone when it comes to security things

like having a proper IMU and having a proper secure element.

So the pixels, they have the Titan, em, on the new generation, a base

pixels, the tighten, em too.

So that's the pixel six and six pro and those secure elements

does support the Weaver API, which massively improves this encryption.

just things like this.

Most other OEMs don't implement and most critically, most OEMs do not implement

support for alternative operating systems.

Google pixel devices, they allow you to unlock the bootloader

without any trouble from the OEM.

You don't need to ask for an unlock code, like some OEMs, they don't

need any special fancy software.

It's just use fast bit when you can unlock the bootloader.

And it also allows you to define , a user defined route of.

what that means is that you can preserve the verified big frat model and actually,

use verified a bit and lock the bootloader with your own operating system, with

your own keys on a pixel device.

And generally pixels have been only devices to properly

implement support for that.

There's a few manufacturers out there, which I won't name while they do have

support, they don't implement it properly.

And there are serious security issues with the alternative operating systems.

So just for a bit of background, for those of you who aren't familiar,

the bootloader is a special piece of software that basically loads up, all of

the other components that are necessary to load up the operating system,

including the kernel and everything else.

Literally loading up.

Everything needed to boot the device.

And when we say you unlock the bootloader, basically that allows, the

user to install images that were not originally signed by the manufacturer.

And, if you were to lock the bootloader.

Then those images would have to be recognized by, the verified boot system

on Android and most devices do not allow you to, insert your own verified boot

keys into that process so that if you were to lock the bootloader, your phone

will be completely braked after installing in alternative operating system.

And with few exceptions, like the Google pixel series, you can.

I'm not the bootloader flash accustom operating system

and then lock the bootloader.

, that is probably one of the most important things that blocks graphene, iOS and other

security minded operating systems from being supported on non pixel devices.

one thing I noticed though, is that even if you were to go through this

process of unlocking the bootloader.

Installing graphene O S and then, flashing a custom verified boot key,

and then re locking the bootloader is that the bootloader will

still show you a warning message.

It displayed in yellow that tells you that you're running

in alternative operating system.

If you were the user who went through the process of installing

graphene OSTP and did all this.

You probably, dismiss this message is no big deal.

Cause you know exactly what you did to your own advice.

But if you were to purchase a device with graphene iOS pre installed, or

maybe you had a friend or someone else install it onto your device for you and

you put up your device and you see this message, you might be a little concerned.

So I wanted to ask you . what would it take to have this message,

not show, what would it take to have graphene S be treated like

a first party operating system?

Like the pre-install firmware on devices.

Going to keep it since.

Android has multiple states within which verified boot will operate in.

So when you buy a device from the shops, say I bought a brand

new pixel six or whatever.

The latest Samsung is that device will boot in the green verified boot

state, which means that the device is booting and operating system, which

has been approved and certified.

And, Basically the OEM said, yeah, we're shipping it with this.

We're approving this operating system.

It will be without any warning, no friction whatsoever.

Now say for example, I were to buy a pixel, unlock the bootloader,

and it's still graphing.

Then device will be booting in a yellow verified boot state.

What that means is that device is using a user defined root of trust.

Your device is using the graffiti now as keys in order to preserve

the verified boot threat model.

And it's running on a locked boot loader with a custom operating system.

So that means quite literally anywhere.

Combined pixel clone down AOSP and build their own fork of the operating

system of all their things that they want in bear operating system, flush

it to the phone with their own keys and lock the bootloader, and they will be

able to completely maintain the front model of the Android security model.

And so if say an OEM wanted to implement first party support for

graphing OS, what exactly would they have to do to get the device to boot with a

green verified boot state with graphene O

S so an OEM would have to waitlist on keys in order for the

phone to boot in the green state.

Within the bootloader and OEM, essentially, It has a

key pinned within the farmer.

and if that key does not match what is in essentially the approved list,

the phone will kick and scream and say, all right, is it using a use

of the finder of trust or is it not?

if it's not, and it's on a lot, bootloader, it'll give a red screen

because something has gone terribly wrong.

If it is using a user defined root of trust of a lot bootloader, then

it will say, okay, you are in the list, but the user has defined you.

So that means that it will be in a yellow verified.

With graphene us on potentially our own hardware or a partner

manufacturer's hardware.

We aim to have it so that our keys will be wait-listed.

And you'll be able to skip that screen

quick tactical question.

can this list be changed after the fact by flashing a new boot loader to the

device, or is that break the trust?

only the OEM can build and sign the bootloader.

all the farmers of the device is signature enforced.

So you can't just swap out the bootloader with your own.

You'd have to use the pre-production device to do that.

And that's just not going to happen.

I guess my example would be in the case of an OEM, actually,

doing this and partnering and wanting to update a phone to support, the

green status, would that be possible?

That could absolutely be possible.

Awesome.

I want to focus on the post installation aspect of graphing LS.

Once you actually have properly installed it and have set it up, you're

going to actually be using this as your operating system on your daily

driver device, which means do you have to have applications anyone who has

installed in AOSP bill probably knows that it's incredibly bare bones and

the basic apps that are there are old.

Incredibly unmaintained by Google.

Unless you want basically a dumb phone, you're going to have to

install apps from somewhere else.

Most OEMs decide to include GMs, which is Google mobile services, as well

as a suite of their own applications.

But for smaller teams like graphing us, it's just not feasible to develop an

entire GMs alternative suite of apps.

And it's also not technically legally okay.

To ship GMs alongside these graphene iOS belts, although many, I'd say other

operating system projects do so anyways.

but I think philosophically graphene, O S doesn't really like

the concept of GMs and has been.

working on alternatives because widely recognized at GMs and, Google play

services and Google play store in particular are incredibly important

applications for the average user.

You know, most users probably won't bother with alternative operating systems that

don't have those applications because just so many things aren't unavailable.

And so many applications just refused.

gave actually alluded to this earlier, but graphing OS has been developing something

called the sandbox play services, compatibility layer, and this, I think,

tries to bridge the gap between okay.

we value privacy and security above all else.

Google apps are closed.

Source binaries.

They collect a whole bunch of data.

But, we know users want to use them regardless.

So I wanted to ask you Gabe, can you tell us a bit about how sandbox play services,

compatibility layer works and how does it, deliver access to Google apps while

preserving graphene OSS privacy model?

Sure.

So ? say for example, you were to just compile an all AOSP build or just simply

buy a phone, which didn't come with GMs.

You don't have Google play store then of Gill play services, general

legal services framework, et cetera.

You won't be able to just install the APKs onto the phone.

And everything will train crash because by default they expect to

be in a special se the annex policy.

They expect to be built into the OS.

So they actually privileged apps and they expect to have all sorts of extra

permissions, which aren't user-facing and only privileged apps can get.

And because of that's why they chain crash.

On graphing of us, what we've done is instead of running

in the own se the next time.

They run in the normal untrusted app.

I see an X domain, which means they run in the same application sandbox, just

as any other APK you are to install.

We don't ship them at all within the operating system.

On top of that, we have essentially taught them how to run like this.

we do that using shims within the operating system.

So say for example, Google play services might try and access the privileged API

to , get the serial number of the phone.

Yeah.

Instead of what we'll do is we'll just say, oh, there's no

serial number, but that's okay.

You can just use this stub, API that we made.

And then it would just think, oh, there's no serial number.

Guess there's none.

And it'll just continue on.

that's essentially what it does throughout the application.

And we've got to a point where.

The vast majority of functionality offered by Google play services and the whole GMs

stack work almost perfectly on graphing.

we have, for example, the new, no down advertising identifier,

you can enable that within Google play services, we also have.

The location, redirection support, which means say,, you install an

application that exclusively relies on Google play API APIs for location.

Instead of the Android operating system, location, API APIs, you can read the.

Those APIs system-wide to go through our compatibility layer and then

redirected to the operating system instead of them essentially being

proxied through Google play services.

So that means Google play services can run without location access.

The apps that depend on its location API can still use it

through the operating system APIs and with regards to functionality.

I did mention earlier that almost everything works and recently we've

got quite literally almost everything.

Things like casting to a Chromecast or apps that don't have their own costing,

implementation, and aligning the place services implementation that works.

Things like Fido and security keys.

Those work now, since there is no AOSP implementation for

security keys, for example.

And it's one of many things which you can see has been moved into place

services in order to either be backport.

It took all Android devices, since you can't really back

port a feature like that to.

Over a billion devices, which are running on multiple different Android versions.

So security, key support isn't in AOSP, but if were in place services

for everything, it's just an example of many features like that, which are

highly integrated into place services.

Like even if you were to compile chromium, premium's going to use

that for security, key support.

If you want to use safe browsing on chromium, it

relies on the Google play APIs.

And the most common use case, which I'm sure everyone has encountered

when they've tried to install custom operating system on their phone without

Google apps is Firebase notifications.

So the Firebase back-end is essentially where , I was to install, I don't know.

Let's say Snapchat, for example, their backend servers

would communicate to Firebase.

Hey, you've got a notification and your phone with Google play

services on it would constantly out.

Towards Firebase and say, okay, there are any notifications.

And then Firebase would say, yeah, you got on your Snapchat message and Google

play would then tell that to Snapchat.

And then Snapchat would pop up saying, Hey, you have a notification.

But none of that functionality by default would be on the operating

system without Google play services.

And generally at least in the Western world.

Pretty much everything uses fire based notifications that deliver

notifications for a backend to the client.

if you look in China, there's all sorts of different homegrown implementations.

I don't remember all of them off by heart, but I know Huawei has one.

I think Tencent has one as well, and I'm sure there's numerous others as well, but

when it comes to the west, pretty much everyone uses Google play services and

the find may CPI to get notification.

And that, of course it's fully functional and graphing us.

When you use some books, Google places.

Yeah, so , I think this is a very fascinating and novel approach to

solving the issue of, that I'm sure many companies who are looking at building an

Android device of hat, do I have to ship Google mobile services with my device?

And if the answer is you're selling a smartphone to a consumer, then

the answer is probably very likely.

And there's really been no way to get around that because if you don't ship

GMs, then your users won't have apps.

When I've access to apps on the Google play store, many of their

applications will refuse to run or just simply be broken without access

to play services, API APIs, and, just without access, do you lose so much

if you don't have include GMs and, by.

Accepting GMs into your bill.

Do you have to bundle it as privileged set of applications?

You have to grant it so many permissions.

You're allowing Google to access so many privileged APIs that aren't

available to other applications.

They can, collect a lot of data.

They run in the background persistently.

There's just so much control you're giving up to enable GMs on your bills.

I think this is a really novel approach that basically.

Allows users to install GMs apps as if they were just regular

applications without giving up too much of your privacy in the process.

And I think basically any company that's looking at, building AOSP and shipping

an AOSP device that actually functions acceptably for an average user might

want to take a look at this sandbox play services, compatibility layer approach,

because it is very interesting in my.

I guess that my big question about that to UK would be, do you see Google

trying to shut some of these doors?

because these are work arounds and, Google obviously also has its

own, kind of trust model for play services that it wants to preserve.

So I'd be curious of your view of where this puts that.

And, how you see their response to date.

I don't really consider this to be an issue because , , we

made shims for everything.

We can always add more shims.

and I highly doubt it's within the interest to intentionally

break anything, which we do.

So I don't really consider it to be an issue for the longterm.

Right.

It is, a bit of a cat and mouse game there because, Google play services

and a lot of apps and GMs are a black box to outside developers.

We don't have the source code to the applications.

So we don't know what API APIs and features Google are planning,

or if anything breaks, we can't really anticipate that.

But as Gabe mentioned, if anything changes, it's always possible

to account for that change.

They might just take some time and a bit of development effort, but

changes can be made to reintroduce support and compatibility with

the latest place services updates.

one of the last questions I wanted to ask you, Gabe is, recently

there's been a lot of talk about software update LUNGevity and Who

is to blame for the, in my opinion, mediocre support that most Android

devices get from their manufacturers.

On average, you'll find that , most flagship devices get

three years of OSTP updates and three years of security updates.

Recently, Samsung has extended that to four years of OSTP updates

and five years security updates.

they're finally starting to approach apple levels.

But apple has always been the gold standard for years.

And for years, Android has lagged behind that gold standard.

So , what do you think of this issue?

Do you think, this can be solved.

Do you think there is a particular entity that we would blame for, poor

software support, length, or do you think it's more complicated and how does

this affect your work on grafting LS?

When it comes to solving this, I do quite firmly believe that it's

a huge combination of issues whereby SOC vendors and OEMs, both have caused

it to be a little bit of a headache I think Google has acknowledged this.

And I think since the introduction of initiatives like treble

project, main line, and GKI so generic Colonel images, I'd say.

Possibly in the far future, potentially even near a future or get to a point

where Google would end up maintaining the vast amount of the base operating system

that's unified across all Android devices and they would update it and maintain.

And we'll get to a point where OEMs just simply maintain their device

specific bits and SOC vendors with collaborate with OEMs to make sure

that's getting pushed out quickly.

So we'll get to a point where.

Google might do the entire underlying OS and they might

do the generic kind of women.

And they might just do that automatically for everyone.

And that would leave OEMs of having to manage firmware updates and

kernel module updates and any other parts of the operating systems.

So say they have a fancy skin, or they might have some novel features.

They would maintain that, but Google would maintain the core Android OSTP.

And I think that will most likely be the future we end up going into,

but of course either really know what will happen in the future.

That's just my personal speculation.

I don't think there's a clear solution to it, but I do think the work Google is

putting into trying to mitigate things and ultimately solving it is going

to be highly beneficial in the long.

I do quite firmly believe that support periods are far too short.

And I think that, a question that is brought up often is why are we coming

together to essentially make e-waste?

And the reality is as a project, we can't really do much about it.

the truth is that we can only be.

I have devices for security coverage.

So long as an OEM is providing support.

The pixel two, for example, that's been end of life work quite a long time.

Now there is no way you can have a secure pixel turnout because

the OEM, IE, Google is not pushing up any security updates for it.

Say you're on a pixel free.

You need to move.

If you're on a free freer, you need to think about moving later this year,

it's not necessarily a great reality.

And people do often frequently compare this ecosystem to the desktop

side where they're saying, oh, but I can use my desktop for years.

I can just install an expert.

I think the awareness of.

In mobile, secure is far more heightened compared to that of desktops where

people don't really understand that things like their UEFI from where their

GPU from where they're trusted platform, module, firmware, all of that culminates

in the whole security of your system.

And the reality is most OEMs neglect that.

we are already seeing in the wild exploitation of these things.

And I do think in the future, it will be a far bigger issue than it is currently.

It's a time bomb waiting to happen.

And in that same regard, users should be very well aware that they should really

avoid using hardware that doesn't have full OEM support because they're not

going to be getting security coverage.

And of course, there's not going to be any bug fixes, but.

that's probably the least of your concerns when anyone can

just, get into your system.

yeah, I don't think there's a very clear answer on what we can do to tackle that.

, that's all I really have to say on the matter.

And I think that's a very fair assessment and that's

what we hear from everyone.

And this is becoming our bit every week where we ask about the state

of the Android update ecosystem.

And the complexity of it, as you've said, makes it really hard to pin anyone to the

wall and not necessarily that they deserve to be there also consumer preferences to

take into account, which in many ways.

The aforementioned e-waste problem.

People want the new thing, and they've been conditioned by a lot

of companies to want the new thing.

For Google's part.

I think that your assessment that, they're going to keep making the OSTP more

modular as relates to the OEM involvement.

That rings true based on everything we've seen with trouble and mainline and GKI

and all of these other initiatives that are just designed GRF is another one

that we've talked about on a episode of the show that will probably be going up.

And the Google requirements freeze that will essentially make it easier for

OEMs to be worse about certain kinds of updates, but in service to getting them

up to date on newer platform versions and more security patches extensively as well.

So you do see Google have to balance that those considerations against each other.

the, OEM.

their kind of economic situation and then also the security of the

whole platform, which is obviously really important to Google.

think that a great example is play services.

Google has increasingly used that as the carrot.

And the stick being, not having play services because everybody wants them.

Right.

So I think that we'll continue to see them use GMs in that

way to advance that interest.

And I think it's a credible way to do it.

It's also one of the few tools they have in their belt , to

enforce that sort of thing.

yeah, it's, going to be slow.

Like you said, Gabe, it's going to take time, but I think we're

watching the pieces come together.

I think this year, I would say Michelle, would you agree that

especially with 12 L or excuse me, 12 and 13, we've seen Google's plans.

They are become much more clear.

Yes.

Especially with the introduction of GRF, which many developers that I've spoken to.

Pet basically describe it as the completion of project trample.

Treble is, finally here with GRF and if you're not familiar with GRF then as

David mentioned, go back and listen to the podcast episode where we talked about that

or the blog posts that I published on it.

but in general, to answer your question.

Yes, I do believe finally, we're going to see the fruits of all of those

initiatives . coming to fruition, may take a few years because we have to actually

wait to see , how quickly OEMs now roll out updates based on these improvements.

But I do think it will have a noticeable impact on the frequency

and the speed at which Android updates are pushed out to users.

All right.

thank you for joining us, Gabe.

where can people learn more about graphing and see what you're working on over there?

So we have a highly in-depth documentation and feature

overview, which you can find that graph, s.org and we are also.

Highly active on our Twitter page.

And we also have a very interactive and active community, which you can find

also in graphing the rest of all by just hitting the contact button in the top.

And you'll be more than welcome to talk about it and ask any questions you have.

Thanks Gabe.

And actually I'm one of the things you brought up earlier did remind

me of Asper a little bit, because we do support verified boot, for our

own distro based on Android, because work with a couple of OEMs, one of

them, most prominently being Lenovo.

So that actually clicked for me.

So thank you for bringing that up because I wasn't a.

Of how that was architected and now it makes a lot more sense to me.

and that gets to who's powering the show.

It's Esper, Michelle and I both work at Esper.

You can find our work@blogdotesper.io.

If you're listening to this episode and you're wondering, okay, like I'm

here because I want to understand how Android devices get built.

what goes into putting on your own OSTP distro on an Android.

Come talk to us at Esper.

We do this every day.

We're building our own custom.

Do we have, excuse me, not building half built our own custom disrobe

Android that works for a variety of devices, including X 86 Intel computers,

which we're actively flipping in the wild with customers right now.

And we can give them security patches too.

Yeah, you should get in touch with us.

That's esper.io.

If you want to book a demo, or if you just want to see what Michelle

and I are up to that's blog.esper.io, or you can find us both on Twitter.

Our links are in the show notes below.

Thank you for listening everybody.