Episode 9

Building a more secure OS based on Android

Published on: 14th March, 2022

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.

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

For more about Esper:

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

Transcript
David:

Hello everyone.

David:

And welcome to another episode of the Android bites podcast powered

David:

by Esper I'm David Ruddock.

David:

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

David:

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

David:

You probably wouldn't ordinarily see discussed this week.

David:

We've got a very special guest.

David:

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

Mishaal:

Thanks David.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

of the preferred alternative Android based operating systems for devices that

Mishaal:

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

Mishaal:

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

Mishaal:

works on the project full time.

Mishaal:

Gabe from graphene O S welcome to the show either.

Gabe:

I'm very happy to join you guys today.

Gabe:

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

Mishaal:

Yeah, definitely.

Mishaal:

before we actually dive into those details, I really wanted

Mishaal:

to clarify one thing with you.

Mishaal:

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

Mishaal:

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

Mishaal:

Android based operating systems.

Mishaal:

Aren't offered by Google or OEMs.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Gabe:

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

Gabe:

my rationale for that being that.

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

systems, because, that is what the.

Mishaal:

Yeah.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

the longevity of your old device.

Mishaal:

It has that hobbyist, indie developer connotation associated

Mishaal:

with it, in my opinion, at least.

Mishaal:

And it feels like graphing.

Mishaal:

This is different than that.

Mishaal:

It feels like it's more.

Mishaal:

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

Mishaal:

who care about security in general.

Mishaal:

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

Mishaal:

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

Mishaal:

great project to use that term for.

Mishaal:

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

Mishaal:

other Android based derivatives.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

that aren't available and it wispy.

Mishaal:

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

Mishaal:

derivative more secure than AOSP.

Gabe:

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

Gabe:

which focuses on incremental and systemic improvements rather than just picking

Gabe:

apart minor issues and low-hanging fruit.

Gabe:

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

Gabe:

Focusing on systemic improvements rather than individual issues.

Gabe:

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

Gabe:

allocator, which we know as heart Malak.

Gabe:

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

Gabe:

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

Gabe:

I would say the overall majority of.

Gabe:

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

Gabe:

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

Gabe:

prevent vulnerabilities that would otherwise affect AOSP normally.

Gabe:

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

Gabe:

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

Gabe:

CVE number, CDE 20 21 0 7 0 3.

Gabe:

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

Gabe:

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

Gabe:

built into the operating system.

Gabe:

And we also have the auditor and attestation server projects and

Gabe:

those help to verify that your installation of graphene is the

Gabe:

real, genuine graphing of us project.

Gabe:

And that, works by using hardware attestation, which is

Gabe:

backed by the secure element.

Gabe:

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

Gabe:

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

Gabe:

Say you install, I dunno, PDF viewing app.

Gabe:

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

Gabe:

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

Gabe:

Additionally, we close off any access to.

Gabe:

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

Gabe:

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

Gabe:

number, but we closed that office.

Gabe:

So it can't be used for tracking.

Gabe:

We also build upon AOSP security features.

Gabe:

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

Gabe:

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

Gabe:

actually enabled on production.

Gabe:

Andrew 12 operating systems.

Gabe:

Similarly, we also enabled them before they were actually enabled

Gabe:

in production on Android 12.

Gabe:

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

Gabe:

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

Gabe:

privacy and security improvements that we do at graphing us.

Gabe:

And we have a full features list on our website.

Mishaal:

thank you for high level rundown of.

Mishaal:

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

Mishaal:

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

Mishaal:

over AOSP is , why do you think AOSP.

Mishaal:

Doesn't offer hardened Malik by default.

Mishaal:

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

Mishaal:

And are there any performance, downsides to enabling it?

, Gabe:

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

, Gabe:

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

, Gabe:

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

, Gabe:

compatible with the licensing of AOSP.

, Gabe:

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

, Gabe:

to the mitigations, which it deploys.

, Gabe:

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

, Gabe:

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

, Gabe:

. And honestly, that decision really lies with them.

, Gabe:

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

, Gabe:

Allocators is I would properly crudely word.

, Gabe:

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

, Gabe:

resource usage performance should not really be affected much from

, Gabe:

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

, Gabe:

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

, Gabe:

And obviously Google could potentially disabled some of the mitigations of

, Gabe:

enharmonic if they wish to deploy it.

, Gabe:

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

, Gabe:

as it is ultimately a Google choice.

, Gabe:

And we can't really show it.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

responsible to thousands of companies.

Mishaal:

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

Mishaal:

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

Mishaal:

something that they have to be aware of.

Mishaal:

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

Mishaal:

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

Mishaal:

negatively, in fact, 1% of our devices.

Mishaal:

And if so, how badly will it impact them?

Mishaal:

These kinds of considerations?

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

practically improve the security overall.

Mishaal:

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

Mishaal:

of personally, The application spawning process used by

Mishaal:

Android, which is called zygote.

Mishaal:

I believe graphene O us disables that traditional spawning model.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

to trade security, security above else.

Mishaal:

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

Mishaal:

features for graphene graphing.

Mishaal:

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

Mishaal:

Gabe?

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

And we've renounced to exact spawning.

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

to the average user on legacy devices.

Gabe:

Like the third generation pickup.

Gabe:

Especially the free and free XL, which use EMMC.

Gabe:

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

Gabe:

to newer generation devices.

Gabe:

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

Gabe:

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

David:

Yeah.

David:

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

David:

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

David:

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

David:

And as that hardware becomes more capable of executing within the

David:

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

David:

I think a good example of that.

David:

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

David:

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

David:

I forget when it was introduced as mandatory.

David:

Was that new get maybe when FDE became.

David:

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

David:

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

David:

disc encryption can impact performance.

David:

We saw that fight for a long time.

David:

I think some phones allowed you to turn on encryption.

David:

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

David:

destroyed performance.

David:

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

David:

pretty frequently given diversity of devices in the ecosystem.

Mishaal:

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

Mishaal:

encryption was introduced in 5.0.

Mishaal:

And then it was eventually replaced with file based in.

Mishaal:

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

Mishaal:

by Google on what they are.

Mishaal:

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

Mishaal:

so I just want it to.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

available for Google pixel devices.

Mishaal:

Can you tell me why.

Gabe:

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

Gabe:

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

Gabe:

The great thing about pixel devices is that they are essentially

Gabe:

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

Gabe:

support within AOSP and they have.

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

pixels, the tighten, em too.

Gabe:

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

Gabe:

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

Gabe:

just things like this.

Gabe:

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

Gabe:

support for alternative operating systems.

Gabe:

Google pixel devices, they allow you to unlock the bootloader

Gabe:

without any trouble from the OEM.

Gabe:

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

Gabe:

need any special fancy software.

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

your own keys on a pixel device.

Gabe:

And generally pixels have been only devices to properly

Gabe:

implement support for that.

Gabe:

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

Gabe:

support, they don't implement it properly.

Gabe:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

including the kernel and everything else.

Mishaal:

Literally loading up.

Mishaal:

Everything needed to boot the device.

Mishaal:

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

Mishaal:

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

Mishaal:

And, if you were to lock the bootloader.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

will be completely braked after installing in alternative operating system.

Mishaal:

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

Mishaal:

I'm not the bootloader flash accustom operating system

Mishaal:

and then lock the bootloader.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

process of unlocking the bootloader.

Mishaal:

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

Mishaal:

and then re locking the bootloader is that the bootloader will

Mishaal:

still show you a warning message.

Mishaal:

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

Mishaal:

in alternative operating system.

Mishaal:

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

Mishaal:

graphene OSTP and did all this.

Mishaal:

You probably, dismiss this message is no big deal.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

a first party operating system?

Mishaal:

Like the pre-install firmware on devices.

Gabe:

Going to keep it since.

Gabe:

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

Gabe:

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

Gabe:

new pixel six or whatever.

Gabe:

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

Gabe:

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

Gabe:

has been approved and certified.

Gabe:

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

Gabe:

We're approving this operating system.

Gabe:

It will be without any warning, no friction whatsoever.

Gabe:

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

Gabe:

and it's still graphing.

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

the verified boot threat model.

Gabe:

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

Gabe:

So that means quite literally anywhere.

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Mishaal:

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

Mishaal:

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

Mishaal:

green verified boot state with graphene O

Gabe:

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

Gabe:

phone to boot in the green state.

Gabe:

Within the bootloader and OEM, essentially, It has a

Gabe:

key pinned within the farmer.

Gabe:

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

Gabe:

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

Gabe:

of the finder of trust or is it not?

Gabe:

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

Gabe:

because something has gone terribly wrong.

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

With graphene us on potentially our own hardware or a partner

Gabe:

manufacturer's hardware.

Gabe:

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

Gabe:

And you'll be able to skip that screen

David:

quick tactical question.

David:

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

David:

device, or is that break the trust?

Gabe:

only the OEM can build and sign the bootloader.

Gabe:

all the farmers of the device is signature enforced.

Gabe:

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

Gabe:

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

Gabe:

And that's just not going to happen.

David:

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

David:

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

David:

green status, would that be possible?

Gabe:

That could absolutely be possible.

Mishaal:

Awesome.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

the basic apps that are there are old.

Mishaal:

Incredibly unmaintained by Google.

Mishaal:

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

Mishaal:

install apps from somewhere else.

Mishaal:

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

Mishaal:

as a suite of their own applications.

Mishaal:

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

Mishaal:

entire GMs alternative suite of apps.

Mishaal:

And it's also not technically legally okay.

Mishaal:

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

Mishaal:

operating system projects do so anyways.

Mishaal:

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

Mishaal:

the concept of GMs and has been.

Mishaal:

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

Mishaal:

services and Google play store in particular are incredibly important

Mishaal:

applications for the average user.

Mishaal:

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

Mishaal:

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

Mishaal:

And so many applications just refused.

Mishaal:

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

Mishaal:

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

Mishaal:

tries to bridge the gap between okay.

Mishaal:

we value privacy and security above all else.

Mishaal:

Google apps are closed.

Mishaal:

Source binaries.

Mishaal:

They collect a whole bunch of data.

Mishaal:

But, we know users want to use them regardless.

Mishaal:

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

Mishaal:

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

Mishaal:

preserving graphene OSS privacy model?

Gabe:

Sure.

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

legal services framework, et cetera.

Gabe:

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

Gabe:

And everything will train crash because by default they expect to

Gabe:

be in a special se the annex policy.

Gabe:

They expect to be built into the OS.

Gabe:

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

Gabe:

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

Gabe:

And because of that's why they chain crash.

Gabe:

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

Gabe:

in the own se the next time.

Gabe:

They run in the normal untrusted app.

Gabe:

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

Gabe:

as any other APK you are to install.

Gabe:

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

Gabe:

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

Gabe:

we do that using shims within the operating system.

Gabe:

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

Gabe:

to , get the serial number of the phone.

Gabe:

Yeah.

Gabe:

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

Gabe:

serial number, but that's okay.

Gabe:

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

Gabe:

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

Gabe:

Guess there's none.

Gabe:

And it'll just continue on.

Gabe:

that's essentially what it does throughout the application.

Gabe:

And we've got to a point where.

Gabe:

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

Gabe:

stack work almost perfectly on graphing.

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

redirected to the operating system instead of them essentially being

Gabe:

proxied through Google play services.

Gabe:

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

Gabe:

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

Gabe:

through the operating system APIs and with regards to functionality.

Gabe:

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

Gabe:

got quite literally almost everything.

Gabe:

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

Gabe:

implementation, and aligning the place services implementation that works.

Gabe:

Things like Fido and security keys.

Gabe:

Those work now, since there is no AOSP implementation for

Gabe:

security keys, for example.

Gabe:

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

Gabe:

services in order to either be backport.

Gabe:

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

Gabe:

port a feature like that to.

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

highly integrated into place services.

Gabe:

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

Gabe:

that for security, key support.

Gabe:

If you want to use safe browsing on chromium, it

Gabe:

relies on the Google play APIs.

Gabe:

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

Gabe:

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

Gabe:

Google apps is Firebase notifications.

Gabe:

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

Gabe:

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

Gabe:

would communicate to Firebase.

Gabe:

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

Gabe:

services on it would constantly out.

Gabe:

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

Gabe:

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

Gabe:

play would then tell that to Snapchat.

Gabe:

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

Gabe:

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

Gabe:

system without Google play services.

Gabe:

And generally at least in the Western world.

Gabe:

Pretty much everything uses fire based notifications that deliver

Gabe:

notifications for a backend to the client.

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

the find may CPI to get notification.

Gabe:

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

Gabe:

When you use some books, Google places.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

the answer is probably very likely.

Mishaal:

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

Mishaal:

GMs, then your users won't have apps.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

Accepting GMs into your bill.

Mishaal:

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

Mishaal:

You have to grant it so many permissions.

Mishaal:

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

Mishaal:

available to other applications.

Mishaal:

They can, collect a lot of data.

Mishaal:

They run in the background persistently.

Mishaal:

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

Mishaal:

I think this is a really novel approach that basically.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

because it is very interesting in my.

David:

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

David:

trying to shut some of these doors?

David:

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

David:

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

David:

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

David:

And, how you see their response to date.

Gabe:

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

Gabe:

made shims for everything.

Gabe:

We can always add more shims.

Gabe:

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

Gabe:

break anything, which we do.

Gabe:

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

Mishaal:

Right.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

to account for that change.

Mishaal:

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

Mishaal:

changes can be made to reintroduce support and compatibility with

Mishaal:

the latest place services updates.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

devices get from their manufacturers.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

and five years security updates.

Mishaal:

they're finally starting to approach apple levels.

Mishaal:

But apple has always been the gold standard for years.

Mishaal:

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

Mishaal:

So , what do you think of this issue?

Mishaal:

Do you think, this can be solved.

Mishaal:

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

Mishaal:

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

Mishaal:

this affect your work on grafting LS?

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

And I think since the introduction of initiatives like treble

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

that's getting pushed out quickly.

Gabe:

So we'll get to a point where.

Gabe:

Google might do the entire underlying OS and they might

Gabe:

do the generic kind of women.

Gabe:

And they might just do that automatically for everyone.

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

That's just my personal speculation.

Gabe:

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

Gabe:

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

Gabe:

to be highly beneficial in the long.

Gabe:

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

Gabe:

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

Gabe:

together to essentially make e-waste?

Gabe:

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

Gabe:

the truth is that we can only be.

Gabe:

I have devices for security coverage.

Gabe:

So long as an OEM is providing support.

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

Say you're on a pixel free.

Gabe:

You need to move.

Gabe:

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

Gabe:

it's not necessarily a great reality.

Gabe:

And people do often frequently compare this ecosystem to the desktop

Gabe:

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

Gabe:

I can just install an expert.

Gabe:

I think the awareness of.

Gabe:

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

Gabe:

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

Gabe:

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

Gabe:

in the whole security of your system.

Gabe:

And the reality is most OEMs neglect that.

Gabe:

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

Gabe:

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

Gabe:

It's a time bomb waiting to happen.

Gabe:

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

Gabe:

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

Gabe:

going to be getting security coverage.

Gabe:

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

Gabe:

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

Gabe:

just, get into your system.

Gabe:

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

Gabe:

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

David:

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

David:

what we hear from everyone.

David:

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

David:

of the Android update ecosystem.

David:

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

David:

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

David:

take into account, which in many ways.

David:

The aforementioned e-waste problem.

David:

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

David:

of companies to want the new thing.

David:

For Google's part.

David:

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

David:

modular as relates to the OEM involvement.

David:

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

David:

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

David:

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

David:

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

David:

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

David:

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

David:

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

David:

the, OEM.

David:

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

David:

whole platform, which is obviously really important to Google.

David:

think that a great example is play services.

David:

Google has increasingly used that as the carrot.

David:

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

David:

Right.

David:

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

David:

way to advance that interest.

David:

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

David:

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

David:

enforce that sort of thing.

David:

yeah, it's, going to be slow.

David:

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

David:

watching the pieces come together.

David:

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

David:

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

David:

They are become much more clear.

Mishaal:

Yes.

Mishaal:

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

Mishaal:

Pet basically describe it as the completion of project trample.

Mishaal:

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

Mishaal:

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

Mishaal:

or the blog posts that I published on it.

Mishaal:

but in general, to answer your question.

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

Mishaal:

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

David:

All right.

David:

thank you for joining us, Gabe.

David:

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

Gabe:

So we have a highly in-depth documentation and feature

Gabe:

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

Gabe:

Highly active on our Twitter page.

Gabe:

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

Gabe:

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

Gabe:

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

David:

Thanks Gabe.

David:

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

David:

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

David:

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

David:

them, most prominently being Lenovo.

David:

So that actually clicked for me.

David:

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

David:

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

David:

and that gets to who's powering the show.

David:

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

David:

You can find our work@blogdotesper.io.

David:

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

David:

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

David:

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

David:

Come talk to us at Esper.

David:

We do this every day.

David:

We're building our own custom.

David:

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

David:

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

David:

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

David:

And we can give them security patches too.

David:

Yeah, you should get in touch with us.

David:

That's esper.io.

David:

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

David:

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

David:

Our links are in the show notes below.

David:

Thank you for listening everybody.

Next Episode All Episodes Previous Episode

Listen for free

Show artwork for Android Bytes (powered by Esper)

About the Podcast

Android Bytes (powered by Esper)
A weekly show that dives deep into the Android OS
Android Bytes (powered by Esper) is the podcast that dives deep into the engineering and business decisions behind the world’s most popular OS. https://www.esper.io

Android powers over 3 billion devices worldwide and is the platform of choice for over a thousand companies. You’ll find Android on smartphones, tablets, watches, TV, cars, kiosks, and so much more. How does Google architect Android to run on so many form factors, and how do companies fork AOSP to make it run on even more devices? These are the kinds of questions the Android Bytes podcast considers each week.

Join cohosts Mishaal Rahman and David Ruddock, two journalists with extensive knowledge covering the Android OS platform and ecosystem, as they speak to system architects, kernel engineers, app developers, and other distinguished experts in the Android space.

Get in touch with us at Esper.io if you’re looking to use Android for your product — we have the experience you need.

About your hosts

David Ruddock

Profile picture for David Ruddock
David is the Editor in Chief of Esper, and cohosts Android Bytes. David spent over 10 years as the Editor in Chief of Android Police, where he reviewed more phones than he'd care to admit, broke dozens of exclusive mobile industry stories (and also, phones), and ran one of the web's most vibrant Android communities.

Mishaal Rahman

Profile picture for Mishaal Rahman
Mishaal is the Senior Technical Editor at Esper.io and a cohost of the Android Bytes podcast. At his previous role as Editor-in-Chief at XDA-Developers, Mishaal was at the forefront of Android tech journalism, breaking story after story on new OS features and platform changes.