August 1, 2022 • 48 mins
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:
- Esper Blog
- Mobile Device Management (MDM) Guide
- Android MDM Guide
- iOS MDM Guide
- MDM Solutions
- MDM APIs & SDK
New from the Esper blog:
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
David (00:02):
Hello, and welcome to Android bites powered by Asper I'm David Ruddick.
And each week I'm joined by mycohost Michelle ramen diving deep
into the world of Android this week.
We're talking about apps and really appstores actually, which is a topic on
Android that obviously has a historyas long as the platform itself and
allow Michelle to introduce our guests.
Mishaal (00:23):
This.
Thanks David.
So on today's show, wehave invited Logan McGee.
He's an independent developer.
He's working on a project called Crescent.
So thanks for joining us, Logan.
Thank you for having me.
Okay.
And as David mentioned, we wanna talkabout apps, more specifically, app
stores and app distribution in a O S P.
You don't have an app store by default.
You have no way to actually get apps.
(00:45):
And if you install a pure,fresh AOSP build, you gotta
find and procure apps on your.
I was actually reading an interestingarticle earlier today on L w N I
don't know if you subscribed to thatwebsite or not, but they're basically
like a newsletter that covers Linux.
And they talked about way Android, whichis a project we've actually talked about
before on the show way back when wewere actually doing the Twitter spaces.
(01:06):
So way droid for those you don't know is asoftware project that enables running the
entire Android user space and a container.
It's a really interesting andneat project, especially if you
have a Linux smartphone like thepine phone, and you wanna run
Android apps because there's not.
Native Linux optimized apps forsmartphones, but it like any other non
GMs, a O S P project has the same issue.
(01:28):
Where do users get their apps from?
Of course, if you're a privacy conscioususer, you've probably heard of various
app repositories, like fro you know howto procure APKs off of various websites.
But as an ecosystem, this is ahuge challenge because you can't
assume that every user has thesame technical capabilities as
your average Linux developer, does.
(01:48):
You gotta assume that most users aregonna want to, or they're gonna expect
that there's an app store on their deviceand they're gonna click that and they're
gonna download everything and everything'sgonna be handled for them all easy peasy.
That's why most OEMs major companies, theygo through the process of licensing GMs,
which if you, um, listen to our podcast,our previous podcast with the execs from
awesome, you know, that's a pretty arduoustask, but most OEMs go through it anyways,
(02:12):
because it's absolutely necessary fortheir users, which consists of millions
of average people to have access to theplay store and Google play services,
which ensures not only do they haveaccess to millions of Android apps, but
also the APIs that many of them depend.
And because so many apps have GMsdependencies, it's pretty much
impossible to talk about alternativeapp distribution models on Android
(02:32):
without factoring in where GMs comes in.
So if a device has GMs, then it'smostly just a matter of where
do you source the apps from?
Is it from Google play storeor is it from somewhere else?
You're not gonna have that many problemsunless you're dealing with like paid apps.
If a device doesn't have GMs, though,then you need to take extra steps to make
sure that the app that you're trying to.
We'll actually run on your devicebecause a lot of apps, like I said, have
(02:53):
dependencies on GMs, including things likesafety net at station fireplace, cloud
messaging for push notifications, theGoogle maps, API for mapping, et cetera.
But thankfully at least since a S Pis open and supports side loading,
other apps stores that aren't bundledwith the OS image, you know, it is
possible to actually have alternativeapp repositories that don't really
(03:13):
care about what's going on with GMs.
Fro is one example that Imentioned the graph OS project.
They recently released their own quoteunquote app store, which is basically
just like a website that has some oftheir apps that you need to set up their
sandbox, Google play implementation.
If you haven't listened to our graph OSepisode, I'd recommend go doing that.
So that's basically what anapp store really boils down to.
It's just a browsable catalog ofapps that users can download install.
(03:37):
So if you're thinking aboutdesigning your own app store and
distributing apps on Android, youneed to answer these questions.
How do you connect usersto that catalog of apps?
How do you get legitimateapps onto the catalog while
weeding out illegitimate ones?
How do you securely and efficientlystore and distribute apps to users?
And how do you handledistributing app update?
None of these are straightforwardthings to solve, but fortunately
(04:00):
we have over a decade of history oflooking at what Google play has done.
So we can basically take a lookand see what does it take to go
about designing your own app storeto distribute apps on Android.
But before we dive into the meatof this discussion, I wanted to ask
both of you for your overall thoughtsand experiences of using other app.
Such as you know, Wawa's appgallery, Samsung's galaxy
(04:20):
store F Android, et cetera.
Have you ever used an Android phonewithout GMs and exclusively had to
get apps from outside of Google play?
And what was it like?
Have you used an Android phonewith GMs, but still chose to get
apps from outside of Google play?
Or have you done a mix ofboth play and non Google play?
Logan (04:36):
Personally I used Graphos as recently, actually, so that doesn't
have GMs installed by default.
And so for a while, I was tryingto get apps from other places like
GitHub releases or fro, and honestlyit was kind of painful to deal with.
And so eventually I actually started usingGMs through their sandbox, Google play
(04:58):
compatibility layer, just because it iskind of a pain to get apps on Android.
If you don't have GM.
David (05:04):
My history with various app stores.
I mean the most prominent one and theone that I probably use the most would
be actually the Amazon app store, whichwas such an interesting experiment.
I mean, it's still, obviouslyvery active, used by tens of
millions of people who own Kindle.
Fire tablets.
But I remember the challenges Amazondealt with in terms of simply like
(05:27):
keeping apps up to date with their Googleplay counterparts fact that the Kindle
fire devices ran an older OS version.
I believe the Kindle fires initiallylaunched based on ice cream sandwich
initially back in the day, correctme if I'm wrong there, but it was
a different time and it was stilla time when legitimately you could.
(05:47):
Somebody may be trying totake a step at Google play.
And Amazon threw money at developers,especially game developers with all
this in-app currency promotion stuff.
And they threw money at advertisingto try to get people excited about it.
And it underscored to me thatthe usefulness of an app store.
Is really dependent on what kind ofwalls are put up around that device.
(06:11):
And in Amazon's case, it was, youcould not easily install, play, or
a GMs applications on those devices.
And they've continuously, youknow, I'm not saying they made it
harder, but they fixed loopholes.
And obviously Google doesn't wantthem to work very well either.
And of course I've used Chinese phonesfrom so many OEMs that don't ship a GMs.
I even back in the day, received areview unit from a smartphone OEM.
(06:34):
And I'm sure Michelle you'veexperienced this as well.
It came with an application on it,specifically designed to display a
WebApp view that linked to the filesyou needed to download the core GMs
bits and then install them as thoughit was like they called it the Google
installer, I think, on this device.
So, yeah, it's just hardto imagine a mass market.
(06:57):
App store that could de throwGoogle play at this point.
And Amazon did try.
So that then begs the question.
The need for specialty appstores is probably there.
And what kind ofspecialties will they have?
And that's always been interesting tome, especially since I worked at Android
police until Valette bought Android.
Police is the sister side of AP came.
(07:18):
Dot com.
So I'm aware of things involvingAndroid app distribution, to some
Mishaal (07:24):
extent.
Yeah.
So if you're going to go about designingan app store or app repository of
like APK mirror, well, APK mirroris a special exception because it's
not really designed to actually getpeople to use it as like an app store.
It's just basically a APK backupposting site for the most part.
But if you're going to design an appstore that you actually want users to
(07:45):
use, you need to answer the question.
How are you gonna get itinto the hands of users?
Obviously on many devicesout in the market, you don't
have access to the OS image.
So you don't have the ability tobundle your app store with the device.
If you are a business and you want tohave a small selection of apps that
you want your employees to access,and you know, you're going to buy a
(08:06):
whole bunch of GMs, Android devices.
Then you could pretty much skip thisentirety of this discussion and just
use something like managed Google play,which is like a small island of apps that
are only available for these devices.
And those are the only apps they can use.
But if you're not going to be doing that,if you want to ship a device without
GMs, then you're going to find anotherway to get your app store onto devices.
(08:30):
So you could either direct users to awebsite, which is the lowest hanging
fruit, or you could create an app thatconnects to your own customer repository
backend, or you could piggyback onexisting solution, like say creating
a repo and then using an fro clientcustomized or not to connect to it
rather than the main FOID repository.
So if you set up a device to be enterprisemanaged from the get go, like through
(08:52):
our SPER device management platform,then it's easy to push something.
And install apps and update them.
If you build the firmwareyourself, which is something
we can also do with foundation.
I know, I know I gotta stop plugging here.
We'll do that later with David, thenthe app store app could also be bundled
with the OS image, and then you couldalso automate app installs and updates
and have them be unintended updates.
(09:13):
So otherwise, if you can't do any of thosethings, you need to have the user manually
seek out your repository, which requiresthem knowing it exists in the first place,
and then requires them to manually accept,installing and updating the apps in most.
So, I guess this is the perfecttime to segue into talking about
the app store that you're creating.
Logan.
Can you give us a brief introductionto Crescent and why you're building it?
(09:34):
How will users access it?
And what are your plans tospread the word about it?
Once it launch.
Yes.
Logan (09:39):
So Crescent is, uh, an in progress app store.
I'm currently building, that'smainly focused on security,
privacy, and usability.
It works kind of similar to the playstore in that it allows developers to.
Upload apps that they have compiledthemselves, but it's different
in that it doesn't require themto give up their signing keys.
(10:01):
They don't have to upload an appbundle with their signing keys or have
Google generate signing keys for them.
So they generate the split AKs themselveslocally and then upload them to Crescent.
So Crescent still has all of thebenefits of split APKs without the
downsides of trust and security.
it also does something kind ofneat regarding app signatures.
(10:23):
And so it has this signedpiece of repository metadata.
The store is really justa static web server.
And so it uses that metadata toverify that apps downloaded are
signed by who they're supposed to be.
So even if the server was taken overby an attacker or something, uh,
users who download apps will knowfor sure that the apps they download.
(10:47):
Are, um, developed bywho they say they are.
Um, but it also focuseson privacy in some ways.
Uh, it doesn't sendany device identifiers.
It doesn't need to,right now it just sends.
Like the device architecture, uh,screen density and primary language,
and it needs that to fetch split APKs.
(11:09):
And another reason building aCrescent was for usability, right?
I'm sure a lot of people have hadproblems with say, uh, on Android, you
have to manually accept and installevery single time you update an app.
Whereas AC Crescent uses some modernAPIs to allow you to update them.
In the background withoutuser interaction, but without
compromising on security.
So those are a couple of thethings that Crescent does to
(11:30):
ensure better user security andprivacy or existing solutions.
Mishaal (11:35):
Thanks for the rundown Logan.
So you brought up a lot of thingsthat I kind of wanna touch on in a
bit, especially like split it, BKSAndroid, app bundles, et cetera.
Some of our listeners may notbe familiar with these concepts,
but before we actually dive intoconsiderations that you need to make
to get apps onto a store, I wantedto talk a bit about Android security
model when it comes to applications.
So every app that you install on anAndroid device comes in a file format
(11:58):
called an Android package or APK file.
An APK is a self-containedarchive, which is essentially a
derivative of Java archives or jar.
But with a few Androidspecific additions to it.
So the jar file format is itself based onthe popular zip format, which, you know,
if you ever use the desktop computer,zip it's that handy archive file format,
(12:19):
where you store a bunch of files andcompress it and it saves you space.
And since jar is based on zip.
APK by extension is as well, which iswhy you can open up APK files and see
what's inside them using something likeseven zip on windows or other platforms.
So within the APK file, there's severalkey Android specific components.
Namely the Android manifest, whichcontains the apps metadata, including
(12:42):
what components it supports, whatcomponents it has, what permissions
it requests and other various.
Things that it needs like librariesthat might require there's also the DAIC
executable bike code files, which hasthe apps code for the JVM to interpret.
Then there's the resource catalog, whichis like, uh, resources.ar SC, and then
(13:04):
the actual resources that they map to.
Then there's unmanaged resources,which are also called assets and then
optionally some native libraries.
There's also a digital signature, whichis inherited in part from the jar format.
And that digital signature is generatedwhenever the developer signs, the
application package using a signing key.
So every app is installed ontoa device, gets a unique, or
(13:25):
has a unique package name.
Developers can technically givewhatever package name they want
to their application, but Androidwill reject the insulation of.
That has a package name matchingan existing app that's installed
on the device provided thatapp's digital signature doesn't
match the existing apps this way.
If you have one app installed a developer,can't just say, I want my app to have
(13:46):
the same package name, and then try toinstall on top of that existing one.
That's one of the key partsof Android security model
when it comes to applications.
And since the signing key used to generatean app's digital signature is generally
assumed to be kept private and secure, youknow, somewhere where only the developer
who signs the app has access to or in,uh, Google play's case, Google themselves.
(14:06):
It's generally assumed that onlythe app's original developers or
Google will be able to push updatesto existing apps that Android will.
This is how Android securely updates apps.
So I've done a bit ofoversimplification here.
APKs, don't actually use likethe exact same digital signature
implementation that you see in jar files.
They've evolved over time to havelike a proprietary implementation.
(14:30):
There's various implementationscalled the APK signature schemes.
And I wanted to ask you Logan, ifyou can explain to our listeners
a bit about these, a signatureschemes, like what does the signature
scheme V3 bring to the table?
For example?
APK signature
Logan (14:43):
scheme three is a slight improvement over V2, which is what
replaced the legacy jar signingyou were just talking about
and V3 allows for key rotation.
So that means if a developer hasa certain signing key and they
might suspect it's compromised.
For example, they can sign a new keywith their old key and then make that new
(15:04):
key, the new trusted key for that app.
So they.
Migrate away from old keys to avoidcompromise without having to make the
user uninstall and reinstall their app,which would've been the case before.
There's a couple other newer ones too,like before, which is kind of different.
It's not embedded in the APK itself.
It's in a separate file and that can beused for this feature called Fs Verity.
(15:28):
I don't wanna get too technical about it.
Essentially what Fs Verity does.
And what V four signatures allow isfor the OS to cryptographically verify
an, a PK every single time you launchit, or every single time it's read by
the operating system, which is veryhelpful for reducing persistence.
I believe the Google play store uses.
Before signatures
Mishaal (15:48):
for this reason, he talked about the technical implementation,
but one of the key features that itenables is the app incremental feature.
So I think, uh, I forgot whatthe marketing name is for it.
I think plays you download.
Yeah.
That's what it's called.
So Android 12 Google introduced plays,you download, which basically lets
you start playing a game while alot of it's assets are still being.
(16:09):
So because the signature isseparate from the actual APK, it's
able to be verified as the bulkof it's still being downloaded.
So that's one of the features thatV4 Napes and which is why it's not
really mandatory to support yet.
Whereas V3 is a much more significantimprovement in terms of security.
So I wanted to ask you next, arethere any flaws in this Android
(16:30):
security model when it comes to appsigning and app distribution, and how
does a Christian plan to deal with.
Yes, sort of, I wouldn't necessarily
Logan (16:39):
call it a flaw.
It's more of a design decision,but the way Android works with app
signatures is the first time youinstall it, it pins that signing key.
So say you install an appcalled secure chat or something.
I install that.
And then the Android operatingsystem parses it and finds the
signature and says, okay, thisis the key that sign this app.
(17:00):
And I will not accept any updatesif they're not signed by this.
And so that securesupdates later on, right.
But that doesn't helpwith the first install.
If you install a maliciousversion of that app, then it'll
updates that are legitimate.
And presumably you'll be gettingupdates that are malicious and
Android doesn't really do anythingitself to solve this problem.
(17:21):
It just leaves that upto the application layer.
What a Crescent does to solve.
This is when you uploadan app to the store.
Or whoever maintains theirrepository will sign their key
to validate basically to the app.
This is the signing key.
We will accept for this app.
The Crescent will only acceptthis signing key for this app.
(17:43):
And so that means the first time youinstall it, you can know for certain that
you are installing the legitimate versionof that app, and it can't be replaced with
a malicious version or something, even ifthe server was taken over, if that makes
Mishaal (17:55):
sense.
Gotcha.
Yeah.
I mean, that is a big problem.
Like figuring out how to installthe legitimate version of an app,
especially when there's so manyclones and copycats out there.
And so many different ways toside load apps or trick users
into side loading apps that seemlegitimate, but they're actually not.
And once they have it, how do they knowit's actually the real deal or not?
And many times they don't.
(18:16):
That is one, as you mentioned, it'snot really a, a flaw, more like a
intentional design decision, andthere are solutions to mitigate that.
But one of the, I'd say key failuresof most app stores is actually
getting developers on board.
And I think this is one of the areaswhere why so many people don't even
bother trying to make an app store.
(18:37):
So kudos to you attempting to do that.
. For those of you who, uh, aren'tfamiliar with this major chicken egg
problem, you have an app store, right?
What you need to do is youneed to get apps on board.
So you need to getdevelopers to upload their.
But the problem is developers.
Aren't going to do that.
If there aren't users who areusing your app store, because
after all, most developers want tomake money off their applications.
(18:58):
You know, they need to earn a living orsell a product or do something with it.
So if there aren't users, then theyaren't going to be making any money.
And if there aren't any apps, there'snot going to be any developers.
So it's just a vicious cycle that kindof ensures that most burgeoning app
stores don't ever really take off.
And it's why even app stores createdby the biggest tech companies
on the planet, just pale incomparison to Google's play store.
(19:21):
There are a couple of things that Googleplay does particularly really well and
what others have attempted to copy inorder to get developers, to actually
upload their apps and share them there.
So Google play, for example, they offerpretty robust tools around handling
rollouts and managing your storefront.
And then offering various ways topromote your apps within Google
play outside of Google play.
(19:42):
Other app stores try to offer lucrativerevenue, sharing fees, much lower
than Google, but still, if you'retrying to launch an app store and
you want to compete with Googleplay, that's a really hard sell.
But if you are trying to just launch anapp store that serves a very specific
purpose, just a handful of users, you knowwhat you're targeting, then you're setting
much more realistic goals for yourself.
(20:03):
But if you're trying to launchvery open app store, that steps.
App submissions by any developeraround the world, and you're
going to deal with the problem.
And it's a problem that pretty muchmost app repositories deal with.
And it's how do you moderate toensure that bad actors aren't
abusing your platform to spreadtheir malicious status, sucking
applications or straight up malware?
(20:24):
and if you're dealing a Google playscale or like Samsung scale, et cetera,
then the answer is, in my opinion, youcan't, I think it's literally impossible
for a company like Google to be ableto thoroughly audit each and every
single app that comes out their door.
There's just too much to deal with.
There are a few things they do, andthey do well and some not so well to
(20:44):
raise the barrier to entry, to ensure.
There aren't as many malicious appsor privacy afflicting apps that
are submitted to the app store.
Like the most basic thing theydo is they require a fee and, you
know, personnel contact information.
When you sign up for developer account.
I don't think it's very effective,but I'm pretty sure that does
stop a lot of bot submissions,Google play, and other app stores.
They also perform static analysisof manifest files to look for
(21:07):
potential violations of privacy.
So for example, Google play is a lot ofpolicies around what permissions and app
can request and how they want to use them.
So if it detects that your app istrying to request the SMS permission,
then Google play will reject your.
If you don't submit a forum andyour app doesn't meet one of the
pre-approved categories of appsthat can request access to SMS.
(21:30):
Google play also does automaticdynamic analysis of apps.
So it analyzes risky code or behaviorsuch as attempts to gain root access
or disabled se Linux play protect.
Does this on GMs devices?
Google play also has human moderatorsto review app submissions and
updates to look for violations.
And finally, Google play alsoforces developers to declare
(21:50):
their use of data permissions.
Although more recently, if you heard thenews, Google play is actually starting to
hide the list of permissions in favor ofthe developers submitted data safety form.
You've all heard the stories.
I don't know if you've ever personallycome across this or dealt with this
before, but you've heard horrorstories about developers dealing with
Google play support or that theirmoderation practices are ineffective,
(22:11):
inconsistent, or straight up incompetent.
And from what I've ever heard, the othermajor app stores aren't really any better.
Do you really think there's anythingGoogle and others could do to improve
the quality of apps and limit thenumber of fake or malicious apps?
Or do you think they're pretty muchjust trying to prevent the dam from.
I
Logan (22:27):
would say similar to what you said, it's very hard
for Google to make the system.
They have work at their massive scale.
It's hard to get frankly, enoughcompetent reviewers and enough
analysis to really prove for surewhether an app is malicious or not.
It's just not reallypossible at that scale.
They are doing quite a few things tohelp though, like reviewing certain
(22:49):
permissions or making sure they'reonly used for legitimate purposes.
For example, there's a legacy filemanagement permission that some apps
request, which basically gives themaccess to manage all of your files.
But sometimes they request that whenthey don't actually need access to
all of 'em, they just need one at atime when they want to send something.
And so that's part of what they can do.
(23:11):
I don't really know howto solve the problem.
On Google side, because honestly Idon't upload apps to the play store.
So I'm not as familiarwith the problems there.
David might have a littlemore insight into that.
David (23:23):
Over the years we received so many meals.
I'm sure you did Michelle as wellfrom developers who were having
problems with basically the contentreview team or content moderation
team on the Google play store.
And there are so many reasonsthat they can reject to.
and often of course, they're reallyterrible at actually explaining the
rejection reason because usuallythe person rejecting you is probably
(23:46):
somebody not making very much money.
And they're working throughas many of these approvals as
they can in a given Workday.
Their goal is volume.
Not quality.
No, you can't just makebetter people for this.
Like you said, that's notreally a scalable solution.
And to me, Google is pulling the leversa can, which are restricting permission
(24:07):
access, making it more stringent, or atleast making the declarations very obvious
when it's something really sensitive,which we're seeing now in Android 13.
And we've seen inprevious Android versions.
And I think that we'll continue to seethat trend and we'll continue to be
upsetting to a particular audience ofhin enthusiasts who don't like that.
Google is clamping down this way.
(24:28):
At the same time, it's hard to see thisbeing a problem that can be solved at
scale without immensely powerful machinelearning and really rigorous controls.
And that just seems to be thedirection Google is heading.
That's how most of their products work.
So I feel like, yeah, thehorror stories from the play
(24:50):
store are really frustrating.
You hear about devs who get delisted fortotally bogus reasons because the reviewer
either didn't understand something about atrademark or copyright complaint, or they
thought there was something in the appthat had changed, but they misunderstood
and seeing that kind of stuff.
And like seeing people'slivelihoods be affected by that.
That sucks at the same time.
(25:12):
Michelle, what you said, I thinkis what I've heard as well,
that there is no app store.
That's good at this.
You hear complaints aboutapple on the app store all the
Logan (25:20):
time.
This is part of why I believeit's a good idea to leverage the
Android security model to enforcethis level of quality control.
For example, the play storerequires that all apps uploaded
must target a certain SDK.
And basically what that means is it'stested on a certain Android version and
the OS enforces certain restrictionsaround that app that typically get
(25:43):
stricter as the Android version goes up.
And so that's one way theycan enforce quality control.
The other one.
Permissions, which they do quite heavily.
Part of it is informing users as well.
So they understand, you know,when I'm giving an app access to
this thing, it has apps don't haveaccess to a whole lot of sensitive
information without user consent.
And so having to rely on the app storeto communicate, that can be helpful.
(26:07):
But part of it is also up to the user.
Mishaal (26:09):
I wanted to ask your thoughts on the growing number of permissions
that seem to be purposely designedso that their actual enforcement
mechanism isn't the Android OSitself, but rather Google play.
And I know like there's alot of permission that says,
oh, app stores may enforce.
The use of this permission, butin actuality, you know, it was
designed around Google play.
(26:29):
So I already mentioned SMS,but there's also call log.
Those two permissions existed a whileago, but I'm seeing more and more
permissions being added with each newOS version and their permission level
might be normal, which means that they'regranted an install time, but then.
There's an asterisk in thedocumentation that says app stores
may restrict this permission.
So I wanted to ask you, do you thinkthat's a good model for Google to
(26:50):
take and do you actually see otherapp stores following through and
actually enforcing these permissions?
Like Google?
I think it can
Logan (26:57):
be a good thing, but I think it's also a hard balancing act.
You don't wanna ask the user forevery little low level permission
that they might understand.
For example, there's the quarry, allpackages permission, which basically
allows an app to list and read allthe apps that you have installed
in your device, which you wouldthink is pretty sensitive stuff.
But the OS doesn't have a mechanismyet to enforce that permission.
(27:22):
Even if you don't have the qualpackages permission, there are
other ways to get around it and listall the apps you have installed.
And so the play store restricts this,but the OS doesn't that specific example
I think could be enforced by the OSlater, but due to how Android works
currently, it's hard to do that withoutbreaking certain app functionality.
Another example is the internet permissiona long time ago, it used to be a dangerous
(27:45):
permission, which means the user had toopt in and allow an app network access.
But Google later decided that wouldjust cause permission, fatigue.
And so if the user is being requested,all these permissions that they have
to give almost every single app, thenthey'll just start blindly accepting
without really looking into whatthey are giving an app access to.
And so it's a, it's a hard balancing act.
(28:06):
It's definitely better for the OS toenforce a permission, but sometimes
it's hard to, for very low level thingsthat the user might not understand
what they're needed for or what
Mishaal (28:15):
they.
Yeah, we've talked about this balancingact that Google has to do before.
And you know, when you're developingan operating system that serves
billions of users, tens of thousandsof developers around the world and
hundreds of millions of regular users.
It's complicated.
There's so many considerations thatthey have to deal with that you
don't really have to care about.
If you're only designing a platformthat's for a specific use case, if you
(28:39):
are able to own the OS image, like ifyou're developing your own AOS P build
for your own devices, and thereforeyou're able to bundle your own app store.
Then you can bypass a lot of Google'sor Android security restrictions
on third party app installers.
And this is one of the thingsthat Google does for the benefit
of the overall ecosystem.
(29:00):
But if you can develop your ownoperating system based on a O S P, then
you don't have to really consider thesecurity implications of that because
you can whitelist your own app store.
You can grant it all the remissions thatGoogle play store might have access.
Without this permission, though,if you're a regular third party app
store running on a Android devicethat you can buy off the shelf.
(29:20):
Then you can't install apps on yourown without holding the request,
install, packages, permission, andthat's the permission that's shown to
the user it's install, unknown apps.
What it does is it allows an app tosend an intent to the system package
installer, or to use the sessionbased package installer, API, to
request users, to grant approvalfor app installs, which is why the
(29:43):
permission name has request in its name.
So when you use.
API, the user has to actually granttheir approval for each and every
installation and subsequent update.
And that can be a real pain whenthey wanna do batch installations
or batch updates of apps.
So privileged system apps likeGoogle play store on all GMs devices
(30:03):
or whatever apps store you pre-Bbundle on the device can request the
install, packages and delete packages.
Permiss.
To be able to fully unattended, installsand uninstalls on first installs and
all subsequent app updates, but that'snot attainable by user apps unless, you
know, the user app is able to gain routeaccess, which is not possible unless the
boot load is unlocked on most devices.
(30:25):
There is.
However, one way that third partyapp stores can do unattended updates.
And you did mention this beforeLogan, when you were talking about
a Crescent and it's through a newAPI that was introduced in Android.
So I wanted to ask you, can you explainwhat this API, this new feature in Android
12 does and like, how does it exactly.
Yes.
So
Logan (30:43):
Crescent does use that API, Android 12 introduced this API that
allows app stores to update apps withoutrequesting user permission all the time.
And the way it works is with thisconcept called the installer of record.
So say AC Crescent,installs, secure chat again.
Crescent is then marked as theinstaller of record for secure chat.
(31:05):
When it first installs it, itbrings up the normal package prompt.
Do you want to install this appby the OS, but once you grant
consent, then in this case, Crescentis allowed to update secure chat
automatically without asking the user.
And this works in tandem with otherAndroid security features like downgrade
protection and signature pining, makingsure that it's signed by the same
developer and that you can't downgrade it.
(31:27):
So that's what a Crescent does.
The privileged permissions you weretalking about, like you said, they don't
ask for user permission, but what's niceabout the Android 12 unattended update
permission is that's not privileged.
You don't have to whitelist anapp in your operating system.
You can use it on anyAndroid 12 and up device.
That's basically how that API works.
Mishaal (31:46):
And, uh, fun fact, this whole API, this feature directly came about
as a result of epic lawsuit againstGoogle, as well as all the antitrust
scrutiny that Google has been facing.
If it weren't for all that scrutinyGoogle's been having lately, then
we wouldn't have this feature or thereduction in the revenue sharing fee.
So.
Developers.
It is really important that you keep aneye out and you watch what's happening
(32:08):
with these lawsuits and these regulationsaround the world, because they're
having a direct impact on the operatingsystem and the ecosystem as a whole.
They're really important, even thoughthere's a lot of legalese and a lot of
politicing back and forth, but yeah, Idefinitely keep an eye out on all that.
If you're developing an app store,I'm sure you probably don't really
consider the politics behind it.
(32:30):
If you're just actually adeveloper working on the backend.
But what you do care about is how doyou deal with the bandwidth and storage
needs of serving apps to millions ofusers and actually storing those apps
on a server when you're at Google scale,this is a very, very important discussion
to have because everybody optimization.
(32:51):
Both on the service side to reducestorage and bandwidth and on the
delivery end to improve, download speedsfor users and thus user retention.
There was a story I remember,I think it was in 2017.
When in Google intern introducedthe more efficient compression
method called Broley.
It was used for both OS systemupdates and also APK files themselves.
And I was surprised by thenumber that Google shared.
(33:12):
It saves them about 1.5 petabytesof data per day, just by switching
to a more efficient compression.
Just being able to switch one littleone correction method, apply that
to all the apps that they apps thatthey serve to save so much data and
thus reduce bandwidth costs on both.
That's something that, you know, it'skind of like a backend thing that
most users will never most users anddevelopers will never have to consider.
(33:34):
But one thing that I'm sure mostdevelopers are familiar with, and at
least a lot of users are, have heard ofis what Logan brought up before the whole
split APKs and or app bundles featureand how it's delivered to users through
the Google play feature delivery feature,which used to be called dynamic delivery.
This is both a really neatfeature and also pretty contr.
(33:56):
Which lo alluded to earlierand I'll get into in a second.
So for those of you who don't knowthe idea behind the split APK and, and
or at bundle is that most users don'tneed to have installed a monolithic
APK file that contains every assetcode chunk and language resource.
Instead, you only need the bare minimum toget the app and its core features starting
(34:16):
all that's contained within the base PK.
And then Google play can push theremaining split APK files that contain the
assets, features and language, resourcesthat are actually needed by the user.
So for example, if your assistantlanguage set to English, then
you'll get the split APK file thatcontains English language strings.
You won't get the French languagestrings cuz you don't need that.
So this concept is actually quite old.
(34:38):
It's older than thera.
Split a BKS were introduced withAndroid 5.0, but a lot of developers
didn't really make use of them untilthe Android app bundle requirement
came into effect in August, 2021.
So starting August, 2021, every newapp that's uploaded to Google play has
to use the Android app bundle format.
The bundle format wasintroduced with Android.
(35:00):
And to explain a bit about what it is.
It's also a valid zipfile, just like APKs.
So within this AAB file, you haveall the resources, assets, and
libraries that are needed to generatemultiple configurations of the app.
And it's structured in a way so thatyou have all of these segments kind of a
segment apart from each other, you havea base module, you have dynamic feature
(35:20):
packs and you have asset packs that thistool called bundle tool uses to generate
specific split APK configurations.
So what developers do is they generate theAndroid app bundle file in Android studio.
They upload that to Google play and thenGoogle play generates split APK files on
demand when the user downloads the app.
So this has a potential to saveusers, a lot of storage space on
(35:44):
APKs and also thus reduce how muchbandwidth is needed to download.
So while the idea behind this is sound,you've mentioned Logan, that there are
some issues with how it's implemented.
Can you explain what some ofthose concerns are and what
Google's done to address them?
If anything.
There are a few
Logan (36:00):
valid concerns with not necessarily app bundles themselves, but
the implications of how they're used.
So Google play uses thisfeature called play app signing.
And so you upload your app bundleand then Google will sign and
generate the APKs themselves.
As we talked about earlier,the Android operating system.
Will pin the signingkeys of those AP case.
(36:22):
But in this case, it'sGoogle, who's signing them.
And so theoretically, Googlecould modify the APK and deliver a
malicious update either intentionallyor after being compromised.
And so that's one big concernwith, uh, app bundles.
They've mitigated this somewhat withthis feature called code transparency.
How that works is a developer cangenerate this separate signature
(36:45):
file and upload it to the play store.
And users can download that and makesure that the APK that they get was
generated from the app bundle that thedeveloper made, but it's not a perfect
solution for one, the developer has tochoose to generate this and upload it.
Then the user has to download itthemselves and verify it themselves,
which already cuts out a lot of people.
(37:05):
Most people aren't gonna try todo that for every single app.
They.
Another problem is it doesn't verifythe entire file code transparency
doesn't verify the entire APK.
And so things like resources couldstill be modified, which could be
used to change the UI or somethingand trick the user into doing
something that they don't intend to.
Those are a couple of the concerns.
The way Crescent works aroundthis is that developers upload
(37:28):
the split APKs themselves.
The tool that Google uses togenerate split APKs is freely
available and open source, and youcan download it and use it yourself.
And so AC Crescent allows developers todo that and just upload the split APKs.
And so they can still be used withoutthe trust issues with app bundles.
To be fair to Google.
They do a very good job of thisand they're handling these keys.
(37:50):
They have a whole white paper ontheir infrastructure, and there
are legitimate reasons for it.
For example, I didn't learn thisuntil recently, but developers
often lose their signing keys.
Once you lose your signing.
Key, the OS won't accept updateswith a different signing key.
If you didn't rotate it right.
And so if you lose your signingkey, all of your users are left
in the dark without an update.
Whereas with Google play, if youlose your upload key, which you have
(38:13):
to use to authenticate yourself,Google still has the signing key.
So they can just generate a newone for your account and you can
still deliver updates as normal.
So there are benefits to it, but thereare definite security and trust drawback.
Mishaal (38:26):
What about the challenges this whole play app signing introduces
when it comes to distributing appsacross multiple app stores, like
since Google is signing the apps thatget delivered to your device, right?
If you were to take that app, And youwere to try to say you had Samsung
galaxy app store installed as well.
And you tried to install an update thatwas already available through Samsung's
(38:47):
galaxy app store for the same exactapp you wouldn't be able to because the
app that's uploaded to Samsung storeis signed with a different key than
the one that's uploaded to Google play.
Can you talk a bit about that?
That's
Logan (38:58):
partially a store concern and partially a developer concern.
Generally speaking, if you havean app that's being signed with
different keys, say for Google playand say, you're really seeking it on
GI Huber, your website or something.
If you're not using the same key,
Mishaal (39:12):
you should
Logan (39:12):
change the app ID, which is basically just an internal
identifier to make an app uniquelyidentifiable to the operating system.
I know I keep bringing itup, but for example, Graphos
does this with their camera.
There's a version.
They sign themselves and theversion that Google signs.
And so they have different app IDs,so they can both be installed at
the same time without conflicting.
So that's generally whatdevelopers should do.
(39:33):
If they're uploading to multiplestores that are signing with different
keys, they should change the app ID.
So they don't conflict.
But many aren't aware of that.
And so that does cause a challenge,especially for apps that are say
on both Google play and F Androidsince F Android signs with their own
keys, but doesn't change the app ID.
They conflict with Google playversions, and you can't have both
(39:53):
installed at the same time oruse one to update to the other.
Mishaal (39:57):
I've talked about this before, but the Android app bundle, there's
a lot of clear and obvious benefits.
It brings to both Google and to userswhen it comes to storage and bandwidth.
But it's hard not tohave like a cynical view.
Oh, how does this lock users moreinto the Google play ecosystem?
Like, is it a coincidencethat it has these benefits?
You tell me because , I'm suremany people will think that there's
(40:20):
no coincidence that, you know, ithas this benefit of doing that.
But to be fair, there are some ratherunique things that can be done with
Android app bundles that you can'tdo easily with the monolithic KPK.
So, for example, at the beginningof this year, Google announced the
new feature that Google play willbe getting called app archiving.
So basically what this does is thatGoogle will be using the bundle that
(40:42):
delivers upload to generate a newsplit APK file called an archived APK.
So this archived APK is basically a.
That holds nothing but code to launchthe app store to redownload the full app.
So this stub basically has nothing in it.
It's just an empty app.
That's signed by the samekey because Google signed it.
(41:02):
It has the app icon.
Because it's actually stillinstalled on your device, but it
has like no resources, no nothing.
It's basically like a multi kilobyte fileinstead of like the tens, potentially
hundreds of megabytes file that theoriginal app was using up on your device.
So by introducing this app, archivingfeature users will be able to archive an
app and reduce its storage requirementswithout actually uninstalling the.
(41:23):
And if you're interested in learningmore about that, by the way, I did a
deep dive on the Android buys column.
I, I think that's quitean interesting feature.
And I'm really curious to see if otherapp stores actually replicate this.
Like Google did design it in such a waythat other app stores could replicate it.
But again, like the whole permissionsdata, the permission safety form
stuff, I don't really know ifany alarm stores actually follow
(41:44):
through and do what Google's doingand all, everything they're doing.
But before we close off this discussion,cuz we're getting close to time.
I wanted to bring up a prime example.
Of a market where non Google playapp distribution is successful.
And that's China, China, for thoseof you who don't know, does not allow
access to any Google services, the factthat Chinese Android users are using
(42:05):
non Google play app repository is moreout of necessity than anything else.
So from what I've heard, speaking toChinese users and reading online is
that Chinese users source APKs from amultitude of app stores, a multitude
of websites, many third party appposting websites, and more like, it's a
huge mess of where they get apps from.
(42:27):
It's it's really decentralized and that'sactually, you know, Kind of the model
that desktop users have been dealing withfor a long time, the decentralization,
but without that centralized, Google playand GMs providing those APIs, the Chinese
market kind of struggles to deal withthings like push notifications, whether
like 13 different push notificationAPIs, which requires like, if you
(42:49):
have 13 different apps, all usingdifferent push notification implement.
Then that means you have 13 differentapps having these foreground services,
constantly waiting for push notificationsto be pushed to your device and that
results in a whole bunch of appswaking up at various random times and
then destroying your battery life.
So if you're wondering why a lotof Chinese phone brands seem to
(43:09):
have these really, really, reallyaggressive battery saving measure.
It's a result of this because there's nounified centralized, Google play services.
Like there is outside of China,knowing what you know about
how the situation is in China.
Do you prefer the centralizedmodel we have now with Google?
Or do you think a fully decentralizedapproach would be better or
maybe something in between.
(43:30):
At
Logan (43:31):
a high level, I would say the decentralized approach
could be better, but it won't be.
And the reason I say that is becausewhen you have multiple parties
providing updates to their ownmechanisms, a lot of them aren't
doing it well or doing it right.
Like we've seen how a Google play store,although this largely due to GMs the
place where actually does securityevaluations, they do app distribution.
(43:53):
Very, very well.
It's hard to make sure that thosesame restrictions, uh, security and
privacy are being enforced acrossall these different mechanisms.
And most app developers won't makesure updates are delivered securely
and timely and automatically.
And so that's why I would say thedecentralized approach could be better,
but it won't be say, if you have anapp that updates itself, that's like
(44:16):
the ideal situation you can have, butmost developers won't want to do that.
It's extra work and it's hard to do.
Decentralization in the sense of sayone app updating from multiple different
places actually violates Android securitymodel there's security model mandates
that one app store is just one app source.
It downloads apps from oneplace, and there are problems
(44:37):
if you try to change that.
And then there's also a problem.
If you're downloading from multipleservers with the same app, say like, does
you can't use certain security featureslike TLS certificate pinning that would.
How I would evaluatethe overall situation.
Centralization is unfortunate in someways, but I think if the centralized
(44:57):
party knows how to do things well,I would say Google does, then the
situation would be much better.
In that case, you don't have to trustas many parties to do the right thing.
Right.
Mishaal (45:08):
And fortunately, you know, Android isn't as locked down as iOS,
where you have no choice betweencentralization and decentralized.
It's all centralized all the time.
At least with Android.
99% is through Google play, but that1% outside of China, at least you
have the freedom to choose what appsand what app stores you're using.
(45:28):
And of course, since a S P itself is open.
You also have the freedomto customize a O S P.
And then build in your own appdistribution ecosystem to that
distribution and to the devices thatyou are deploying this build on,
which of course is really importantbecause a S P as I said before, does
not come with an app store by default.
So you have to do something custom.
(45:49):
If you're going to builda O S P without GMs.
David (45:52):
App distribution is actually something that is very near and dear
toper, you might even say it's kindof the core of our business in a lot
of ways, because what Esper does everyday is deliver applications and updates
to applications, to dedicated devices,which are things like kiosks business
tablets, things that typically don't haveGoogle mobile services to begin with.
(46:14):
And wouldn't have a reason toother than having a way to.
Apps, but obviously that's not a goodsolution for a lot of reasons, for a lot
of different kinds of devices, some ofwhich are cost, some of which are time,
some of which are engineering effort.
I mean, all of thosethings generally are true.
Being a GMs partner versus using AOS.
P.
(46:34):
So if you're using a O S P to build akiosk or to build a point of sale or
to build display, signage, whatever,it might be a medical device, perhaps
home exercise equipment, we'reliterally on a climbing machine.
You need a way to deploy updatedAPKs to that Android device.
And if you don't have the play store,that's a little easier said than done
(46:54):
at scale, easy to do with a few dozen.
And once you get to a few hundred,few thousand tens of thousands of
devices, That gets pretty hard.
And so what Asper provides along withour robust device management tools
is a really, really sophisticated wayto deploy your apps, stage updates,
group them choose when and where theygo out, set conditions for success.
(47:16):
You.
And deploy your app in a way thatis highly observable and where
you know exactly where it's going.
You know, every device that'sreceived it, every device that
hasn't, you're getting exceptionreports when something goes wrong.
So if you've been wondering how you candeploy applications to Android devices
in a really specific, targeted, highlyreliable way with an enterprise grade QoS,
(47:38):
come talk to us at SPER we're at SPER dot.
I.
Mishaal (47:42):
Thanks David, for the obligatory per plug in the Android bites podcast.
And of course, here's the obligatoryclosing segment of the podcast where
I give our guests the opportunity toexplain where can you follow him online?
So Logan, where can peoplefind you and your work?
You can find
Logan (47:59):
me on Twitter and on GitHub as Berry ma that's my
handle on most other places.
And then Crescent is ongithub.com/crescent, ACC, R E S C E
Mishaal (48:12):
NT.
And you can find David and Ion ESER that's blog.sper.io.
And thank you all again for listeningto another episode of Android bites.
Hello, and welcome to Android bites powered by Asper I'm David Ruddick.
And each week I'm joined by mycohost Michelle ramen diving deep
into the world of Android this week.
We're talking about apps and really appstores actually, which is a topic on
Android that obviously has a historyas long as the platform itself and
allow Michelle to introduce our guests.
Mishaal (00:23):
This.
Thanks David.
So on today's show, wehave invited Logan McGee.
He's an independent developer.
He's working on a project called Crescent.
So thanks for joining us, Logan.
Thank you for having me.
Okay.
And as David mentioned, we wanna talkabout apps, more specifically, app
stores and app distribution in a O S P.
You don't have an app store by default.
You have no way to actually get apps.
(00:45):
And if you install a pure,fresh AOSP build, you gotta
find and procure apps on your.
I was actually reading an interestingarticle earlier today on L w N I
don't know if you subscribed to thatwebsite or not, but they're basically
like a newsletter that covers Linux.
And they talked about way Android, whichis a project we've actually talked about
before on the show way back when wewere actually doing the Twitter spaces.
(01:06):
So way droid for those you don't know is asoftware project that enables running the
entire Android user space and a container.
It's a really interesting andneat project, especially if you
have a Linux smartphone like thepine phone, and you wanna run
Android apps because there's not.
Native Linux optimized apps forsmartphones, but it like any other non
GMs, a O S P project has the same issue.
(01:28):
Where do users get their apps from?
Of course, if you're a privacy conscioususer, you've probably heard of various
app repositories, like fro you know howto procure APKs off of various websites.
But as an ecosystem, this is ahuge challenge because you can't
assume that every user has thesame technical capabilities as
your average Linux developer, does.
(01:48):
You gotta assume that most users aregonna want to, or they're gonna expect
that there's an app store on their deviceand they're gonna click that and they're
gonna download everything and everything'sgonna be handled for them all easy peasy.
That's why most OEMs major companies, theygo through the process of licensing GMs,
which if you, um, listen to our podcast,our previous podcast with the execs from
awesome, you know, that's a pretty arduoustask, but most OEMs go through it anyways,
(02:12):
because it's absolutely necessary fortheir users, which consists of millions
of average people to have access to theplay store and Google play services,
which ensures not only do they haveaccess to millions of Android apps, but
also the APIs that many of them depend.
And because so many apps have GMsdependencies, it's pretty much
impossible to talk about alternativeapp distribution models on Android
(02:32):
without factoring in where GMs comes in.
So if a device has GMs, then it'smostly just a matter of where
do you source the apps from?
Is it from Google play storeor is it from somewhere else?
You're not gonna have that many problemsunless you're dealing with like paid apps.
If a device doesn't have GMs, though,then you need to take extra steps to make
sure that the app that you're trying to.
We'll actually run on your devicebecause a lot of apps, like I said, have
(02:53):
dependencies on GMs, including things likesafety net at station fireplace, cloud
messaging for push notifications, theGoogle maps, API for mapping, et cetera.
But thankfully at least since a S Pis open and supports side loading,
other apps stores that aren't bundledwith the OS image, you know, it is
possible to actually have alternativeapp repositories that don't really
(03:13):
care about what's going on with GMs.
Fro is one example that Imentioned the graph OS project.
They recently released their own quoteunquote app store, which is basically
just like a website that has some oftheir apps that you need to set up their
sandbox, Google play implementation.
If you haven't listened to our graph OSepisode, I'd recommend go doing that.
So that's basically what anapp store really boils down to.
It's just a browsable catalog ofapps that users can download install.
(03:37):
So if you're thinking aboutdesigning your own app store and
distributing apps on Android, youneed to answer these questions.
How do you connect usersto that catalog of apps?
How do you get legitimateapps onto the catalog while
weeding out illegitimate ones?
How do you securely and efficientlystore and distribute apps to users?
And how do you handledistributing app update?
None of these are straightforwardthings to solve, but fortunately
(04:00):
we have over a decade of history oflooking at what Google play has done.
So we can basically take a lookand see what does it take to go
about designing your own app storeto distribute apps on Android.
But before we dive into the meatof this discussion, I wanted to ask
both of you for your overall thoughtsand experiences of using other app.
Such as you know, Wawa's appgallery, Samsung's galaxy
(04:20):
store F Android, et cetera.
Have you ever used an Android phonewithout GMs and exclusively had to
get apps from outside of Google play?
And what was it like?
Have you used an Android phonewith GMs, but still chose to get
apps from outside of Google play?
Or have you done a mix ofboth play and non Google play?
Logan (04:36):
Personally I used Graphos as recently, actually, so that doesn't
have GMs installed by default.
And so for a while, I was tryingto get apps from other places like
GitHub releases or fro, and honestlyit was kind of painful to deal with.
And so eventually I actually started usingGMs through their sandbox, Google play
(04:58):
compatibility layer, just because it iskind of a pain to get apps on Android.
If you don't have GM.
David (05:04):
My history with various app stores.
I mean the most prominent one and theone that I probably use the most would
be actually the Amazon app store, whichwas such an interesting experiment.
I mean, it's still, obviouslyvery active, used by tens of
millions of people who own Kindle.
Fire tablets.
But I remember the challenges Amazondealt with in terms of simply like
(05:27):
keeping apps up to date with their Googleplay counterparts fact that the Kindle
fire devices ran an older OS version.
I believe the Kindle fires initiallylaunched based on ice cream sandwich
initially back in the day, correctme if I'm wrong there, but it was
a different time and it was stilla time when legitimately you could.
(05:47):
Somebody may be trying totake a step at Google play.
And Amazon threw money at developers,especially game developers with all
this in-app currency promotion stuff.
And they threw money at advertisingto try to get people excited about it.
And it underscored to me thatthe usefulness of an app store.
Is really dependent on what kind ofwalls are put up around that device.
(06:11):
And in Amazon's case, it was, youcould not easily install, play, or
a GMs applications on those devices.
And they've continuously, youknow, I'm not saying they made it
harder, but they fixed loopholes.
And obviously Google doesn't wantthem to work very well either.
And of course I've used Chinese phonesfrom so many OEMs that don't ship a GMs.
I even back in the day, received areview unit from a smartphone OEM.
(06:34):
And I'm sure Michelle you'veexperienced this as well.
It came with an application on it,specifically designed to display a
WebApp view that linked to the filesyou needed to download the core GMs
bits and then install them as thoughit was like they called it the Google
installer, I think, on this device.
So, yeah, it's just hardto imagine a mass market.
(06:57):
App store that could de throwGoogle play at this point.
And Amazon did try.
So that then begs the question.
The need for specialty appstores is probably there.
And what kind ofspecialties will they have?
And that's always been interesting tome, especially since I worked at Android
police until Valette bought Android.
Police is the sister side of AP came.
(07:18):
Dot com.
So I'm aware of things involvingAndroid app distribution, to some
Mishaal (07:24):
extent.
Yeah.
So if you're going to go about designingan app store or app repository of
like APK mirror, well, APK mirroris a special exception because it's
not really designed to actually getpeople to use it as like an app store.
It's just basically a APK backupposting site for the most part.
But if you're going to design an appstore that you actually want users to
(07:45):
use, you need to answer the question.
How are you gonna get itinto the hands of users?
Obviously on many devicesout in the market, you don't
have access to the OS image.
So you don't have the ability tobundle your app store with the device.
If you are a business and you want tohave a small selection of apps that
you want your employees to access,and you know, you're going to buy a
(08:06):
whole bunch of GMs, Android devices.
Then you could pretty much skip thisentirety of this discussion and just
use something like managed Google play,which is like a small island of apps that
are only available for these devices.
And those are the only apps they can use.
But if you're not going to be doing that,if you want to ship a device without
GMs, then you're going to find anotherway to get your app store onto devices.
(08:30):
So you could either direct users to awebsite, which is the lowest hanging
fruit, or you could create an app thatconnects to your own customer repository
backend, or you could piggyback onexisting solution, like say creating
a repo and then using an fro clientcustomized or not to connect to it
rather than the main FOID repository.
So if you set up a device to be enterprisemanaged from the get go, like through
(08:52):
our SPER device management platform,then it's easy to push something.
And install apps and update them.
If you build the firmwareyourself, which is something
we can also do with foundation.
I know, I know I gotta stop plugging here.
We'll do that later with David, thenthe app store app could also be bundled
with the OS image, and then you couldalso automate app installs and updates
and have them be unintended updates.
(09:13):
So otherwise, if you can't do any of thosethings, you need to have the user manually
seek out your repository, which requiresthem knowing it exists in the first place,
and then requires them to manually accept,installing and updating the apps in most.
So, I guess this is the perfecttime to segue into talking about
the app store that you're creating.
Logan.
Can you give us a brief introductionto Crescent and why you're building it?
(09:34):
How will users access it?
And what are your plans tospread the word about it?
Once it launch.
Yes.
Logan (09:39):
So Crescent is, uh, an in progress app store.
I'm currently building, that'smainly focused on security,
privacy, and usability.
It works kind of similar to the playstore in that it allows developers to.
Upload apps that they have compiledthemselves, but it's different
in that it doesn't require themto give up their signing keys.
(10:01):
They don't have to upload an appbundle with their signing keys or have
Google generate signing keys for them.
So they generate the split AKs themselveslocally and then upload them to Crescent.
So Crescent still has all of thebenefits of split APKs without the
downsides of trust and security.
it also does something kind ofneat regarding app signatures.
(10:23):
And so it has this signedpiece of repository metadata.
The store is really justa static web server.
And so it uses that metadata toverify that apps downloaded are
signed by who they're supposed to be.
So even if the server was taken overby an attacker or something, uh,
users who download apps will knowfor sure that the apps they download.
(10:47):
Are, um, developed bywho they say they are.
Um, but it also focuseson privacy in some ways.
Uh, it doesn't sendany device identifiers.
It doesn't need to,right now it just sends.
Like the device architecture, uh,screen density and primary language,
and it needs that to fetch split APKs.
(11:09):
And another reason building aCrescent was for usability, right?
I'm sure a lot of people have hadproblems with say, uh, on Android, you
have to manually accept and installevery single time you update an app.
Whereas AC Crescent uses some modernAPIs to allow you to update them.
In the background withoutuser interaction, but without
compromising on security.
So those are a couple of thethings that Crescent does to
(11:30):
ensure better user security andprivacy or existing solutions.
Mishaal (11:35):
Thanks for the rundown Logan.
So you brought up a lot of thingsthat I kind of wanna touch on in a
bit, especially like split it, BKSAndroid, app bundles, et cetera.
Some of our listeners may notbe familiar with these concepts,
but before we actually dive intoconsiderations that you need to make
to get apps onto a store, I wantedto talk a bit about Android security
model when it comes to applications.
So every app that you install on anAndroid device comes in a file format
(11:58):
called an Android package or APK file.
An APK is a self-containedarchive, which is essentially a
derivative of Java archives or jar.
But with a few Androidspecific additions to it.
So the jar file format is itself based onthe popular zip format, which, you know,
if you ever use the desktop computer,zip it's that handy archive file format,
(12:19):
where you store a bunch of files andcompress it and it saves you space.
And since jar is based on zip.
APK by extension is as well, which iswhy you can open up APK files and see
what's inside them using something likeseven zip on windows or other platforms.
So within the APK file, there's severalkey Android specific components.
Namely the Android manifest, whichcontains the apps metadata, including
(12:42):
what components it supports, whatcomponents it has, what permissions
it requests and other various.
Things that it needs like librariesthat might require there's also the DAIC
executable bike code files, which hasthe apps code for the JVM to interpret.
Then there's the resource catalog, whichis like, uh, resources.ar SC, and then
(13:04):
the actual resources that they map to.
Then there's unmanaged resources,which are also called assets and then
optionally some native libraries.
There's also a digital signature, whichis inherited in part from the jar format.
And that digital signature is generatedwhenever the developer signs, the
application package using a signing key.
So every app is installed ontoa device, gets a unique, or
(13:25):
has a unique package name.
Developers can technically givewhatever package name they want
to their application, but Androidwill reject the insulation of.
That has a package name matchingan existing app that's installed
on the device provided thatapp's digital signature doesn't
match the existing apps this way.
If you have one app installed a developer,can't just say, I want my app to have
(13:46):
the same package name, and then try toinstall on top of that existing one.
That's one of the key partsof Android security model
when it comes to applications.
And since the signing key used to generatean app's digital signature is generally
assumed to be kept private and secure, youknow, somewhere where only the developer
who signs the app has access to or in,uh, Google play's case, Google themselves.
(14:06):
It's generally assumed that onlythe app's original developers or
Google will be able to push updatesto existing apps that Android will.
This is how Android securely updates apps.
So I've done a bit ofoversimplification here.
APKs, don't actually use likethe exact same digital signature
implementation that you see in jar files.
They've evolved over time to havelike a proprietary implementation.
(14:30):
There's various implementationscalled the APK signature schemes.
And I wanted to ask you Logan, ifyou can explain to our listeners
a bit about these, a signatureschemes, like what does the signature
scheme V3 bring to the table?
For example?
APK signature
Logan (14:43):
scheme three is a slight improvement over V2, which is what
replaced the legacy jar signingyou were just talking about
and V3 allows for key rotation.
So that means if a developer hasa certain signing key and they
might suspect it's compromised.
For example, they can sign a new keywith their old key and then make that new
(15:04):
key, the new trusted key for that app.
So they.
Migrate away from old keys to avoidcompromise without having to make the
user uninstall and reinstall their app,which would've been the case before.
There's a couple other newer ones too,like before, which is kind of different.
It's not embedded in the APK itself.
It's in a separate file and that can beused for this feature called Fs Verity.
(15:28):
I don't wanna get too technical about it.
Essentially what Fs Verity does.
And what V four signatures allow isfor the OS to cryptographically verify
an, a PK every single time you launchit, or every single time it's read by
the operating system, which is veryhelpful for reducing persistence.
I believe the Google play store uses.
Before signatures
Mishaal (15:48):
for this reason, he talked about the technical implementation,
but one of the key features that itenables is the app incremental feature.
So I think, uh, I forgot whatthe marketing name is for it.
I think plays you download.
Yeah.
That's what it's called.
So Android 12 Google introduced plays,you download, which basically lets
you start playing a game while alot of it's assets are still being.
(16:09):
So because the signature isseparate from the actual APK, it's
able to be verified as the bulkof it's still being downloaded.
So that's one of the features thatV4 Napes and which is why it's not
really mandatory to support yet.
Whereas V3 is a much more significantimprovement in terms of security.
So I wanted to ask you next, arethere any flaws in this Android
(16:30):
security model when it comes to appsigning and app distribution, and how
does a Christian plan to deal with.
Yes, sort of, I wouldn't necessarily
Logan (16:39):
call it a flaw.
It's more of a design decision,but the way Android works with app
signatures is the first time youinstall it, it pins that signing key.
So say you install an appcalled secure chat or something.
I install that.
And then the Android operatingsystem parses it and finds the
signature and says, okay, thisis the key that sign this app.
(17:00):
And I will not accept any updatesif they're not signed by this.
And so that securesupdates later on, right.
But that doesn't helpwith the first install.
If you install a maliciousversion of that app, then it'll
updates that are legitimate.
And presumably you'll be gettingupdates that are malicious and
Android doesn't really do anythingitself to solve this problem.
(17:21):
It just leaves that upto the application layer.
What a Crescent does to solve.
This is when you uploadan app to the store.
Or whoever maintains theirrepository will sign their key
to validate basically to the app.
This is the signing key.
We will accept for this app.
The Crescent will only acceptthis signing key for this app.
(17:43):
And so that means the first time youinstall it, you can know for certain that
you are installing the legitimate versionof that app, and it can't be replaced with
a malicious version or something, even ifthe server was taken over, if that makes
Mishaal (17:55):
sense.
Gotcha.
Yeah.
I mean, that is a big problem.
Like figuring out how to installthe legitimate version of an app,
especially when there's so manyclones and copycats out there.
And so many different ways toside load apps or trick users
into side loading apps that seemlegitimate, but they're actually not.
And once they have it, how do they knowit's actually the real deal or not?
And many times they don't.
(18:16):
That is one, as you mentioned, it'snot really a, a flaw, more like a
intentional design decision, andthere are solutions to mitigate that.
But one of the, I'd say key failuresof most app stores is actually
getting developers on board.
And I think this is one of the areaswhere why so many people don't even
bother trying to make an app store.
(18:37):
So kudos to you attempting to do that.
. For those of you who, uh, aren'tfamiliar with this major chicken egg
problem, you have an app store, right?
What you need to do is youneed to get apps on board.
So you need to getdevelopers to upload their.
But the problem is developers.
Aren't going to do that.
If there aren't users who areusing your app store, because
after all, most developers want tomake money off their applications.
(18:58):
You know, they need to earn a living orsell a product or do something with it.
So if there aren't users, then theyaren't going to be making any money.
And if there aren't any apps, there'snot going to be any developers.
So it's just a vicious cycle that kindof ensures that most burgeoning app
stores don't ever really take off.
And it's why even app stores createdby the biggest tech companies
on the planet, just pale incomparison to Google's play store.
(19:21):
There are a couple of things that Googleplay does particularly really well and
what others have attempted to copy inorder to get developers, to actually
upload their apps and share them there.
So Google play, for example, they offerpretty robust tools around handling
rollouts and managing your storefront.
And then offering various ways topromote your apps within Google
play outside of Google play.
(19:42):
Other app stores try to offer lucrativerevenue, sharing fees, much lower
than Google, but still, if you'retrying to launch an app store and
you want to compete with Googleplay, that's a really hard sell.
But if you are trying to just launch anapp store that serves a very specific
purpose, just a handful of users, you knowwhat you're targeting, then you're setting
much more realistic goals for yourself.
(20:03):
But if you're trying to launchvery open app store, that steps.
App submissions by any developeraround the world, and you're
going to deal with the problem.
And it's a problem that pretty muchmost app repositories deal with.
And it's how do you moderate toensure that bad actors aren't
abusing your platform to spreadtheir malicious status, sucking
applications or straight up malware?
(20:24):
and if you're dealing a Google playscale or like Samsung scale, et cetera,
then the answer is, in my opinion, youcan't, I think it's literally impossible
for a company like Google to be ableto thoroughly audit each and every
single app that comes out their door.
There's just too much to deal with.
There are a few things they do, andthey do well and some not so well to
(20:44):
raise the barrier to entry, to ensure.
There aren't as many malicious appsor privacy afflicting apps that
are submitted to the app store.
Like the most basic thing theydo is they require a fee and, you
know, personnel contact information.
When you sign up for developer account.
I don't think it's very effective,but I'm pretty sure that does
stop a lot of bot submissions,Google play, and other app stores.
They also perform static analysisof manifest files to look for
(21:07):
potential violations of privacy.
So for example, Google play is a lot ofpolicies around what permissions and app
can request and how they want to use them.
So if it detects that your app istrying to request the SMS permission,
then Google play will reject your.
If you don't submit a forum andyour app doesn't meet one of the
pre-approved categories of appsthat can request access to SMS.
(21:30):
Google play also does automaticdynamic analysis of apps.
So it analyzes risky code or behaviorsuch as attempts to gain root access
or disabled se Linux play protect.
Does this on GMs devices?
Google play also has human moderatorsto review app submissions and
updates to look for violations.
And finally, Google play alsoforces developers to declare
(21:50):
their use of data permissions.
Although more recently, if you heard thenews, Google play is actually starting to
hide the list of permissions in favor ofthe developers submitted data safety form.
You've all heard the stories.
I don't know if you've ever personallycome across this or dealt with this
before, but you've heard horrorstories about developers dealing with
Google play support or that theirmoderation practices are ineffective,
(22:11):
inconsistent, or straight up incompetent.
And from what I've ever heard, the othermajor app stores aren't really any better.
Do you really think there's anythingGoogle and others could do to improve
the quality of apps and limit thenumber of fake or malicious apps?
Or do you think they're pretty muchjust trying to prevent the dam from.
I
Logan (22:27):
would say similar to what you said, it's very hard
for Google to make the system.
They have work at their massive scale.
It's hard to get frankly, enoughcompetent reviewers and enough
analysis to really prove for surewhether an app is malicious or not.
It's just not reallypossible at that scale.
They are doing quite a few things tohelp though, like reviewing certain
(22:49):
permissions or making sure they'reonly used for legitimate purposes.
For example, there's a legacy filemanagement permission that some apps
request, which basically gives themaccess to manage all of your files.
But sometimes they request that whenthey don't actually need access to
all of 'em, they just need one at atime when they want to send something.
And so that's part of what they can do.
(23:11):
I don't really know howto solve the problem.
On Google side, because honestly Idon't upload apps to the play store.
So I'm not as familiarwith the problems there.
David might have a littlemore insight into that.
David (23:23):
Over the years we received so many meals.
I'm sure you did Michelle as wellfrom developers who were having
problems with basically the contentreview team or content moderation
team on the Google play store.
And there are so many reasonsthat they can reject to.
and often of course, they're reallyterrible at actually explaining the
rejection reason because usuallythe person rejecting you is probably
(23:46):
somebody not making very much money.
And they're working throughas many of these approvals as
they can in a given Workday.
Their goal is volume.
Not quality.
No, you can't just makebetter people for this.
Like you said, that's notreally a scalable solution.
And to me, Google is pulling the leversa can, which are restricting permission
(24:07):
access, making it more stringent, or atleast making the declarations very obvious
when it's something really sensitive,which we're seeing now in Android 13.
And we've seen inprevious Android versions.
And I think that we'll continue to seethat trend and we'll continue to be
upsetting to a particular audience ofhin enthusiasts who don't like that.
Google is clamping down this way.
(24:28):
At the same time, it's hard to see thisbeing a problem that can be solved at
scale without immensely powerful machinelearning and really rigorous controls.
And that just seems to be thedirection Google is heading.
That's how most of their products work.
So I feel like, yeah, thehorror stories from the play
(24:50):
store are really frustrating.
You hear about devs who get delisted fortotally bogus reasons because the reviewer
either didn't understand something about atrademark or copyright complaint, or they
thought there was something in the appthat had changed, but they misunderstood
and seeing that kind of stuff.
And like seeing people'slivelihoods be affected by that.
That sucks at the same time.
(25:12):
Michelle, what you said, I thinkis what I've heard as well,
that there is no app store.
That's good at this.
You hear complaints aboutapple on the app store all the
Logan (25:20):
time.
This is part of why I believeit's a good idea to leverage the
Android security model to enforcethis level of quality control.
For example, the play storerequires that all apps uploaded
must target a certain SDK.
And basically what that means is it'stested on a certain Android version and
the OS enforces certain restrictionsaround that app that typically get
(25:43):
stricter as the Android version goes up.
And so that's one way theycan enforce quality control.
The other one.
Permissions, which they do quite heavily.
Part of it is informing users as well.
So they understand, you know,when I'm giving an app access to
this thing, it has apps don't haveaccess to a whole lot of sensitive
information without user consent.
And so having to rely on the app storeto communicate, that can be helpful.
(26:07):
But part of it is also up to the user.
Mishaal (26:09):
I wanted to ask your thoughts on the growing number of permissions
that seem to be purposely designedso that their actual enforcement
mechanism isn't the Android OSitself, but rather Google play.
And I know like there's alot of permission that says,
oh, app stores may enforce.
The use of this permission, butin actuality, you know, it was
designed around Google play.
(26:29):
So I already mentioned SMS,but there's also call log.
Those two permissions existed a whileago, but I'm seeing more and more
permissions being added with each newOS version and their permission level
might be normal, which means that they'regranted an install time, but then.
There's an asterisk in thedocumentation that says app stores
may restrict this permission.
So I wanted to ask you, do you thinkthat's a good model for Google to
(26:50):
take and do you actually see otherapp stores following through and
actually enforcing these permissions?
Like Google?
I think it can
Logan (26:57):
be a good thing, but I think it's also a hard balancing act.
You don't wanna ask the user forevery little low level permission
that they might understand.
For example, there's the quarry, allpackages permission, which basically
allows an app to list and read allthe apps that you have installed
in your device, which you wouldthink is pretty sensitive stuff.
But the OS doesn't have a mechanismyet to enforce that permission.
(27:22):
Even if you don't have the qualpackages permission, there are
other ways to get around it and listall the apps you have installed.
And so the play store restricts this,but the OS doesn't that specific example
I think could be enforced by the OSlater, but due to how Android works
currently, it's hard to do that withoutbreaking certain app functionality.
Another example is the internet permissiona long time ago, it used to be a dangerous
(27:45):
permission, which means the user had toopt in and allow an app network access.
But Google later decided that wouldjust cause permission, fatigue.
And so if the user is being requested,all these permissions that they have
to give almost every single app, thenthey'll just start blindly accepting
without really looking into whatthey are giving an app access to.
And so it's a, it's a hard balancing act.
(28:06):
It's definitely better for the OS toenforce a permission, but sometimes
it's hard to, for very low level thingsthat the user might not understand
what they're needed for or what
Mishaal (28:15):
they.
Yeah, we've talked about this balancingact that Google has to do before.
And you know, when you're developingan operating system that serves
billions of users, tens of thousandsof developers around the world and
hundreds of millions of regular users.
It's complicated.
There's so many considerations thatthey have to deal with that you
don't really have to care about.
If you're only designing a platformthat's for a specific use case, if you
(28:39):
are able to own the OS image, like ifyou're developing your own AOS P build
for your own devices, and thereforeyou're able to bundle your own app store.
Then you can bypass a lot of Google'sor Android security restrictions
on third party app installers.
And this is one of the thingsthat Google does for the benefit
of the overall ecosystem.
(29:00):
But if you can develop your ownoperating system based on a O S P, then
you don't have to really consider thesecurity implications of that because
you can whitelist your own app store.
You can grant it all the remissions thatGoogle play store might have access.
Without this permission, though,if you're a regular third party app
store running on a Android devicethat you can buy off the shelf.
(29:20):
Then you can't install apps on yourown without holding the request,
install, packages, permission, andthat's the permission that's shown to
the user it's install, unknown apps.
What it does is it allows an app tosend an intent to the system package
installer, or to use the sessionbased package installer, API, to
request users, to grant approvalfor app installs, which is why the
(29:43):
permission name has request in its name.
So when you use.
API, the user has to actually granttheir approval for each and every
installation and subsequent update.
And that can be a real pain whenthey wanna do batch installations
or batch updates of apps.
So privileged system apps likeGoogle play store on all GMs devices
(30:03):
or whatever apps store you pre-Bbundle on the device can request the
install, packages and delete packages.
Permiss.
To be able to fully unattended, installsand uninstalls on first installs and
all subsequent app updates, but that'snot attainable by user apps unless, you
know, the user app is able to gain routeaccess, which is not possible unless the
boot load is unlocked on most devices.
(30:25):
There is.
However, one way that third partyapp stores can do unattended updates.
And you did mention this beforeLogan, when you were talking about
a Crescent and it's through a newAPI that was introduced in Android.
So I wanted to ask you, can you explainwhat this API, this new feature in Android
12 does and like, how does it exactly.
Yes.
So
Logan (30:43):
Crescent does use that API, Android 12 introduced this API that
allows app stores to update apps withoutrequesting user permission all the time.
And the way it works is with thisconcept called the installer of record.
So say AC Crescent,installs, secure chat again.
Crescent is then marked as theinstaller of record for secure chat.
(31:05):
When it first installs it, itbrings up the normal package prompt.
Do you want to install this appby the OS, but once you grant
consent, then in this case, Crescentis allowed to update secure chat
automatically without asking the user.
And this works in tandem with otherAndroid security features like downgrade
protection and signature pining, makingsure that it's signed by the same
developer and that you can't downgrade it.
(31:27):
So that's what a Crescent does.
The privileged permissions you weretalking about, like you said, they don't
ask for user permission, but what's niceabout the Android 12 unattended update
permission is that's not privileged.
You don't have to whitelist anapp in your operating system.
You can use it on anyAndroid 12 and up device.
That's basically how that API works.
Mishaal (31:46):
And, uh, fun fact, this whole API, this feature directly came about
as a result of epic lawsuit againstGoogle, as well as all the antitrust
scrutiny that Google has been facing.
If it weren't for all that scrutinyGoogle's been having lately, then
we wouldn't have this feature or thereduction in the revenue sharing fee.
So.
Developers.
It is really important that you keep aneye out and you watch what's happening
(32:08):
with these lawsuits and these regulationsaround the world, because they're
having a direct impact on the operatingsystem and the ecosystem as a whole.
They're really important, even thoughthere's a lot of legalese and a lot of
politicing back and forth, but yeah, Idefinitely keep an eye out on all that.
If you're developing an app store,I'm sure you probably don't really
consider the politics behind it.
(32:30):
If you're just actually adeveloper working on the backend.
But what you do care about is how doyou deal with the bandwidth and storage
needs of serving apps to millions ofusers and actually storing those apps
on a server when you're at Google scale,this is a very, very important discussion
to have because everybody optimization.
(32:51):
Both on the service side to reducestorage and bandwidth and on the
delivery end to improve, download speedsfor users and thus user retention.
There was a story I remember,I think it was in 2017.
When in Google intern introducedthe more efficient compression
method called Broley.
It was used for both OS systemupdates and also APK files themselves.
And I was surprised by thenumber that Google shared.
(33:12):
It saves them about 1.5 petabytesof data per day, just by switching
to a more efficient compression.
Just being able to switch one littleone correction method, apply that
to all the apps that they apps thatthey serve to save so much data and
thus reduce bandwidth costs on both.
That's something that, you know, it'skind of like a backend thing that
most users will never most users anddevelopers will never have to consider.
(33:34):
But one thing that I'm sure mostdevelopers are familiar with, and at
least a lot of users are, have heard ofis what Logan brought up before the whole
split APKs and or app bundles featureand how it's delivered to users through
the Google play feature delivery feature,which used to be called dynamic delivery.
This is both a really neatfeature and also pretty contr.
(33:56):
Which lo alluded to earlierand I'll get into in a second.
So for those of you who don't knowthe idea behind the split APK and, and
or at bundle is that most users don'tneed to have installed a monolithic
APK file that contains every assetcode chunk and language resource.
Instead, you only need the bare minimum toget the app and its core features starting
(34:16):
all that's contained within the base PK.
And then Google play can push theremaining split APK files that contain the
assets, features and language, resourcesthat are actually needed by the user.
So for example, if your assistantlanguage set to English, then
you'll get the split APK file thatcontains English language strings.
You won't get the French languagestrings cuz you don't need that.
So this concept is actually quite old.
(34:38):
It's older than thera.
Split a BKS were introduced withAndroid 5.0, but a lot of developers
didn't really make use of them untilthe Android app bundle requirement
came into effect in August, 2021.
So starting August, 2021, every newapp that's uploaded to Google play has
to use the Android app bundle format.
The bundle format wasintroduced with Android.
(35:00):
And to explain a bit about what it is.
It's also a valid zipfile, just like APKs.
So within this AAB file, you haveall the resources, assets, and
libraries that are needed to generatemultiple configurations of the app.
And it's structured in a way so thatyou have all of these segments kind of a
segment apart from each other, you havea base module, you have dynamic feature
(35:20):
packs and you have asset packs that thistool called bundle tool uses to generate
specific split APK configurations.
So what developers do is they generate theAndroid app bundle file in Android studio.
They upload that to Google play and thenGoogle play generates split APK files on
demand when the user downloads the app.
So this has a potential to saveusers, a lot of storage space on
(35:44):
APKs and also thus reduce how muchbandwidth is needed to download.
So while the idea behind this is sound,you've mentioned Logan, that there are
some issues with how it's implemented.
Can you explain what some ofthose concerns are and what
Google's done to address them?
If anything.
There are a few
Logan (36:00):
valid concerns with not necessarily app bundles themselves, but
the implications of how they're used.
So Google play uses thisfeature called play app signing.
And so you upload your app bundleand then Google will sign and
generate the APKs themselves.
As we talked about earlier,the Android operating system.
Will pin the signingkeys of those AP case.
(36:22):
But in this case, it'sGoogle, who's signing them.
And so theoretically, Googlecould modify the APK and deliver a
malicious update either intentionallyor after being compromised.
And so that's one big concernwith, uh, app bundles.
They've mitigated this somewhat withthis feature called code transparency.
How that works is a developer cangenerate this separate signature
(36:45):
file and upload it to the play store.
And users can download that and makesure that the APK that they get was
generated from the app bundle that thedeveloper made, but it's not a perfect
solution for one, the developer has tochoose to generate this and upload it.
Then the user has to download itthemselves and verify it themselves,
which already cuts out a lot of people.
(37:05):
Most people aren't gonna try todo that for every single app.
They.
Another problem is it doesn't verifythe entire file code transparency
doesn't verify the entire APK.
And so things like resources couldstill be modified, which could be
used to change the UI or somethingand trick the user into doing
something that they don't intend to.
Those are a couple of the concerns.
The way Crescent works aroundthis is that developers upload
(37:28):
the split APKs themselves.
The tool that Google uses togenerate split APKs is freely
available and open source, and youcan download it and use it yourself.
And so AC Crescent allows developers todo that and just upload the split APKs.
And so they can still be used withoutthe trust issues with app bundles.
To be fair to Google.
They do a very good job of thisand they're handling these keys.
(37:50):
They have a whole white paper ontheir infrastructure, and there
are legitimate reasons for it.
For example, I didn't learn thisuntil recently, but developers
often lose their signing keys.
Once you lose your signing.
Key, the OS won't accept updateswith a different signing key.
If you didn't rotate it right.
And so if you lose your signingkey, all of your users are left
in the dark without an update.
Whereas with Google play, if youlose your upload key, which you have
(38:13):
to use to authenticate yourself,Google still has the signing key.
So they can just generate a newone for your account and you can
still deliver updates as normal.
So there are benefits to it, but thereare definite security and trust drawback.
Mishaal (38:26):
What about the challenges this whole play app signing introduces
when it comes to distributing appsacross multiple app stores, like
since Google is signing the apps thatget delivered to your device, right?
If you were to take that app, And youwere to try to say you had Samsung
galaxy app store installed as well.
And you tried to install an update thatwas already available through Samsung's
(38:47):
galaxy app store for the same exactapp you wouldn't be able to because the
app that's uploaded to Samsung storeis signed with a different key than
the one that's uploaded to Google play.
Can you talk a bit about that?
That's
Logan (38:58):
partially a store concern and partially a developer concern.
Generally speaking, if you havean app that's being signed with
different keys, say for Google playand say, you're really seeking it on
GI Huber, your website or something.
If you're not using the same key,
Mishaal (39:12):
you should
Logan (39:12):
change the app ID, which is basically just an internal
identifier to make an app uniquelyidentifiable to the operating system.
I know I keep bringing itup, but for example, Graphos
does this with their camera.
There's a version.
They sign themselves and theversion that Google signs.
And so they have different app IDs,so they can both be installed at
the same time without conflicting.
So that's generally whatdevelopers should do.
(39:33):
If they're uploading to multiplestores that are signing with different
keys, they should change the app ID.
So they don't conflict.
But many aren't aware of that.
And so that does cause a challenge,especially for apps that are say
on both Google play and F Androidsince F Android signs with their own
keys, but doesn't change the app ID.
They conflict with Google playversions, and you can't have both
(39:53):
installed at the same time oruse one to update to the other.
Mishaal (39:57):
I've talked about this before, but the Android app bundle, there's
a lot of clear and obvious benefits.
It brings to both Google and to userswhen it comes to storage and bandwidth.
But it's hard not tohave like a cynical view.
Oh, how does this lock users moreinto the Google play ecosystem?
Like, is it a coincidencethat it has these benefits?
You tell me because , I'm suremany people will think that there's
(40:20):
no coincidence that, you know, ithas this benefit of doing that.
But to be fair, there are some ratherunique things that can be done with
Android app bundles that you can'tdo easily with the monolithic KPK.
So, for example, at the beginningof this year, Google announced the
new feature that Google play willbe getting called app archiving.
So basically what this does is thatGoogle will be using the bundle that
(40:42):
delivers upload to generate a newsplit APK file called an archived APK.
So this archived APK is basically a.
That holds nothing but code to launchthe app store to redownload the full app.
So this stub basically has nothing in it.
It's just an empty app.
That's signed by the samekey because Google signed it.
(41:02):
It has the app icon.
Because it's actually stillinstalled on your device, but it
has like no resources, no nothing.
It's basically like a multi kilobyte fileinstead of like the tens, potentially
hundreds of megabytes file that theoriginal app was using up on your device.
So by introducing this app, archivingfeature users will be able to archive an
app and reduce its storage requirementswithout actually uninstalling the.
(41:23):
And if you're interested in learningmore about that, by the way, I did a
deep dive on the Android buys column.
I, I think that's quitean interesting feature.
And I'm really curious to see if otherapp stores actually replicate this.
Like Google did design it in such a waythat other app stores could replicate it.
But again, like the whole permissionsdata, the permission safety form
stuff, I don't really know ifany alarm stores actually follow
(41:44):
through and do what Google's doingand all, everything they're doing.
But before we close off this discussion,cuz we're getting close to time.
I wanted to bring up a prime example.
Of a market where non Google playapp distribution is successful.
And that's China, China, for thoseof you who don't know, does not allow
access to any Google services, the factthat Chinese Android users are using
(42:05):
non Google play app repository is moreout of necessity than anything else.
So from what I've heard, speaking toChinese users and reading online is
that Chinese users source APKs from amultitude of app stores, a multitude
of websites, many third party appposting websites, and more like, it's a
huge mess of where they get apps from.
(42:27):
It's it's really decentralized and that'sactually, you know, Kind of the model
that desktop users have been dealing withfor a long time, the decentralization,
but without that centralized, Google playand GMs providing those APIs, the Chinese
market kind of struggles to deal withthings like push notifications, whether
like 13 different push notificationAPIs, which requires like, if you
(42:49):
have 13 different apps, all usingdifferent push notification implement.
Then that means you have 13 differentapps having these foreground services,
constantly waiting for push notificationsto be pushed to your device and that
results in a whole bunch of appswaking up at various random times and
then destroying your battery life.
So if you're wondering why a lotof Chinese phone brands seem to
(43:09):
have these really, really, reallyaggressive battery saving measure.
It's a result of this because there's nounified centralized, Google play services.
Like there is outside of China,knowing what you know about
how the situation is in China.
Do you prefer the centralizedmodel we have now with Google?
Or do you think a fully decentralizedapproach would be better or
maybe something in between.
(43:30):
At
Logan (43:31):
a high level, I would say the decentralized approach
could be better, but it won't be.
And the reason I say that is becausewhen you have multiple parties
providing updates to their ownmechanisms, a lot of them aren't
doing it well or doing it right.
Like we've seen how a Google play store,although this largely due to GMs the
place where actually does securityevaluations, they do app distribution.
(43:53):
Very, very well.
It's hard to make sure that thosesame restrictions, uh, security and
privacy are being enforced acrossall these different mechanisms.
And most app developers won't makesure updates are delivered securely
and timely and automatically.
And so that's why I would say thedecentralized approach could be better,
but it won't be say, if you have anapp that updates itself, that's like
(44:16):
the ideal situation you can have, butmost developers won't want to do that.
It's extra work and it's hard to do.
Decentralization in the sense of sayone app updating from multiple different
places actually violates Android securitymodel there's security model mandates
that one app store is just one app source.
It downloads apps from oneplace, and there are problems
(44:37):
if you try to change that.
And then there's also a problem.
If you're downloading from multipleservers with the same app, say like, does
you can't use certain security featureslike TLS certificate pinning that would.
How I would evaluatethe overall situation.
Centralization is unfortunate in someways, but I think if the centralized
(44:57):
party knows how to do things well,I would say Google does, then the
situation would be much better.
In that case, you don't have to trustas many parties to do the right thing.
Right.
Mishaal (45:08):
And fortunately, you know, Android isn't as locked down as iOS,
where you have no choice betweencentralization and decentralized.
It's all centralized all the time.
At least with Android.
99% is through Google play, but that1% outside of China, at least you
have the freedom to choose what appsand what app stores you're using.
(45:28):
And of course, since a S P itself is open.
You also have the freedomto customize a O S P.
And then build in your own appdistribution ecosystem to that
distribution and to the devices thatyou are deploying this build on,
which of course is really importantbecause a S P as I said before, does
not come with an app store by default.
So you have to do something custom.
(45:49):
If you're going to builda O S P without GMs.
David (45:52):
App distribution is actually something that is very near and dear
toper, you might even say it's kindof the core of our business in a lot
of ways, because what Esper does everyday is deliver applications and updates
to applications, to dedicated devices,which are things like kiosks business
tablets, things that typically don't haveGoogle mobile services to begin with.
(46:14):
And wouldn't have a reason toother than having a way to.
Apps, but obviously that's not a goodsolution for a lot of reasons, for a lot
of different kinds of devices, some ofwhich are cost, some of which are time,
some of which are engineering effort.
I mean, all of thosethings generally are true.
Being a GMs partner versus using AOS.
P.
(46:34):
So if you're using a O S P to build akiosk or to build a point of sale or
to build display, signage, whatever,it might be a medical device, perhaps
home exercise equipment, we'reliterally on a climbing machine.
You need a way to deploy updatedAPKs to that Android device.
And if you don't have the play store,that's a little easier said than done
(46:54):
at scale, easy to do with a few dozen.
And once you get to a few hundred,few thousand tens of thousands of
devices, That gets pretty hard.
And so what Asper provides along withour robust device management tools
is a really, really sophisticated wayto deploy your apps, stage updates,
group them choose when and where theygo out, set conditions for success.
(47:16):
You.
And deploy your app in a way thatis highly observable and where
you know exactly where it's going.
You know, every device that'sreceived it, every device that
hasn't, you're getting exceptionreports when something goes wrong.
So if you've been wondering how you candeploy applications to Android devices
in a really specific, targeted, highlyreliable way with an enterprise grade QoS,
(47:38):
come talk to us at SPER we're at SPER dot.
I.
Mishaal (47:42):
Thanks David, for the obligatory per plug in the Android bites podcast.
And of course, here's the obligatoryclosing segment of the podcast where
I give our guests the opportunity toexplain where can you follow him online?
So Logan, where can peoplefind you and your work?
You can find
Logan (47:59):
me on Twitter and on GitHub as Berry ma that's my
handle on most other places.
And then Crescent is ongithub.com/crescent, ACC, R E S C E
Mishaal (48:12):
NT.
And you can find David and Ion ESER that's blog.sper.io.
And thank you all again for listeningto another episode of Android bites.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!