Artwork for podcast Android Bytes (powered by Esper)
The Android 13 teaser episode
Episode 2 • Bonus Episode • 26th January 2022 • Android Bytes (powered by Esper) • Esper.io
00:00:00 00:34:10

Share Episode

Shownotes

Sign up for the 451 Research and Esper webinar: https://www.esper.io/webinar/digital-transformation-for-dedicated-devices

On this bonus episode of Android Bytes, David and Mishaal discuss some of the upcoming features in the Android 13 platform. Yes, the one that isn't announced yet.

Transcripts

Mishaal:

So just for some context, as you may know, Google

Mishaal:

released Android 12 in October.

Mishaal:

They released the source code first on October 4th, and then the stable

Mishaal:

update per pixel phone or 19th.

Mishaal:

So we're right off the release of one major Android operating system update.

Mishaal:

And we're not expecting another major update until early 2022.

Mishaal:

When Google were release Android 12.

Mishaal:

And it's kind of arguable whether or not that's actually going to be a major

Mishaal:

update because for most devices, it's not going to be, it's targeted more

Mishaal:

at foldables and large screen devices like tablets, but the update that

Mishaal:

everyone who owns a smartphone, an Android smartphone will look forward

Mishaal:

to is Android 13 in late 20, 22.

Mishaal:

Most likely around September, October, if Google follows.

Mishaal:

They're pattern.

Mishaal:

I don't think, you know, we delayed like Andrew 12 hours by a month

Mishaal:

because I, I don't foresee them making any major UI overhauls like

Mishaal:

they did with 12, for Android 13.

Mishaal:

We're still many, many months away from enter 13 regardless, but despite

Mishaal:

that there have been a series of leaks and ongoing AOSP code changes that

Mishaal:

reveal some interesting information about the next Android update.

Mishaal:

Except for release late next year.

David:

Yeah.

David:

And I think that we can kind of, you know, go from there.

David:

I think that we've got most people that are going to show

David:

up from our side, at least.

David:

Where do you think we should start?

David:

Mishaal?

David:

What are some of the the big items that 13 seems to be focusing on.

Mishaal:

So one of the most significant changes that users should look

Mishaal:

forward to is the new app languages.

Mishaal:

And that feature is code name Penn lingual, because the idea is that

Mishaal:

currently in Android you can set one system language and the languages and

Mishaal:

input settings, and that language is what's applied system-wide across settings

Mishaal:

interface across the quick settings panel, and most applications will address.

Mishaal:

That language the language that you set in settings, some applications

Mishaal:

do provide their own in-app language settings, but it's not very common.

Mishaal:

And the downside of that is say your a, you know, you speak multiple

Mishaal:

languages or your native tongues in English, but some applications

Mishaal:

don't have very good translations to your local tongue right now.

Mishaal:

And Andrew.

Mishaal:

You basically have to deal with a really bad translation for that app.

Mishaal:

While you set your system language to say your native tongue maybe

Mishaal:

might be like Italian or something.

Mishaal:

But an Android 13, what Google is doing is they're adding any new app

Mishaal:

language feature that will let you set the language on a per app basis.

Mishaal:

The application itself still needs to support that language.

Mishaal:

It needs to have the strings that are translated to that language, but this

Mishaal:

will make it so you don't have to choose one language for the majority of apps.

Mishaal:

You can pick your preferred language for each application that you want to.

David:

Now I know that there's some things the Google's been doing

David:

on the developer side for Android apps around languages in terms of

David:

split it or excuse me app bundles.

David:

So is there any impact here?

David:

The developers should be aware of because I know that developers,

David:

for example, can specify like, Hey, you know, like if my users.

David:

Uses us English only download us English asset pack.

David:

Versus, you know, whereas before, you know, a developer might put all

David:

of their like international language assets and the version of an app

David:

because they needed all of it.

David:

It became bundles.

David:

Let them split that up now with pan lingual.

David:

Will we see, you know, Google leveraging that ability to dynamically generate,

David:

you know, APKs with mulch files, like, is that going to be part of.

Mishaal:

That's an interesting thought.

Mishaal:

Right now, depending on the language that you have and depending on whether or not

Mishaal:

the app support that bundles, whenever you go to download an app from the play

Mishaal:

store, it does download the base APK, the.

Mishaal:

The N a series of splits based on your architecture and your

Mishaal:

screen layout and your language.

Mishaal:

But this app language feature is something that you said

Mishaal:

after you've installed the app.

Mishaal:

So what may end up happening is that after you install the app, and then you change

Mishaal:

the language for that, The play store will recognize that the configuration for that

Mishaal:

app has changed and will inmate download the additional split for that language?

Mishaal:

We don't know.

Mishaal:

We don't have specific details on how this works because we don't have, you

Mishaal:

know, the source code for Android 13 or the documentation for this feature.

Mishaal:

But that's how I think it might address.

David:

Yeah.

David:

And multi language support is something that Google has is, you know, it's

David:

not something we think of as much in America, obviously, but it's an

David:

extremely important feature of the platform given its global reach.

David:

And I bet this has been high on the list for people as a

David:

requested feature for a long time.

Mishaal:

Oh yeah.

Mishaal:

It's definitely something that I've seen many requests for.

Mishaal:

And community developers have come up with like, Android modifications that

Mishaal:

enable this kind of functionality, but the big problem with previous solutions

Mishaal:

is that changing the language on your device is a very heavy process.

Mishaal:

It causes applications to restart it.

Mishaal:

It's, it's pretty slow in itself.

Mishaal:

If you just go to your phone and try to change the language, you'll notice

Mishaal:

it hangs for like 2, 3, 5 seconds, maybe when it's changing the language.

Mishaal:

And it's just not a very.

Mishaal:

Experience right now, if you were to try to take what's happening right now

Mishaal:

and apply that on a per rep basis, every time you load an app that has a different

Mishaal:

language, that it would just hang for like five seconds and that's not good.

Mishaal:

So we don't know exactly how it'll work on Android 13 and I suspect it

Mishaal:

probably won't be a laggy experience because that would just be awful.

Mishaal:

A solution that one of listeners on this call right now, Karen mentioned is

Mishaal:

that the configuration change might be applied only to the app sandbox, so that

Mishaal:

other applications won't be affected

David:

yeah.

David:

And I think that's probably, that's a really good point, you know, switching

David:

system languages, like the heaviness of that process, Google probably just wants

David:

to avoid users ever having to touch that setting to begin with aside from initials.

Mishaal:

Oh, yeah, you'll, you'll set the system language to be your,

Mishaal:

whatever, your preferred languages.

Mishaal:

And then if there's a particular language that you find more comfortable

Mishaal:

in with a particular app, then you'll set that and it will be

Mishaal:

much more user-friendly that way.

Mishaal:

And I'm surprised it's taken Android this long to add this feature, but

Mishaal:

you know, better, late than never.

David:

So what else do we know about the 13 so far?

Mishaal:

So this one the next feature, we are less sure about.

Mishaal:

The original report on XDA developers is not 100% certain that this feature will

Mishaal:

be added, but if it is added in the way it's described, it would be a monumental

Mishaal:

change to the way Acacia work on it.

Mishaal:

So right now, notifications can be posted by after they're installed and they do

Mishaal:

not require any permissions from the user.

Mishaal:

The moment you install an application, it has the ability to post notification.

Mishaal:

And if you've seen advertisements posted on your device, you know, that

Mishaal:

they can get pretty annoying because applications will see the notifications

Mishaal:

panel as a way to just promote themselves or promote their services.

Mishaal:

It's a common way for apps to try to get these to reengage with their application

Mishaal:

if they haven't opened it in a while.

Mishaal:

But in the end, it's just not a very user-friendly experience

Mishaal:

because most users are not going to go into settings and then revoke

Mishaal:

the ability of an application to post notifications after this.

Mishaal:

So what might be changing Andrew 13 is that Google is adding a new runtime

Mishaal:

permission called post notifications and what a runtime notification or what our

Mishaal:

one-time permission is, is a permission that can only be granted by the user

Mishaal:

after the application has been installed.

Mishaal:

And the user has to granted by explicitly tapping allow on the dialogue that

Mishaal:

appears like in the middle of the screen.

Mishaal:

So there's no.

Mishaal:

Trick the user into automatically opting in to notifications.

Mishaal:

They have to explicitly grant the app permission to do that.

Mishaal:

And by doing so that will probably significantly cut down on how many

Mishaal:

apps can abuse notifications for advertisements or spam, et cetera.

David:

This would be a huge change for developers and for users alike.

David:

And I think we've seen.

David:

There's a, there's an interesting dynamic, the advertisements on

David:

Android because it's an advertising company and they're more accepting.

David:

I think, of that than apple historically has been.

David:

And so on iOS notifications, as far as I know, have always been often.

David:

They definitely have been as long as I've been using it.

David:

So I think that that is always been kind of a philosophical disagreement

David:

that may be Google had with apple.

David:

But I have to say that like, This seems like maybe a thing where, you know, in

David:

China, obviously we see manufacturers of Android phones doing all kinds of

David:

crazy things to notifications because a, they don't run GMs and they don't have

David:

to worry about compatibility so much.

David:

And B because the app spam situation in China, because they do not have.

David:

A truly like one size fits all app store.

David:

That's a coalition of app stores and they're all responsible for

David:

gatekeeping their own content.

David:

You can end up with a lot of bad content and also, you know, piracy

David:

and other things exist everywhere.

David:

So you have to look out for.

David:

And I think that we were all confused for so long.

David:

Like why would you want such aggressive notification management on Android?

David:

Why would you want to lock down applications so hard?

David:

And I have to say, I have slowly turned the other direction where I used to

David:

be so against opt-in notifications.

David:

I am now.

David:

I think I am pro opt-in notification because more and more apps that

David:

I use I've started abusing this.

David:

And even on iOS, it's still a problem, you know, but one of the, the things

David:

that developers do or companies, I should say, because I don't think

David:

individual, this is a super cool thing to do these reengagement tactics that

David:

they use in their applications to the notification trays, basically like.

David:

They start to obfuscate like the channels that are going to send you

David:

kind of promotion notifications.

David:

They make it more difficult.

David:

They buried in the settings with Android notification channels.

David:

You do have good control over that, provided the app, respects those

David:

channels and defines them properly.

David:

But on iOS, you know, I, I have apps where.

David:

I can't get rid of notification permissions because I need to

David:

get notifications from that app.

David:

But I also know it's still going to advertise to me.

David:

So this is a problem on all platforms.

David:

And it's interesting to see that Google is moving that direction

David:

because that is, that is a huge switch,

Mishaal:

right?

Mishaal:

Traditionally Google is kind of wary about making everything permission, gated,

Mishaal:

because if you make everything opt in, then users will be much more likely.

Mishaal:

By default grant permission to everything, because if you make it

Mishaal:

annoying for an application to actually do what you installed it to do, then

Mishaal:

you're not going to be giving much thought to these permission prompts.

Mishaal:

So Google wants to add permissions for sensitive features such as access

Mishaal:

to the camera or location, but they don't want to overdo it and make

Mishaal:

people just click allow, allow, allow.

Mishaal:

So.

Mishaal:

It is interesting to see that Google is finally, or may finally be taking

Mishaal:

this approach to notifications because being able to post a notification is one

Mishaal:

of the core functionalities of an app.

Mishaal:

And it's one of the ways that an app, as you said, can, re-engage a user with

Mishaal:

the service app, if they haven't been using it for awhile, but it seems like

Mishaal:

it's gotten to a point where so many applications that have just abused that

Mishaal:

permission, that they've decided to relegate it to a runtime permission.

David:

And I think that, you know, the that's also just kind of an effect, I

David:

think, of the way smartphones are used and what people use them for, you know,

David:

for example, gaming you know, I think the games, you know, if you've ever played

David:

a mobile game, you know, that most games are shameless abusers of notifications.

David:

Their developers are, let's say a little more cutthroat about

David:

re-engagement strategies, then I think most app developers.

David:

And so I think that, you know, probably.

David:

As Android gaming has become more popular, which it has.

David:

You probably do see more and more user complaints basically saying this, you

David:

know, like this game is spamming me or this app is spamming me and probably

David:

Google does get pressure from some developers to be like, Hey, listen, you

David:

know, like I'm getting like, Unfairly review bombed you know, for this behave,

David:

don't understand or that like, you know, either a user doesn't understand

David:

that my app is responsible for sending these notifications or they don't, you

David:

know, understand the way to like, like disengage from them or do turn them off.

David:

So I think that Google does have to consider both directions, but

David:

at the end of the day, Like when I look at the experience on Google

David:

Chrome, like you have to opt in to notifications on a web browser.

David:

And to me it would be insanity if you didn't have to opt in.

David:

And so that's, that's, what's funny to me about this is it's very, like, it's

David:

very personal and it's very context dependent where you want notifications.

David:

And I think that Google moving to an opt-in system is, you know, just

David:

honestly it's respecting that more.

David:

And I think I'm definitely forward at this point.

David:

Like I've convinced my.

David:

And I, we did not start there.

David:

Like probably if you asked me five years ago, it would

David:

have been this isn't terrible.

David:

I would have said this is a terrible idea,

Mishaal:

greed.

Mishaal:

And the next major change that I'm sure many will think is a

Mishaal:

terrible idea, especially if you're a developer, but it's.

Mishaal:

From a user perspective, it's much appreciated is Google's ongoing war on

Mishaal:

background services, and I'm sure many developers absolutely hate the amount of

Mishaal:

restrictions on applications, but from a user's perspective, it is nice to know

Mishaal:

that, you know, something is being done to curb applications that abuse how much

Mishaal:

access they're allowed in the background.

Mishaal:

In terms of permissions in terms of services, they can run because, you know,

Mishaal:

you want your phone to last all day.

Mishaal:

You don't want a phone that day.

Mishaal:

You want something that you can unplug in the morning and last you throughout the

Mishaal:

Workday and maybe a second day without even having to recharge it overnight.

Mishaal:

So the feature that Google is supposedly working on is called terr T a R E,

Mishaal:

which stands for the Android resource.

Mishaal:

So basically right now over the years, Google has been addressing what

Mishaal:

applications can do in the background by changing how they queue tasks.

Mishaal:

So in the early days of Android and application could start a what's

Mishaal:

called a foreground service and they could basically run tasks as

Mishaal:

they pleased whenever they wanted.

Mishaal:

But over the years, Google started to cut down on.

Mishaal:

Foreground services and the ability for apps to start them.

Mishaal:

And right now, if an application wants to start a foreground service they need

Mishaal:

to have a persistent notification, which is, which makes it very obvious that an

Mishaal:

application is running in the background.

Mishaal:

And that basically shames a lot of apps away from that.

Mishaal:

Like right now, if I pull down my notification panel on.

Mishaal:

I see a persistent notification for you, because I always want that app to

Mishaal:

be running because I want it to be able to respond to events in real time, but

Mishaal:

very few applications need to do that.

Mishaal:

And so what Google has come up with our API is like alarm job

Mishaal:

scheduler and work manager.

Mishaal:

Some of these work on AOSP, some of these require a Google play services

Mishaal:

to work, but basically the Google play services or the Android system itself.

Mishaal:

Except jobs from applications and they will, it will decide how to queue them and

Mishaal:

it will run these jobs based on factors.

Mishaal:

Like whenever the device is plugged in, whenever it has

Mishaal:

sufficient battery life, et cetera.

Mishaal:

That's how things work right now and enter 13, it seems like Google will be enhancing

Mishaal:

this concept to basically adjust.

Mishaal:

How many jobs an application can queue.

Mishaal:

Cause right now there's a maximum of 50, that can be cute through these APIs.

Mishaal:

And it seems that the system right now is not very intelligent.

Mishaal:

It just lets applications, queue jobs.

Mishaal:

And then the API APIs you know, the Google play services decide when to

Mishaal:

run them based on like your charge rate, your charge level, et cetera.

Mishaal:

But what the Android research economy will do is it will stop.

Mishaal:

Quote-unquote credits to apps to spend.

Mishaal:

And the total number of credits that the Android recess economy will assign.

Mishaal:

What it's calling the balance will depend on things like the current

Mishaal:

battery level and how many credits are assigned to an app will depend on the

Mishaal:

type of task that the app wants to queue.

Mishaal:

Is what my understanding is of tear.

Mishaal:

So basically if an application wants to queue a task, it

Mishaal:

won't be treated the same.

Mishaal:

As another application that wants to queue another task the Android, which is under

Mishaal:

me, will determine how many tasks can be queued based on the current battery level.

Mishaal:

And it will decide how many tasks a app can queue based

Mishaal:

on how important that task is.

Mishaal:

So like some applications will be able to queue more or have their tasks

Mishaal:

executed earlier than others based on.

Mishaal:

The importance of those tasks.

Mishaal:

So it seems like the way that Android will be executing background tasks will

Mishaal:

be more intelligent and Android 13.

Mishaal:

And in effect that will improve the battery life of your.

David:

So this is, this is another really human for me because you know,

David:

battery life is obviously like, you know, when I go between my iPhone

David:

and my pixel, like the battery life is very noticeably different.

David:

And the, yet I don't want to turn this into the phone right

David:

show, but like my pixel six, like notifications are incredibly delayed.

David:

You know, like that behavior is not actually.

David:

Like performing in the way I would like, and I do wonder you know, on the

David:

Android team's end of things, like this sounds very complex, Michelle, what

David:

you're describing, like a system of like credits, obviously developers, if

David:

they're not like actually exposed and having to think about this very actively.

David:

But the systems handling most of that that's, you know, makes it a

David:

little different, but it feels like.

David:

This is the same story we get from Google every year about battery life, which

David:

is we are going to use heterogeneous processing to do this more efficiently.

David:

We are going to make sure apps respect, like, you know, when they

David:

can schedule jobs and we're going to make this all more efficient and

David:

we're going to use automate herb.

David:

We're going to use AI or ML to like learn.

David:

And I have yet to see a lot of evidence of that actually working.

David:

Would you agree with that assessment or am I just like totally off base here?

Mishaal:

I think the reason why we haven't seen like McKinley improve

Mishaal:

battery life over the years, it's more to do with the hardware of the

Mishaal:

devices rather than the software.

Mishaal:

I think if we were to run the same, like a current software release on really old

Mishaal:

hardware, we'd get amazing battery life.

Mishaal:

It's just that phones nowadays have just crazy high resolution displays

Mishaal:

a one 20 Hertz variable refresh.

Mishaal:

Super bright hole, led panels, all this, all these different sensors, like the

Mishaal:

cameras we have, multi-camera arrays all processing at the same time, it's just,

Mishaal:

there's just so much on the internals that would drain band even with crown tasks,

Mishaal:

you know, being a lot more restricted and that lead to better battery life.

Mishaal:

That's, that's not enough to keep up with the significant advancements in our.

Mishaal:

So, do we know if this is going to be like exclusively based on battery

Mishaal:

life or is it going to take other hardware like Ram into consideration

Mishaal:

to we don't know what the factors are?

Mishaal:

What, what terrible use to determine how to assign credits or

Mishaal:

what the total balance should be.

David:

And I mean, we don't want to get into necessarily what Google will or

David:

won't, this is still not a released thing.

David:

But I guess, you know, what is, where do we see this having the biggest impact,

David:

I guess, what kind of applications do we feel would have like an outsize of.

David:

Basically like what applications are going to look at this and

David:

say, oh no, this is really bad.

David:

Or conversely, which ones are going to say, oh, this is really good.

David:

Because I'm sure that there are apps out there that probably blurry on the

David:

line between abusive or just eat G send a lot of notifications and you

David:

know, potential issues they could run into here with these changes.

Mishaal:

Yeah.

Mishaal:

That's a good question.

Mishaal:

And honestly, I'm not entirely sure on about which applications

Mishaal:

would be the most effective and which applications would not be.

Mishaal:

From my understanding, the alarm manager API is used to schedule tasks that

Mishaal:

need to be executed at a specific time.

Mishaal:

While the job scheduler slash work manager, API APIs are used to basically

Mishaal:

defer a task to an undefined point in time because it doesn't need to be executed

Mishaal:

immediately or at a specific time.

Mishaal:

There are just so many different kinds of apps on the market that use these APIs.

Mishaal:

So I can't really tell you like with acted in which won't be.

Mishaal:

I know there'll be certain kinds of applications that will be more effective

Mishaal:

than others, and there's, there might be a lot of complaints about the way

Mishaal:

this is implemented, because I, I'm not sure if it would be immediately

Mishaal:

obvious to a developer, whether or not their app is less deprioritize over.

Mishaal:

We'll just have to see what kinds of document, what kinds of callbacks

Mishaal:

Google will provide to apps.

David:

Yeah, another facet of this is the effect basically on OEMs because

David:

you know, Michelle was, you know, like when Google updates, CTS, and there

David:

are new battery saving features, CTS changes pretty significantly usually.

David:

Because Google doesn't want manufacturers changing these behaviors, at least not.

David:

Huge ways.

David:

You know, I don't know the nuances of like a lot of the power

David:

saving rules and CTS right now.

David:

Or excuse me,

Mishaal:

CDD.

David:

CTS is the compatibility test suite CDD is the document.

David:

But anyway, like ed is quite nitty gritty about like things you can and

David:

can't do with power saving features.

David:

Do you think it's likely that Google will, you know, have to

David:

enforce this on an OEM level?

Mishaal:

I have a good feeling.

Mishaal:

This feature will be.

Mishaal:

Mandatory for Android 13 devices, but I don't know if Google will mandate

Mishaal:

the exact values or the parameters that they're setting up for care.

Mishaal:

I suspect that OEMs will be able to tweak the parameters that

Mishaal:

are, that are listed in those screenshots posted by AXA developers.

Mishaal:

There, there will probably be a default and Google play services would probably

Mishaal:

be able to modify those values.

Mishaal:

I think OEMs would probably have a level of control over it.

Mishaal:

Yeah.

Mishaal:

Because

David:

they do currently with the adaptive battery settings.

David:

There are some values they can change.

David:

And I think that I don't want to point fingers here.

David:

We've heard of manufacturers adjusting these things, such that

David:

break the feature per se, but it makes it a lot less effective.

David:

I think that we've seen some phone companies that like, you know, crank

David:

those things all the way off so that you get all of your notifications instant.

David:

But battery life is very negatively impacted.

David:

And then we see it in the other direction.

David:

For some OEMs crank up the asynchronous like notifications so far that you

David:

can go like a half hour and not get the notification on your phone.

David:

So controlling the consistency of that experience is not like a.

David:

A concrete thing for Google, you know, they've created guardrails,

David:

but you know, we don't even know until the feature is announced.

David:

And then the phones that use the feature come out and then how

David:

would it perform on those phones?

David:

We don't even know how effective it is necessarily.

David:

So that's what makes it hard, but stuff like battery life to hardware,

David:

like you said, is a great point.

David:

You know, the phones are simply doing more work and we have to consider that.

David:

But on the other side of things, you know, with the software, you know,

David:

that's, that's also something that's changing, you know, year over year.

David:

So with with stuff with power, like, you know, it's, it's really hard to say

David:

because I think that manufacturers are going to have really strong opinions

David:

about how to manage their devices power, because it is the bears, they own it.

David:

And they may also have a different impression of like what their users

David:

want in the experience they expect.

David:

Samsung may have a very different set of like assumptions they're making in

David:

terms of how users want to receive their notifications and how critical that is

David:

versus say one plus and Google makes some accommodations there for them to, you

David:

know, tweak certain settings accordingly.

David:

But the problem is that for developers, I assume in general, that's very open.

Mishaal:

I agree.

Mishaal:

And there are a few more major changes that I'd like to mention.

Mishaal:

The next one is possible full support for Bluetooth low-energy audio.

Mishaal:

So if you're unfamiliar the Bluetooth SIG the, basically the organization

Mishaal:

that defines the Bluetooth standard, they announced the low energy audio.

Mishaal:

Codec and the standard.

Mishaal:

And basically the promises that it makes is that it will enable high quality audio

Mishaal:

streaming at a very low power without massively increasing the data rate.

Mishaal:

So basically it's just a significant improvement across

Mishaal:

the board for audio playback and audio streaming over Bluetooth.

Mishaal:

And right now, although there are multiple Bluetooth chips on the market

Mishaal:

on devices that are shipping right now that support Ellie audio, Android itself

Mishaal:

does not support the new standard with a new codec, but that might change with

Mishaal:

Android 13 because Google has been working on an open source L C3 in coder L C3 is

Mishaal:

the codec that's used for both Bluetooth Ellie audio, and that's been submitted to.

Mishaal:

And they're also working on the setting settings for the new

Mishaal:

codec within developer options within, within the framework.

Mishaal:

So my guess is that Andrew 13 will probably be the first release where

Mishaal:

Android itself will support selecting Ellie audio as the ADP source codec.

Mishaal:

But we'll have to wait and see if.

Mishaal:

Device makers actually have audio products on the market that support

Mishaal:

Ellie audio, because you need both the audio sync and source.

Mishaal:

So we have the source, which is the smartphone, the device running Android 13

Mishaal:

with the requisite Bluetooth chip, but you need to sync, which would be the earbud

Mishaal:

or headphone that supports Ellie audio.

Mishaal:

And I don't think there are any on the market right now, the support it.

David:

And just for some context here, I'm reading up on this because.

David:

The reason we care about this this Bluetooth Le audio feature it's

David:

enabling things like basically, like you can have, you know, you're going

David:

to have two people listening to AirPods at the same time on an iPad.

David:

Well, Bluetooth is going to be able to do that now in theory which is

David:

great because everybody wants that.

David:

It's basically increasing the amount of bandwidth, not, not increasing

David:

the amount of bandwidth, but the amount of audio you can put over the.

David:

Yeah, so like it's much more efficient.

David:

So yeah, that's a great example, you know, of another feature that Google has

David:

to implement again on that OSTP level and how things move kind of slowly.

David:

Granted, this is pretty new.

David:

So that's, that's pretty fast movement by Google standards, but probably that

David:

still means consumer product impact.

David:

Won't be till early 20, 23 at the earliest.

Mishaal:

And I'm the next change that I've, that I believe Google is working on

Mishaal:

based on comments made by Googlers is that there's worrying work done to decouple

Mishaal:

wifi scanning from location permissions.

Mishaal:

So for some context prior to Android 12, in order for an application to

Mishaal:

scan for nearby Bluetooth device, It would have to request the user

Mishaal:

to grant it location permission.

Mishaal:

And that led to a lot of confusion whenever Google wanted to roll out

Mishaal:

the COVID 19 contact tracing apps, because that would require scanning

Mishaal:

for new abrupt Bluetooth devices.

Mishaal:

But doing so would show a prompt, asking the user to

Mishaal:

grant their location permission.

Mishaal:

And so that led to a lot of users thinking these tracing

Mishaal:

apps are tracking my location.

Mishaal:

When all they're doing is just scanning for nearby Bluetooth devices.

Mishaal:

So what Google ended up doing and Android 12 is they added a

Mishaal:

new nearby device permission.

Mishaal:

So that apps wouldn't need to request for location access, just to scan

Mishaal:

for nearby police use devices.

Mishaal:

It seems like Andrew 13, we'll do something similar with wifi scanning.

Mishaal:

So in order for an app to scan for nearby wifi access points

Mishaal:

in 113, they may not need to ask for location permissions anymore.

Mishaal:

We haven't seen that brought up in any, in any of the images that are posted

Mishaal:

by x-ray developers, but a Googler has commented saying that that's

Mishaal:

one of their goals for Android 13.

Mishaal:

And the reason why right now, if you're wondering.

Mishaal:

Y Android requires location permission just to scan for nearby Bluetooth

Mishaal:

devices or wifi access points.

Mishaal:

Is that being able to get a list of nearby devices is actually something that can

Mishaal:

be used to infer your devices location.

Mishaal:

So that's the reason why they tied it to location permissions.

Mishaal:

It just ended up confusing users who thought that devices that just need to

Mishaal:

scan for those devices for legitimate purposes, maybe to connect to them or

Mishaal:

to find a better access point nearby.

Mishaal:

We're actually just tracking the location.

Mishaal:

So Google scrapped that idea and they're decoupling those two.

David:

Yeah, and I think that's a semantic issue.

David:

I mean, for example, you could also say like, if you open Google

David:

maps, AR mode, like that's not a really good example because that's

David:

using location permission anyway.

David:

But if you were using an AR experience that could figure out where you were

David:

based on what the camera was looking at, is that a form of location?

David:

Well,

Mishaal:

yes, it is.

David:

But does that mean it needs to be tied to a location permission and

David:

things obviously gets super muddy there.

David:

And I think that's probably where they came down by discussion with the scanning

David:

behavior for wifi and Bluetooth that it's too nuanced to explain to users.

Mishaal:

Okay.

Mishaal:

I think a really great example of where this confusion manifests is with nearby

Mishaal:

share basically Android's version of.

Mishaal:

I forgot the name of the iOS file sharing solution, but basically nearby share is

Mishaal:

the solution that lets you quickly share files with nearby a hundred devices.

Mishaal:

But right now if you were to use nearby share, you would have to grant the

Mishaal:

surface access to location and that might make you wonder why does a.

Mishaal:

Solution that just shares files with nearby devices need

Mishaal:

access to Michael location.

Mishaal:

And the answer is it actually, doesn't what it's doing.

Mishaal:

Is it scans for nearby Bluetooth devices?

Mishaal:

And then once it, once you, once a user picks a device to connect.

Mishaal:

It initiates a wifi direct connection to that device and that device, the

Mishaal:

other, the receiving device needs to scan for a local wifi access points

Mishaal:

and connect to that access point.

Mishaal:

So that's where the location permission comes in.

Mishaal:

And that's what the user is thinking that nearby shares

Mishaal:

actually tracking the location.

Mishaal:

And that's not the case.

Mishaal:

So by decoupling wifi scanning from location permissions

Mishaal:

nearby share in Android.

Mishaal:

We'll likely no longer ask for the user location.

Mishaal:

Ask for the near brown permission.

David:

Interesting.

David:

I wonder if we should just start putting a giant sticker on every

David:

phone when you open it, it says your phone knows where you are.

David:

Do you accept it?

David:

Because at this point it's kind of true, no matter what anything

David:

else that we should we should hit on Michelle before we end this

Mishaal:

week.

Mishaal:

There are a lot of other smaller changes that I'd love to talk about, but can't.

Mishaal:

You'll just have to wait and see, but there is one that there is

Mishaal:

public evidence of in AOSP and that I actually wrote a blog, wrote

Mishaal:

a blog post about two weeks ago.

Mishaal:

Now it's about how Google will use virtualization in.

Mishaal:

It's quite a complex topic, but I run down, I basically document the necessity

Mishaal:

of Google standardizing, the virtual machine framework and Android, and what

Mishaal:

they're doing to bring virtualization and how they're going to use it.

Mishaal:

I recommend giving that a read it's part of the Andrew dessert by column

Mishaal:

that I write, which is only accessible.

Mishaal:

If you sign up for the Android engineer.

David:

Yeah.

David:

And you should absolutely sign up for that goes out.

David:

Every week and includes a embed of Michelle's column, which he,

David:

again, like, Mishaal said is exclusive to that newsletter.

David:

If you want to sign up for that newsletter, go to blog.esper.io.

David:

And I am typing that in right now.

David:

Yes.

David:

To verify it's up at the top right.

David:

Of the page from the desktop says subscribe to our Android newsletter.

David:

It's called the Android edge.

David:

And we'd appreciate it.

David:

If you all did that, we host these every week about Android because Esper is a

David:

company that cares deeply about Android.

David:

We built an operating system based on AOSP.

David:

And so we are immensely interested in what goes on under the hood of

David:

Google's open source operating system.

David:

So thank you for joining us everyone this week and we'll be back next week.

David:

With the holiday over in me, not at CES and apparently, almost nobody else either.

David:

Anyway.

David:

So we'll catch you next time and thanks for listening everybody.

Chapters

Video

More from YouTube