Episode 24

How to distribute apps on Android without Google Play

Published on: 1st August, 2022

The Google Play Store is home to millions of Android apps. It's most likely the place where you downloaded the app to get this podcast. But what if you're in that very special group of users who source their apps from outside the bubble of Google Play?

On this episode of Android Bytes, we talk with Logan Magee, the developer behind his very own app store, Accrescent.

  • 01:23 - Why do so many OEMs license GMS? What’s the importance of the Google Play Store and Google Play Services?
  • 03:38 - What are the considerations you need to make when designing an app store?
  • 07:45 - How do you get your app store on devices without GMS?
  • 09:32 - What is Accrescent, and how will it differ from other Android app stores?
  • 11:51 - How does Android’s security model work when it comes to apps? What is an APK file? What’s inside of an APK? How is it updated?
  • 14:20 - How have APK signatures evolved? What do APK Signature Scheme v3 and v4 bring to the table? How does APK Signature Scheme v4 enable the “Play as you download” feature?
  • 16:28 - Is there a way to secure Android’s trust on first use (TOFU) model for first-time app installs?
  • 19:20 - What do Google Play and other app stores do to get developers on board?
  • 20:40 - How does Google Play (try to) keep malicious apps off their store? Are these measures effective?
  • 26:08 - Should app stores take over guarding of sensitive permissions from the OS?
  • 28:40 - What is the advantage of bundling an app store with the OS image? What can preinstalled app stores do that sideloaded third-party app stores can’t?
  • 30:25 - How does Android 12 enable third-party app stores to perform unattended updates?
  • 33:35 - What is an Android App Bundle and how is it different from an APK? What are the benefits of app bundles and what are some of the downsides?
  • 40:25 - How will Google Play’s app archiving feature work? What is an archived APK?
  • 41:50 - What can we learn about Android app distribution from China?

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, and welcome to Android bites powered by Asper I'm David Ruddick.

David:

And each week I'm joined by my cohost Michelle ramen diving deep

David:

into the world of Android this week.

David:

We're talking about apps and really app stores actually, which is a topic on

David:

Android that obviously has a history as long as the platform itself and

David:

allow Michelle to introduce our guests.

Mishaal:

This.

Mishaal:

Thanks David.

Mishaal:

So on today's show, we have invited Logan McGee.

Mishaal:

He's an independent developer.

Mishaal:

He's working on a project called Crescent.

Mishaal:

So thanks for joining us, Logan.

Mishaal:

Thank you for having me.

Mishaal:

Okay.

Mishaal:

And as David mentioned, we wanna talk about apps, more specifically, app

Mishaal:

stores and app distribution in a O S P.

Mishaal:

You don't have an app store by default.

Mishaal:

You have no way to actually get apps.

Mishaal:

And if you install a pure, fresh AOSP build, you gotta

Mishaal:

find and procure apps on your.

Mishaal:

I was actually reading an interesting article earlier today on L w N I

Mishaal:

don't know if you subscribed to that website or not, but they're basically

Mishaal:

like a newsletter that covers Linux.

Mishaal:

And they talked about way Android, which is a project we've actually talked about

Mishaal:

before on the show way back when we were actually doing the Twitter spaces.

Mishaal:

So way droid for those you don't know is a software project that enables running the

Mishaal:

entire Android user space and a container.

Mishaal:

It's a really interesting and neat project, especially if you

Mishaal:

have a Linux smartphone like the pine phone, and you wanna run

Mishaal:

Android apps because there's not.

Mishaal:

Native Linux optimized apps for smartphones, but it like any other non

Mishaal:

GMs, a O S P project has the same issue.

Mishaal:

Where do users get their apps from?

Mishaal:

Of course, if you're a privacy conscious user, you've probably heard of various

Mishaal:

app repositories, like fro you know how to procure APKs off of various websites.

Mishaal:

But as an ecosystem, this is a huge challenge because you can't

Mishaal:

assume that every user has the same technical capabilities as

Mishaal:

your average Linux developer, does.

Mishaal:

You gotta assume that most users are gonna want to, or they're gonna expect

Mishaal:

that there's an app store on their device and they're gonna click that and they're

Mishaal:

gonna download everything and everything's gonna be handled for them all easy peasy.

Mishaal:

That's why most OEMs major companies, they go through the process of licensing GMs,

Mishaal:

which if you, um, listen to our podcast, our previous podcast with the execs from

Mishaal:

awesome, you know, that's a pretty arduous task, but most OEMs go through it anyways,

Mishaal:

because it's absolutely necessary for their users, which consists of millions

Mishaal:

of average people to have access to the play store and Google play services,

Mishaal:

which ensures not only do they have access to millions of Android apps, but

Mishaal:

also the APIs that many of them depend.

Mishaal:

And because so many apps have GMs dependencies, it's pretty much

Mishaal:

impossible to talk about alternative app distribution models on Android

Mishaal:

without factoring in where GMs comes in.

Mishaal:

So if a device has GMs, then it's mostly just a matter of where

Mishaal:

do you source the apps from?

Mishaal:

Is it from Google play store or is it from somewhere else?

Mishaal:

You're not gonna have that many problems unless you're dealing with like paid apps.

Mishaal:

If a device doesn't have GMs, though, then you need to take extra steps to make

Mishaal:

sure that the app that you're trying to.

Mishaal:

We'll actually run on your device because a lot of apps, like I said, have

Mishaal:

dependencies on GMs, including things like safety net at station fireplace, cloud

Mishaal:

messaging for push notifications, the Google maps, API for mapping, et cetera.

Mishaal:

But thankfully at least since a S P is open and supports side loading,

Mishaal:

other apps stores that aren't bundled with the OS image, you know, it is

Mishaal:

possible to actually have alternative app repositories that don't really

Mishaal:

care about what's going on with GMs.

Mishaal:

Fro is one example that I mentioned the graph OS project.

Mishaal:

They recently released their own quote unquote app store, which is basically

Mishaal:

just like a website that has some of their apps that you need to set up their

Mishaal:

sandbox, Google play implementation.

Mishaal:

If you haven't listened to our graph OS episode, I'd recommend go doing that.

Mishaal:

So that's basically what an app store really boils down to.

Mishaal:

It's just a browsable catalog of apps that users can download install.

Mishaal:

So if you're thinking about designing your own app store and

Mishaal:

distributing apps on Android, you need to answer these questions.

Mishaal:

How do you connect users to that catalog of apps?

Mishaal:

How do you get legitimate apps onto the catalog while

Mishaal:

weeding out illegitimate ones?

Mishaal:

How do you securely and efficiently store and distribute apps to users?

Mishaal:

And how do you handle distributing app update?

Mishaal:

None of these are straightforward things to solve, but fortunately

Mishaal:

we have over a decade of history of looking at what Google play has done.

Mishaal:

So we can basically take a look and see what does it take to go

Mishaal:

about designing your own app store to distribute apps on Android.

Mishaal:

But before we dive into the meat of this discussion, I wanted to ask

Mishaal:

both of you for your overall thoughts and experiences of using other app.

Mishaal:

Such as you know, Wawa's app gallery, Samsung's galaxy

Mishaal:

store F Android, et cetera.

Mishaal:

Have you ever used an Android phone without GMs and exclusively had to

Mishaal:

get apps from outside of Google play?

Mishaal:

And what was it like?

Mishaal:

Have you used an Android phone with GMs, but still chose to get

Mishaal:

apps from outside of Google play?

Mishaal:

Or have you done a mix of both play and non Google play?

Logan:

Personally I used Graphos as recently, actually, so that doesn't

Logan:

have GMs installed by default.

Logan:

And so for a while, I was trying to get apps from other places like

Logan:

GitHub releases or fro, and honestly it was kind of painful to deal with.

Logan:

And so eventually I actually started using GMs through their sandbox, Google play

Logan:

compatibility layer, just because it is kind of a pain to get apps on Android.

Logan:

If you don't have GM.

David:

My history with various app stores.

David:

I mean the most prominent one and the one that I probably use the most would

David:

be actually the Amazon app store, which was such an interesting experiment.

David:

I mean, it's still, obviously very active, used by tens of

David:

millions of people who own Kindle.

David:

Fire tablets.

David:

But I remember the challenges Amazon dealt with in terms of simply like

David:

keeping apps up to date with their Google play counterparts fact that the Kindle

David:

fire devices ran an older OS version.

David:

I believe the Kindle fires initially launched based on ice cream sandwich

David:

initially back in the day, correct me if I'm wrong there, but it was

David:

a different time and it was still a time when legitimately you could.

David:

Somebody may be trying to take a step at Google play.

David:

And Amazon threw money at developers, especially game developers with all

David:

this in-app currency promotion stuff.

David:

And they threw money at advertising to try to get people excited about it.

David:

And it underscored to me that the usefulness of an app store.

David:

Is really dependent on what kind of walls are put up around that device.

David:

And in Amazon's case, it was, you could not easily install, play, or

David:

a GMs applications on those devices.

David:

And they've continuously, you know, I'm not saying they made it

David:

harder, but they fixed loopholes.

David:

And obviously Google doesn't want them to work very well either.

David:

And of course I've used Chinese phones from so many OEMs that don't ship a GMs.

David:

I even back in the day, received a review unit from a smartphone OEM.

David:

And I'm sure Michelle you've experienced this as well.

David:

It came with an application on it, specifically designed to display a

David:

WebApp view that linked to the files you needed to download the core GMs

David:

bits and then install them as though it was like they called it the Google

David:

installer, I think, on this device.

David:

So, yeah, it's just hard to imagine a mass market.

David:

App store that could de throw Google play at this point.

David:

And Amazon did try.

David:

So that then begs the question.

David:

The need for specialty app stores is probably there.

David:

And what kind of specialties will they have?

David:

And that's always been interesting to me, especially since I worked at Android

David:

police until Valette bought Android.

David:

Police is the sister side of AP came.

David:

Dot com.

David:

So I'm aware of things involving Android app distribution, to some

Mishaal:

extent.

Mishaal:

Yeah.

Mishaal:

So if you're going to go about designing an app store or app repository of

Mishaal:

like APK mirror, well, APK mirror is a special exception because it's

Mishaal:

not really designed to actually get people to use it as like an app store.

Mishaal:

It's just basically a APK backup posting site for the most part.

Mishaal:

But if you're going to design an app store that you actually want users to

Mishaal:

use, you need to answer the question.

Mishaal:

How are you gonna get it into the hands of users?

Mishaal:

Obviously on many devices out in the market, you don't

Mishaal:

have access to the OS image.

Mishaal:

So you don't have the ability to bundle your app store with the device.

Mishaal:

If you are a business and you want to have a small selection of apps that

Mishaal:

you want your employees to access, and you know, you're going to buy a

Mishaal:

whole bunch of GMs, Android devices.

Mishaal:

Then you could pretty much skip this entirety of this discussion and just

Mishaal:

use something like managed Google play, which is like a small island of apps that

Mishaal:

are only available for these devices.

Mishaal:

And those are the only apps they can use.

Mishaal:

But if you're not going to be doing that, if you want to ship a device without

Mishaal:

GMs, then you're going to find another way to get your app store onto devices.

Mishaal:

So you could either direct users to a website, which is the lowest hanging

Mishaal:

fruit, or you could create an app that connects to your own customer repository

Mishaal:

backend, or you could piggyback on existing solution, like say creating

Mishaal:

a repo and then using an fro client customized or not to connect to it

Mishaal:

rather than the main FOID repository.

Mishaal:

So if you set up a device to be enterprise managed from the get go, like through

Mishaal:

our SPER device management platform, then it's easy to push something.

Mishaal:

And install apps and update them.

Mishaal:

If you build the firmware yourself, which is something

Mishaal:

we can also do with foundation.

Mishaal:

I know, I know I gotta stop plugging here.

Mishaal:

We'll do that later with David, then the app store app could also be bundled

Mishaal:

with the OS image, and then you could also automate app installs and updates

Mishaal:

and have them be unintended updates.

Mishaal:

So otherwise, if you can't do any of those things, you need to have the user manually

Mishaal:

seek out your repository, which requires them knowing it exists in the first place,

Mishaal:

and then requires them to manually accept, installing and updating the apps in most.

Mishaal:

So, I guess this is the perfect time to segue into talking about

Mishaal:

the app store that you're creating.

Mishaal:

Logan.

Mishaal:

Can you give us a brief introduction to Crescent and why you're building it?

Mishaal:

How will users access it?

Mishaal:

And what are your plans to spread the word about it?

Mishaal:

Once it launch.

Mishaal:

Yes.

Logan:

So Crescent is, uh, an in progress app store.

Logan:

I'm currently building, that's mainly focused on security,

Logan:

privacy, and usability.

Logan:

It works kind of similar to the play store in that it allows developers to.

Logan:

Upload apps that they have compiled themselves, but it's different

Logan:

in that it doesn't require them to give up their signing keys.

Logan:

They don't have to upload an app bundle with their signing keys or have

Logan:

Google generate signing keys for them.

Logan:

So they generate the split AKs themselves locally and then upload them to Crescent.

Logan:

So Crescent still has all of the benefits of split APKs without the

Logan:

downsides of trust and security.

Logan:

it also does something kind of neat regarding app signatures.

Logan:

And so it has this signed piece of repository metadata.

Logan:

The store is really just a static web server.

Logan:

And so it uses that metadata to verify that apps downloaded are

Logan:

signed by who they're supposed to be.

Logan:

So even if the server was taken over by an attacker or something, uh,

Logan:

users who download apps will know for sure that the apps they download.

Logan:

Are, um, developed by who they say they are.

Logan:

Um, but it also focuses on privacy in some ways.

Logan:

Uh, it doesn't send any device identifiers.

Logan:

It doesn't need to, right now it just sends.

Logan:

Like the device architecture, uh, screen density and primary language,

Logan:

and it needs that to fetch split APKs.

Logan:

And another reason building a Crescent was for usability, right?

Logan:

I'm sure a lot of people have had problems with say, uh, on Android, you

Logan:

have to manually accept and install every single time you update an app.

Logan:

Whereas AC Crescent uses some modern APIs to allow you to update them.

Logan:

In the background without user interaction, but without

Logan:

compromising on security.

Logan:

So those are a couple of the things that Crescent does to

Logan:

ensure better user security and privacy or existing solutions.

Mishaal:

Thanks for the rundown Logan.

Mishaal:

So you brought up a lot of things that I kind of wanna touch on in a

Mishaal:

bit, especially like split it, BKS Android, app bundles, et cetera.

Mishaal:

Some of our listeners may not be familiar with these concepts,

Mishaal:

but before we actually dive into considerations that you need to make

Mishaal:

to get apps onto a store, I wanted to talk a bit about Android security

Mishaal:

model when it comes to applications.

Mishaal:

So every app that you install on an Android device comes in a file format

Mishaal:

called an Android package or APK file.

Mishaal:

An APK is a self-contained archive, which is essentially a

Mishaal:

derivative of Java archives or jar.

Mishaal:

But with a few Android specific additions to it.

Mishaal:

So the jar file format is itself based on the popular zip format, which, you know,

Mishaal:

if you ever use the desktop computer, zip it's that handy archive file format,

Mishaal:

where you store a bunch of files and compress it and it saves you space.

Mishaal:

And since jar is based on zip.

Mishaal:

APK by extension is as well, which is why you can open up APK files and see

Mishaal:

what's inside them using something like seven zip on windows or other platforms.

Mishaal:

So within the APK file, there's several key Android specific components.

Mishaal:

Namely the Android manifest, which contains the apps metadata, including

Mishaal:

what components it supports, what components it has, what permissions

Mishaal:

it requests and other various.

Mishaal:

Things that it needs like libraries that might require there's also the DAIC

Mishaal:

executable bike code files, which has the apps code for the JVM to interpret.

Mishaal:

Then there's the resource catalog, which is like, uh, resources.ar SC, and then

Mishaal:

the actual resources that they map to.

Mishaal:

Then there's unmanaged resources, which are also called assets and then

Mishaal:

optionally some native libraries.

Mishaal:

There's also a digital signature, which is inherited in part from the jar format.

Mishaal:

And that digital signature is generated whenever the developer signs, the

Mishaal:

application package using a signing key.

Mishaal:

So every app is installed onto a device, gets a unique, or

Mishaal:

has a unique package name.

Mishaal:

Developers can technically give whatever package name they want

Mishaal:

to their application, but Android will reject the insulation of.

Mishaal:

That has a package name matching an existing app that's installed

Mishaal:

on the device provided that app's digital signature doesn't

Mishaal:

match the existing apps this way.

Mishaal:

If you have one app installed a developer, can't just say, I want my app to have

Mishaal:

the same package name, and then try to install on top of that existing one.

Mishaal:

That's one of the key parts of Android security model

Mishaal:

when it comes to applications.

Mishaal:

And since the signing key used to generate an app's digital signature is generally

Mishaal:

assumed to be kept private and secure, you know, somewhere where only the developer

Mishaal:

who signs the app has access to or in, uh, Google play's case, Google themselves.

Mishaal:

It's generally assumed that only the app's original developers or

Mishaal:

Google will be able to push updates to existing apps that Android will.

Mishaal:

This is how Android securely updates apps.

Mishaal:

So I've done a bit of oversimplification here.

Mishaal:

APKs, don't actually use like the exact same digital signature

Mishaal:

implementation that you see in jar files.

Mishaal:

They've evolved over time to have like a proprietary implementation.

Mishaal:

There's various implementations called the APK signature schemes.

Mishaal:

And I wanted to ask you Logan, if you can explain to our listeners

Mishaal:

a bit about these, a signature schemes, like what does the signature

Mishaal:

scheme V3 bring to the table?

Mishaal:

For example?

Mishaal:

APK signature

Logan:

scheme three is a slight improvement over V2, which is what

Logan:

replaced the legacy jar signing you were just talking about

Logan:

and V3 allows for key rotation.

Logan:

So that means if a developer has a certain signing key and they

Logan:

might suspect it's compromised.

Logan:

For example, they can sign a new key with their old key and then make that new

Logan:

key, the new trusted key for that app.

Logan:

So they.

Logan:

Migrate away from old keys to avoid compromise without having to make the

Logan:

user uninstall and reinstall their app, which would've been the case before.

Logan:

There's a couple other newer ones too, like before, which is kind of different.

Logan:

It's not embedded in the APK itself.

Logan:

It's in a separate file and that can be used for this feature called Fs Verity.

Logan:

I don't wanna get too technical about it.

Logan:

Essentially what Fs Verity does.

Logan:

And what V four signatures allow is for the OS to cryptographically verify

Logan:

an, a PK every single time you launch it, or every single time it's read by

Logan:

the operating system, which is very helpful for reducing persistence.

Logan:

I believe the Google play store uses.

Logan:

Before signatures

Mishaal:

for this reason, he talked about the technical implementation,

Mishaal:

but one of the key features that it enables is the app incremental feature.

Mishaal:

So I think, uh, I forgot what the marketing name is for it.

Mishaal:

I think plays you download.

Mishaal:

Yeah.

Mishaal:

That's what it's called.

Mishaal:

So Android 12 Google introduced plays, you download, which basically lets

Mishaal:

you start playing a game while a lot of it's assets are still being.

Mishaal:

So because the signature is separate from the actual APK, it's

Mishaal:

able to be verified as the bulk of it's still being downloaded.

Mishaal:

So that's one of the features that V4 Napes and which is why it's not

Mishaal:

really mandatory to support yet.

Mishaal:

Whereas V3 is a much more significant improvement in terms of security.

Mishaal:

So I wanted to ask you next, are there any flaws in this Android

Mishaal:

security model when it comes to app signing and app distribution, and how

Mishaal:

does a Christian plan to deal with.

Mishaal:

Yes, sort of, I wouldn't necessarily

Logan:

call it a flaw.

Logan:

It's more of a design decision, but the way Android works with app

Logan:

signatures is the first time you install it, it pins that signing key.

Logan:

So say you install an app called secure chat or something.

Logan:

I install that.

Logan:

And then the Android operating system parses it and finds the

Logan:

signature and says, okay, this is the key that sign this app.

Logan:

And I will not accept any updates if they're not signed by this.

Logan:

And so that secures updates later on, right.

Logan:

But that doesn't help with the first install.

Logan:

If you install a malicious version of that app, then it'll

Logan:

updates that are legitimate.

Logan:

And presumably you'll be getting updates that are malicious and

Logan:

Android doesn't really do anything itself to solve this problem.

Logan:

It just leaves that up to the application layer.

Logan:

What a Crescent does to solve.

Logan:

This is when you upload an app to the store.

Logan:

Or whoever maintains their repository will sign their key

Logan:

to validate basically to the app.

Logan:

This is the signing key.

Logan:

We will accept for this app.

Logan:

The Crescent will only accept this signing key for this app.

Logan:

And so that means the first time you install it, you can know for certain that

Logan:

you are installing the legitimate version of that app, and it can't be replaced with

Logan:

a malicious version or something, even if the server was taken over, if that makes

Mishaal:

sense.

Mishaal:

Gotcha.

Mishaal:

Yeah.

Mishaal:

I mean, that is a big problem.

Mishaal:

Like figuring out how to install the legitimate version of an app,

Mishaal:

especially when there's so many clones and copycats out there.

Mishaal:

And so many different ways to side load apps or trick users

Mishaal:

into side loading apps that seem legitimate, but they're actually not.

Mishaal:

And once they have it, how do they know it's actually the real deal or not?

Mishaal:

And many times they don't.

Mishaal:

That is one, as you mentioned, it's not really a, a flaw, more like a

Mishaal:

intentional design decision, and there are solutions to mitigate that.

Mishaal:

But one of the, I'd say key failures of most app stores is actually

Mishaal:

getting developers on board.

Mishaal:

And I think this is one of the areas where why so many people don't even

Mishaal:

bother trying to make an app store.

Mishaal:

So kudos to you attempting to do that.

Mishaal:

. For those of you who, uh, aren't familiar with this major chicken egg

Mishaal:

problem, you have an app store, right?

Mishaal:

What you need to do is you need to get apps on board.

Mishaal:

So you need to get developers to upload their.

Mishaal:

But the problem is developers.

Mishaal:

Aren't going to do that.

Mishaal:

If there aren't users who are using your app store, because

Mishaal:

after all, most developers want to make money off their applications.

Mishaal:

You know, they need to earn a living or sell a product or do something with it.

Mishaal:

So if there aren't users, then they aren't going to be making any money.

Mishaal:

And if there aren't any apps, there's not going to be any developers.

Mishaal:

So it's just a vicious cycle that kind of ensures that most burgeoning app

Mishaal:

stores don't ever really take off.

Mishaal:

And it's why even app stores created by the biggest tech companies

Mishaal:

on the planet, just pale in comparison to Google's play store.

Mishaal:

There are a couple of things that Google play does particularly really well and

Mishaal:

what others have attempted to copy in order to get developers, to actually

Mishaal:

upload their apps and share them there.

Mishaal:

So Google play, for example, they offer pretty robust tools around handling

Mishaal:

rollouts and managing your storefront.

Mishaal:

And then offering various ways to promote your apps within Google

Mishaal:

play outside of Google play.

Mishaal:

Other app stores try to offer lucrative revenue, sharing fees, much lower

Mishaal:

than Google, but still, if you're trying to launch an app store and

Mishaal:

you want to compete with Google play, that's a really hard sell.

Mishaal:

But if you are trying to just launch an app store that serves a very specific

Mishaal:

purpose, just a handful of users, you know what you're targeting, then you're setting

Mishaal:

much more realistic goals for yourself.

Mishaal:

But if you're trying to launch very open app store, that steps.

Mishaal:

App submissions by any developer around the world, and you're

Mishaal:

going to deal with the problem.

Mishaal:

And it's a problem that pretty much most app repositories deal with.

Mishaal:

And it's how do you moderate to ensure that bad actors aren't

Mishaal:

abusing your platform to spread their malicious status, sucking

Mishaal:

applications or straight up malware?

Mishaal:

and if you're dealing a Google play scale or like Samsung scale, et cetera,

Mishaal:

then the answer is, in my opinion, you can't, I think it's literally impossible

Mishaal:

for a company like Google to be able to thoroughly audit each and every

Mishaal:

single app that comes out their door.

Mishaal:

There's just too much to deal with.

Mishaal:

There are a few things they do, and they do well and some not so well to

Mishaal:

raise the barrier to entry, to ensure.

Mishaal:

There aren't as many malicious apps or privacy afflicting apps that

Mishaal:

are submitted to the app store.

Mishaal:

Like the most basic thing they do is they require a fee and, you

Mishaal:

know, personnel contact information.

Mishaal:

When you sign up for developer account.

Mishaal:

I don't think it's very effective, but I'm pretty sure that does

Mishaal:

stop a lot of bot submissions, Google play, and other app stores.

Mishaal:

They also perform static analysis of manifest files to look for

Mishaal:

potential violations of privacy.

Mishaal:

So for example, Google play is a lot of policies around what permissions and app

Mishaal:

can request and how they want to use them.

Mishaal:

So if it detects that your app is trying to request the SMS permission,

Mishaal:

then Google play will reject your.

Mishaal:

If you don't submit a forum and your app doesn't meet one of the

Mishaal:

pre-approved categories of apps that can request access to SMS.

Mishaal:

Google play also does automatic dynamic analysis of apps.

Mishaal:

So it analyzes risky code or behavior such as attempts to gain root access

Mishaal:

or disabled se Linux play protect.

Mishaal:

Does this on GMs devices?

Mishaal:

Google play also has human moderators to review app submissions and

Mishaal:

updates to look for violations.

Mishaal:

And finally, Google play also forces developers to declare

Mishaal:

their use of data permissions.

Mishaal:

Although more recently, if you heard the news, Google play is actually starting to

Mishaal:

hide the list of permissions in favor of the developers submitted data safety form.

Mishaal:

You've all heard the stories.

Mishaal:

I don't know if you've ever personally come across this or dealt with this

Mishaal:

before, but you've heard horror stories about developers dealing with

Mishaal:

Google play support or that their moderation practices are ineffective,

Mishaal:

inconsistent, or straight up incompetent.

Mishaal:

And from what I've ever heard, the other major app stores aren't really any better.

Mishaal:

Do you really think there's anything Google and others could do to improve

Mishaal:

the quality of apps and limit the number of fake or malicious apps?

Mishaal:

Or do you think they're pretty much just trying to prevent the dam from.

Mishaal:

I

Logan:

would say similar to what you said, it's very hard

Logan:

for Google to make the system.

Logan:

They have work at their massive scale.

Logan:

It's hard to get frankly, enough competent reviewers and enough

Logan:

analysis to really prove for sure whether an app is malicious or not.

Logan:

It's just not really possible at that scale.

Logan:

They are doing quite a few things to help though, like reviewing certain

Logan:

permissions or making sure they're only used for legitimate purposes.

Logan:

For example, there's a legacy file management permission that some apps

Logan:

request, which basically gives them access to manage all of your files.

Logan:

But sometimes they request that when they don't actually need access to

Logan:

all of 'em, they just need one at a time when they want to send something.

Logan:

And so that's part of what they can do.

Logan:

I don't really know how to solve the problem.

Logan:

On Google side, because honestly I don't upload apps to the play store.

Logan:

So I'm not as familiar with the problems there.

Logan:

David might have a little more insight into that.

David:

Over the years we received so many meals.

David:

I'm sure you did Michelle as well from developers who were having

David:

problems with basically the content review team or content moderation

David:

team on the Google play store.

David:

And there are so many reasons that they can reject to.

David:

and often of course, they're really terrible at actually explaining the

David:

rejection reason because usually the person rejecting you is probably

David:

somebody not making very much money.

David:

And they're working through as many of these approvals as

David:

they can in a given Workday.

David:

Their goal is volume.

David:

Not quality.

David:

No, you can't just make better people for this.

David:

Like you said, that's not really a scalable solution.

David:

And to me, Google is pulling the levers a can, which are restricting permission

David:

access, making it more stringent, or at least making the declarations very obvious

David:

when it's something really sensitive, which we're seeing now in Android 13.

David:

And we've seen in previous Android versions.

David:

And I think that we'll continue to see that trend and we'll continue to be

David:

upsetting to a particular audience of hin enthusiasts who don't like that.

David:

Google is clamping down this way.

David:

At the same time, it's hard to see this being a problem that can be solved at

David:

scale without immensely powerful machine learning and really rigorous controls.

David:

And that just seems to be the direction Google is heading.

David:

That's how most of their products work.

David:

So I feel like, yeah, the horror stories from the play

David:

store are really frustrating.

David:

You hear about devs who get delisted for totally bogus reasons because the reviewer

David:

either didn't understand something about a trademark or copyright complaint, or they

David:

thought there was something in the app that had changed, but they misunderstood

David:

and seeing that kind of stuff.

David:

And like seeing people's livelihoods be affected by that.

David:

That sucks at the same time.

David:

Michelle, what you said, I think is what I've heard as well,

David:

that there is no app store.

David:

That's good at this.

David:

You hear complaints about apple on the app store all the

Logan:

time.

Logan:

This is part of why I believe it's a good idea to leverage the

Logan:

Android security model to enforce this level of quality control.

Logan:

For example, the play store requires that all apps uploaded

Logan:

must target a certain SDK.

Logan:

And basically what that means is it's tested on a certain Android version and

Logan:

the OS enforces certain restrictions around that app that typically get

Logan:

stricter as the Android version goes up.

Logan:

And so that's one way they can enforce quality control.

Logan:

The other one.

Logan:

Permissions, which they do quite heavily.

Logan:

Part of it is informing users as well.

Logan:

So they understand, you know, when I'm giving an app access to

Logan:

this thing, it has apps don't have access to a whole lot of sensitive

Logan:

information without user consent.

Logan:

And so having to rely on the app store to communicate, that can be helpful.

Logan:

But part of it is also up to the user.

Mishaal:

I wanted to ask your thoughts on the growing number of permissions

Mishaal:

that seem to be purposely designed so that their actual enforcement

Mishaal:

mechanism isn't the Android OS itself, but rather Google play.

Mishaal:

And I know like there's a lot of permission that says,

Mishaal:

oh, app stores may enforce.

Mishaal:

The use of this permission, but in actuality, you know, it was

Mishaal:

designed around Google play.

Mishaal:

So I already mentioned SMS, but there's also call log.

Mishaal:

Those two permissions existed a while ago, but I'm seeing more and more

Mishaal:

permissions being added with each new OS version and their permission level

Mishaal:

might be normal, which means that they're granted an install time, but then.

Mishaal:

There's an asterisk in the documentation that says app stores

Mishaal:

may restrict this permission.

Mishaal:

So I wanted to ask you, do you think that's a good model for Google to

Mishaal:

take and do you actually see other app stores following through and

Mishaal:

actually enforcing these permissions?

Mishaal:

Like Google?

Mishaal:

I think it can

Logan:

be a good thing, but I think it's also a hard balancing act.

Logan:

You don't wanna ask the user for every little low level permission

Logan:

that they might understand.

Logan:

For example, there's the quarry, all packages permission, which basically

Logan:

allows an app to list and read all the apps that you have installed

Logan:

in your device, which you would think is pretty sensitive stuff.

Logan:

But the OS doesn't have a mechanism yet to enforce that permission.

Logan:

Even if you don't have the qual packages permission, there are

Logan:

other ways to get around it and list all the apps you have installed.

Logan:

And so the play store restricts this, but the OS doesn't that specific example

Logan:

I think could be enforced by the OS later, but due to how Android works

Logan:

currently, it's hard to do that without breaking certain app functionality.

Logan:

Another example is the internet permission a long time ago, it used to be a dangerous

Logan:

permission, which means the user had to opt in and allow an app network access.

Logan:

But Google later decided that would just cause permission, fatigue.

Logan:

And so if the user is being requested, all these permissions that they have

Logan:

to give almost every single app, then they'll just start blindly accepting

Logan:

without really looking into what they are giving an app access to.

Logan:

And so it's a, it's a hard balancing act.

Logan:

It's definitely better for the OS to enforce a permission, but sometimes

Logan:

it's hard to, for very low level things that the user might not understand

Logan:

what they're needed for or what

Mishaal:

they.

Mishaal:

Yeah, we've talked about this balancing act that Google has to do before.

Mishaal:

And you know, when you're developing an operating system that serves

Mishaal:

billions of users, tens of thousands of developers around the world and

Mishaal:

hundreds of millions of regular users.

Mishaal:

It's complicated.

Mishaal:

There's so many considerations that they have to deal with that you

Mishaal:

don't really have to care about.

Mishaal:

If you're only designing a platform that's for a specific use case, if you

Mishaal:

are able to own the OS image, like if you're developing your own AOS P build

Mishaal:

for your own devices, and therefore you're able to bundle your own app store.

Mishaal:

Then you can bypass a lot of Google's or Android security restrictions

Mishaal:

on third party app installers.

Mishaal:

And this is one of the things that Google does for the benefit

Mishaal:

of the overall ecosystem.

Mishaal:

But if you can develop your own operating system based on a O S P, then

Mishaal:

you don't have to really consider the security implications of that because

Mishaal:

you can whitelist your own app store.

Mishaal:

You can grant it all the remissions that Google play store might have access.

Mishaal:

Without this permission, though, if you're a regular third party app

Mishaal:

store running on a Android device that you can buy off the shelf.

Mishaal:

Then you can't install apps on your own without holding the request,

Mishaal:

install, packages, permission, and that's the permission that's shown to

Mishaal:

the user it's install, unknown apps.

Mishaal:

What it does is it allows an app to send an intent to the system package

Mishaal:

installer, or to use the session based package installer, API, to

Mishaal:

request users, to grant approval for app installs, which is why the

Mishaal:

permission name has request in its name.

Mishaal:

So when you use.

Mishaal:

API, the user has to actually grant their approval for each and every

Mishaal:

installation and subsequent update.

Mishaal:

And that can be a real pain when they wanna do batch installations

Mishaal:

or batch updates of apps.

Mishaal:

So privileged system apps like Google play store on all GMs devices

Mishaal:

or whatever apps store you pre-B bundle on the device can request the

Mishaal:

install, packages and delete packages.

Mishaal:

Permiss.

Mishaal:

To be able to fully unattended, installs and uninstalls on first installs and

Mishaal:

all subsequent app updates, but that's not attainable by user apps unless, you

Mishaal:

know, the user app is able to gain route access, which is not possible unless the

Mishaal:

boot load is unlocked on most devices.

Mishaal:

There is.

Mishaal:

However, one way that third party app stores can do unattended updates.

Mishaal:

And you did mention this before Logan, when you were talking about

Mishaal:

a Crescent and it's through a new API that was introduced in Android.

Mishaal:

So I wanted to ask you, can you explain what this API, this new feature in Android

Mishaal:

12 does and like, how does it exactly.

Mishaal:

Yes.

Mishaal:

So

Logan:

Crescent does use that API, Android 12 introduced this API that

Logan:

allows app stores to update apps without requesting user permission all the time.

Logan:

And the way it works is with this concept called the installer of record.

Logan:

So say AC Crescent, installs, secure chat again.

Logan:

Crescent is then marked as the installer of record for secure chat.

Logan:

When it first installs it, it brings up the normal package prompt.

Logan:

Do you want to install this app by the OS, but once you grant

Logan:

consent, then in this case, Crescent is allowed to update secure chat

Logan:

automatically without asking the user.

Logan:

And this works in tandem with other Android security features like downgrade

Logan:

protection and signature pining, making sure that it's signed by the same

Logan:

developer and that you can't downgrade it.

Logan:

So that's what a Crescent does.

Logan:

The privileged permissions you were talking about, like you said, they don't

Logan:

ask for user permission, but what's nice about the Android 12 unattended update

Logan:

permission is that's not privileged.

Logan:

You don't have to whitelist an app in your operating system.

Logan:

You can use it on any Android 12 and up device.

Logan:

That's basically how that API works.

Mishaal:

And, uh, fun fact, this whole API, this feature directly came about

Mishaal:

as a result of epic lawsuit against Google, as well as all the antitrust

Mishaal:

scrutiny that Google has been facing.

Mishaal:

If it weren't for all that scrutiny Google's been having lately, then

Mishaal:

we wouldn't have this feature or the reduction in the revenue sharing fee.

Mishaal:

So.

Mishaal:

Developers.

Mishaal:

It is really important that you keep an eye out and you watch what's happening

Mishaal:

with these lawsuits and these regulations around the world, because they're

Mishaal:

having a direct impact on the operating system and the ecosystem as a whole.

Mishaal:

They're really important, even though there's a lot of legalese and a lot of

Mishaal:

politicing back and forth, but yeah, I definitely keep an eye out on all that.

Mishaal:

If you're developing an app store, I'm sure you probably don't really

Mishaal:

consider the politics behind it.

Mishaal:

If you're just actually a developer working on the backend.

Mishaal:

But what you do care about is how do you deal with the bandwidth and storage

Mishaal:

needs of serving apps to millions of users and actually storing those apps

Mishaal:

on a server when you're at Google scale, this is a very, very important discussion

Mishaal:

to have because everybody optimization.

Mishaal:

Both on the service side to reduce storage and bandwidth and on the

Mishaal:

delivery end to improve, download speeds for users and thus user retention.

Mishaal:

There was a story I remember, I think it was in 2017.

Mishaal:

When in Google intern introduced the more efficient compression

Mishaal:

method called Broley.

Mishaal:

It was used for both OS system updates and also APK files themselves.

Mishaal:

And I was surprised by the number that Google shared.

Mishaal:

It saves them about 1.5 petabytes of data per day, just by switching

Mishaal:

to a more efficient compression.

Mishaal:

Just being able to switch one little one correction method, apply that

Mishaal:

to all the apps that they apps that they serve to save so much data and

Mishaal:

thus reduce bandwidth costs on both.

Mishaal:

That's something that, you know, it's kind of like a backend thing that

Mishaal:

most users will never most users and developers will never have to consider.

Mishaal:

But one thing that I'm sure most developers are familiar with, and at

Mishaal:

least a lot of users are, have heard of is what Logan brought up before the whole

Mishaal:

split APKs and or app bundles feature and how it's delivered to users through

Mishaal:

the Google play feature delivery feature, which used to be called dynamic delivery.

Mishaal:

This is both a really neat feature and also pretty contr.

Mishaal:

Which lo alluded to earlier and I'll get into in a second.

Mishaal:

So for those of you who don't know the idea behind the split APK and, and

Mishaal:

or at bundle is that most users don't need to have installed a monolithic

Mishaal:

APK file that contains every asset code chunk and language resource.

Mishaal:

Instead, you only need the bare minimum to get the app and its core features starting

Mishaal:

all that's contained within the base PK.

Mishaal:

And then Google play can push the remaining split APK files that contain the

Mishaal:

assets, features and language, resources that are actually needed by the user.

Mishaal:

So for example, if your assistant language set to English, then

Mishaal:

you'll get the split APK file that contains English language strings.

Mishaal:

You won't get the French language strings cuz you don't need that.

Mishaal:

So this concept is actually quite old.

Mishaal:

It's older than thera.

Mishaal:

Split a BKS were introduced with Android 5.0, but a lot of developers

Mishaal:

didn't really make use of them until the Android app bundle requirement

Mishaal:

came into effect in August, 2021.

Mishaal:

So starting August, 2021, every new app that's uploaded to Google play has

Mishaal:

to use the Android app bundle format.

Mishaal:

The bundle format was introduced with Android.

Mishaal:

And to explain a bit about what it is.

Mishaal:

It's also a valid zip file, just like APKs.

Mishaal:

So within this AAB file, you have all the resources, assets, and

Mishaal:

libraries that are needed to generate multiple configurations of the app.

Mishaal:

And it's structured in a way so that you have all of these segments kind of a

Mishaal:

segment apart from each other, you have a base module, you have dynamic feature

Mishaal:

packs and you have asset packs that this tool called bundle tool uses to generate

Mishaal:

specific split APK configurations.

Mishaal:

So what developers do is they generate the Android app bundle file in Android studio.

Mishaal:

They upload that to Google play and then Google play generates split APK files on

Mishaal:

demand when the user downloads the app.

Mishaal:

So this has a potential to save users, a lot of storage space on

Mishaal:

APKs and also thus reduce how much bandwidth is needed to download.

Mishaal:

So while the idea behind this is sound, you've mentioned Logan, that there are

Mishaal:

some issues with how it's implemented.

Mishaal:

Can you explain what some of those concerns are and what

Mishaal:

Google's done to address them?

Mishaal:

If anything.

Mishaal:

There are a few

Logan:

valid concerns with not necessarily app bundles themselves, but

Logan:

the implications of how they're used.

Logan:

So Google play uses this feature called play app signing.

Logan:

And so you upload your app bundle and then Google will sign and

Logan:

generate the APKs themselves.

Logan:

As we talked about earlier, the Android operating system.

Logan:

Will pin the signing keys of those AP case.

Logan:

But in this case, it's Google, who's signing them.

Logan:

And so theoretically, Google could modify the APK and deliver a

Logan:

malicious update either intentionally or after being compromised.

Logan:

And so that's one big concern with, uh, app bundles.

Logan:

They've mitigated this somewhat with this feature called code transparency.

Logan:

How that works is a developer can generate this separate signature

Logan:

file and upload it to the play store.

Logan:

And users can download that and make sure that the APK that they get was

Logan:

generated from the app bundle that the developer made, but it's not a perfect

Logan:

solution for one, the developer has to choose to generate this and upload it.

Logan:

Then the user has to download it themselves and verify it themselves,

Logan:

which already cuts out a lot of people.

Logan:

Most people aren't gonna try to do that for every single app.

Logan:

They.

Logan:

Another problem is it doesn't verify the entire file code transparency

Logan:

doesn't verify the entire APK.

Logan:

And so things like resources could still be modified, which could be

Logan:

used to change the UI or something and trick the user into doing

Logan:

something that they don't intend to.

Logan:

Those are a couple of the concerns.

Logan:

The way Crescent works around this is that developers upload

Logan:

the split APKs themselves.

Logan:

The tool that Google uses to generate split APKs is freely

Logan:

available and open source, and you can download it and use it yourself.

Logan:

And so AC Crescent allows developers to do that and just upload the split APKs.

Logan:

And so they can still be used without the trust issues with app bundles.

Logan:

To be fair to Google.

Logan:

They do a very good job of this and they're handling these keys.

Logan:

They have a whole white paper on their infrastructure, and there

Logan:

are legitimate reasons for it.

Logan:

For example, I didn't learn this until recently, but developers

Logan:

often lose their signing keys.

Logan:

Once you lose your signing.

Logan:

Key, the OS won't accept updates with a different signing key.

Logan:

If you didn't rotate it right.

Logan:

And so if you lose your signing key, all of your users are left

Logan:

in the dark without an update.

Logan:

Whereas with Google play, if you lose your upload key, which you have

Logan:

to use to authenticate yourself, Google still has the signing key.

Logan:

So they can just generate a new one for your account and you can

Logan:

still deliver updates as normal.

Logan:

So there are benefits to it, but there are definite security and trust drawback.

Mishaal:

What about the challenges this whole play app signing introduces

Mishaal:

when it comes to distributing apps across multiple app stores, like

Mishaal:

since Google is signing the apps that get delivered to your device, right?

Mishaal:

If you were to take that app, And you were to try to say you had Samsung

Mishaal:

galaxy app store installed as well.

Mishaal:

And you tried to install an update that was already available through Samsung's

Mishaal:

galaxy app store for the same exact app you wouldn't be able to because the

Mishaal:

app that's uploaded to Samsung store is signed with a different key than

Mishaal:

the one that's uploaded to Google play.

Mishaal:

Can you talk a bit about that?

Mishaal:

That's

Logan:

partially a store concern and partially a developer concern.

Logan:

Generally speaking, if you have an app that's being signed with

Logan:

different keys, say for Google play and say, you're really seeking it on

Logan:

GI Huber, your website or something.

Logan:

If you're not using the same key,

Mishaal:

you should

Logan:

change the app ID, which is basically just an internal

Logan:

identifier to make an app uniquely identifiable to the operating system.

Logan:

I know I keep bringing it up, but for example, Graphos

Logan:

does this with their camera.

Logan:

There's a version.

Logan:

They sign themselves and the version that Google signs.

Logan:

And so they have different app IDs, so they can both be installed at

Logan:

the same time without conflicting.

Logan:

So that's generally what developers should do.

Logan:

If they're uploading to multiple stores that are signing with different

Logan:

keys, they should change the app ID.

Logan:

So they don't conflict.

Logan:

But many aren't aware of that.

Logan:

And so that does cause a challenge, especially for apps that are say

Logan:

on both Google play and F Android since F Android signs with their own

Logan:

keys, but doesn't change the app ID.

Logan:

They conflict with Google play versions, and you can't have both

Logan:

installed at the same time or use one to update to the other.

Mishaal:

I've talked about this before, but the Android app bundle, there's

Mishaal:

a lot of clear and obvious benefits.

Mishaal:

It brings to both Google and to users when it comes to storage and bandwidth.

Mishaal:

But it's hard not to have like a cynical view.

Mishaal:

Oh, how does this lock users more into the Google play ecosystem?

Mishaal:

Like, is it a coincidence that it has these benefits?

Mishaal:

You tell me because , I'm sure many people will think that there's

Mishaal:

no coincidence that, you know, it has this benefit of doing that.

Mishaal:

But to be fair, there are some rather unique things that can be done with

Mishaal:

Android app bundles that you can't do easily with the monolithic KPK.

Mishaal:

So, for example, at the beginning of this year, Google announced the

Mishaal:

new feature that Google play will be getting called app archiving.

Mishaal:

So basically what this does is that Google will be using the bundle that

Mishaal:

delivers upload to generate a new split APK file called an archived APK.

Mishaal:

So this archived APK is basically a.

Mishaal:

That holds nothing but code to launch the app store to redownload the full app.

Mishaal:

So this stub basically has nothing in it.

Mishaal:

It's just an empty app.

Mishaal:

That's signed by the same key because Google signed it.

Mishaal:

It has the app icon.

Mishaal:

Because it's actually still installed on your device, but it

Mishaal:

has like no resources, no nothing.

Mishaal:

It's basically like a multi kilobyte file instead of like the tens, potentially

Mishaal:

hundreds of megabytes file that the original app was using up on your device.

Mishaal:

So by introducing this app, archiving feature users will be able to archive an

Mishaal:

app and reduce its storage requirements without actually uninstalling the.

Mishaal:

And if you're interested in learning more about that, by the way, I did a

Mishaal:

deep dive on the Android buys column.

Mishaal:

I, I think that's quite an interesting feature.

Mishaal:

And I'm really curious to see if other app stores actually replicate this.

Mishaal:

Like Google did design it in such a way that other app stores could replicate it.

Mishaal:

But again, like the whole permissions data, the permission safety form

Mishaal:

stuff, I don't really know if any alarm stores actually follow

Mishaal:

through and do what Google's doing and all, everything they're doing.

Mishaal:

But before we close off this discussion, cuz we're getting close to time.

Mishaal:

I wanted to bring up a prime example.

Mishaal:

Of a market where non Google play app distribution is successful.

Mishaal:

And that's China, China, for those of you who don't know, does not allow

Mishaal:

access to any Google services, the fact that Chinese Android users are using

Mishaal:

non Google play app repository is more out of necessity than anything else.

Mishaal:

So from what I've heard, speaking to Chinese users and reading online is

Mishaal:

that Chinese users source APKs from a multitude of app stores, a multitude

Mishaal:

of websites, many third party app posting websites, and more like, it's a

Mishaal:

huge mess of where they get apps from.

Mishaal:

It's it's really decentralized and that's actually, you know, Kind of the model

Mishaal:

that desktop users have been dealing with for a long time, the decentralization,

Mishaal:

but without that centralized, Google play and GMs providing those APIs, the Chinese

Mishaal:

market kind of struggles to deal with things like push notifications, whether

Mishaal:

like 13 different push notification APIs, which requires like, if you

Mishaal:

have 13 different apps, all using different push notification implement.

Mishaal:

Then that means you have 13 different apps having these foreground services,

Mishaal:

constantly waiting for push notifications to be pushed to your device and that

Mishaal:

results in a whole bunch of apps waking up at various random times and

Mishaal:

then destroying your battery life.

Mishaal:

So if you're wondering why a lot of Chinese phone brands seem to

Mishaal:

have these really, really, really aggressive battery saving measure.

Mishaal:

It's a result of this because there's no unified centralized, Google play services.

Mishaal:

Like there is outside of China, knowing what you know about

Mishaal:

how the situation is in China.

Mishaal:

Do you prefer the centralized model we have now with Google?

Mishaal:

Or do you think a fully decentralized approach would be better or

Mishaal:

maybe something in between.

Mishaal:

At

Logan:

a high level, I would say the decentralized approach

Logan:

could be better, but it won't be.

Logan:

And the reason I say that is because when you have multiple parties

Logan:

providing updates to their own mechanisms, a lot of them aren't

Logan:

doing it well or doing it right.

Logan:

Like we've seen how a Google play store, although this largely due to GMs the

Logan:

place where actually does security evaluations, they do app distribution.

Logan:

Very, very well.

Logan:

It's hard to make sure that those same restrictions, uh, security and

Logan:

privacy are being enforced across all these different mechanisms.

Logan:

And most app developers won't make sure updates are delivered securely

Logan:

and timely and automatically.

Logan:

And so that's why I would say the decentralized approach could be better,

Logan:

but it won't be say, if you have an app that updates itself, that's like

Logan:

the ideal situation you can have, but most developers won't want to do that.

Logan:

It's extra work and it's hard to do.

Logan:

Decentralization in the sense of say one app updating from multiple different

Logan:

places actually violates Android security model there's security model mandates

Logan:

that one app store is just one app source.

Logan:

It downloads apps from one place, and there are problems

Logan:

if you try to change that.

Logan:

And then there's also a problem.

Logan:

If you're downloading from multiple servers with the same app, say like, does

Logan:

you can't use certain security features like TLS certificate pinning that would.

Logan:

How I would evaluate the overall situation.

Logan:

Centralization is unfortunate in some ways, but I think if the centralized

Logan:

party knows how to do things well, I would say Google does, then the

Logan:

situation would be much better.

Logan:

In that case, you don't have to trust as many parties to do the right thing.

Logan:

Right.

Mishaal:

And fortunately, you know, Android isn't as locked down as iOS,

Mishaal:

where you have no choice between centralization and decentralized.

Mishaal:

It's all centralized all the time.

Mishaal:

At least with Android.

Mishaal:

99% is through Google play, but that 1% outside of China, at least you

Mishaal:

have the freedom to choose what apps and what app stores you're using.

Mishaal:

And of course, since a S P itself is open.

Mishaal:

You also have the freedom to customize a O S P.

Mishaal:

And then build in your own app distribution ecosystem to that

Mishaal:

distribution and to the devices that you are deploying this build on,

Mishaal:

which of course is really important because a S P as I said before, does

Mishaal:

not come with an app store by default.

Mishaal:

So you have to do something custom.

Mishaal:

If you're going to build a O S P without GMs.

David:

App distribution is actually something that is very near and dear

David:

toper, you might even say it's kind of the core of our business in a lot

David:

of ways, because what Esper does every day is deliver applications and updates

David:

to applications, to dedicated devices, which are things like kiosks business

David:

tablets, things that typically don't have Google mobile services to begin with.

David:

And wouldn't have a reason to other than having a way to.

David:

Apps, but obviously that's not a good solution for a lot of reasons, for a lot

David:

of different kinds of devices, some of which are cost, some of which are time,

David:

some of which are engineering effort.

David:

I mean, all of those things generally are true.

David:

Being a GMs partner versus using AOS.

David:

P.

David:

So if you're using a O S P to build a kiosk or to build a point of sale or

David:

to build display, signage, whatever, it might be a medical device, perhaps

David:

home exercise equipment, we're literally on a climbing machine.

David:

You need a way to deploy updated APKs to that Android device.

David:

And if you don't have the play store, that's a little easier said than done

David:

at scale, easy to do with a few dozen.

David:

And once you get to a few hundred, few thousand tens of thousands of

David:

devices, That gets pretty hard.

David:

And so what Asper provides along with our robust device management tools

David:

is a really, really sophisticated way to deploy your apps, stage updates,

David:

group them choose when and where they go out, set conditions for success.

David:

You.

David:

And deploy your app in a way that is highly observable and where

David:

you know exactly where it's going.

David:

You know, every device that's received it, every device that

David:

hasn't, you're getting exception reports when something goes wrong.

David:

So if you've been wondering how you can deploy applications to Android devices

David:

in a really specific, targeted, highly reliable way with an enterprise grade QoS,

David:

come talk to us at SPER we're at SPER dot.

David:

I.

Mishaal:

Thanks David, for the obligatory per plug in the Android bites podcast.

Mishaal:

And of course, here's the obligatory closing segment of the podcast where

Mishaal:

I give our guests the opportunity to explain where can you follow him online?

Mishaal:

So Logan, where can people find you and your work?

Mishaal:

You can find

Logan:

me on Twitter and on GitHub as Berry ma that's my

Logan:

handle on most other places.

Logan:

And then Crescent is on github.com/crescent, ACC, R E S C E

Mishaal:

NT.

Mishaal:

And you can find David and I on ESER that's blog.sper.io.

Mishaal:

And thank you all again for listening to another episode of Android bites.

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.