So just for some context, as you may know, Google released Android 12 in October. They released the source code first on October 4th, and then the stable update per pixel phone or 19th. So we're right off the release of one major Android operating system update. And we're not expecting another major update until early 2022. When Google were release Android 12. And it's kind of arguable whether or not that's actually going to be a major update because for most devices, it's not going to be, it's targeted more at foldables and large screen devices like tablets, but the update that everyone who owns a smartphone, an Android smartphone will look forward to is Android 13 in late 20, 22. Most likely around September, October, if Google follows. They're pattern. I don't think, you know, we delayed like Andrew 12 hours by a month because I, I don't foresee them making any major UI overhauls like they did with 12, for Android 13. We're still many, many months away from enter 13 regardless, but despite that there have been a series of leaks and ongoing AOSP code changes that reveal some interesting information about the next Android update. Except for release late next year.

Yeah. And I think that we can kind of, you know, go from there. I think that we've got most people that are going to show up from our side, at least. Where do you think we should start? Mishaal? What are some of the the big items that 13 seems to be focusing on.

So one of the most significant changes that users should look forward to is the new app languages. And that feature is code name Penn lingual, because the idea is that currently in Android you can set one system language and the languages and input settings, and that language is what's applied system-wide across settings interface across the quick settings panel, and most applications will address. That language the language that you set in settings, some applications do provide their own in-app language settings, but it's not very common. And the downside of that is say your a, you know, you speak multiple languages or your native tongues in English, but some applications don't have very good translations to your local tongue right now. And Andrew. You basically have to deal with a really bad translation for that app. While you set your system language to say your native tongue maybe might be like Italian or something. But an Android 13, what Google is doing is they're adding any new app language feature that will let you set the language on a per app basis. The application itself still needs to support that language. It needs to have the strings that are translated to that language, but this will make it so you don't have to choose one language for the majority of apps. You can pick your preferred language for each application that you want to.

Now I know that there's some things the Google's been doing on the developer side for Android apps around languages in terms of split it or excuse me app bundles. So is there any impact here? The developers should be aware of because I know that developers, for example, can specify like, Hey, you know, like if my users. Uses us English only download us English asset pack. Versus, you know, whereas before, you know, a developer might put all of their like international language assets and the version of an app because they needed all of it. It became bundles. Let them split that up now with pan lingual. Will we see, you know, Google leveraging that ability to dynamically generate, you know, APKs with mulch files, like, is that going to be part of.

That's an interesting thought. Right now, depending on the language that you have and depending on whether or not the app support that bundles, whenever you go to download an app from the play store, it does download the base APK, the. The N a series of splits based on your architecture and your screen layout and your language. But this app language feature is something that you said after you've installed the app. So what may end up happening is that after you install the app, and then you change the language for that, The play store will recognize that the configuration for that app has changed and will inmate download the additional split for that language? We don't know. We don't have specific details on how this works because we don't have, you know, the source code for Android 13 or the documentation for this feature. But that's how I think it might address.

Yeah. And multi language support is something that Google has is, you know, it's not something we think of as much in America, obviously, but it's an extremely important feature of the platform given its global reach. And I bet this has been high on the list for people as a requested feature for a long time.

Oh yeah. It's definitely something that I've seen many requests for. And community developers have come up with like, Android modifications that enable this kind of functionality, but the big problem with previous solutions is that changing the language on your device is a very heavy process. It causes applications to restart it. It's, it's pretty slow in itself. If you just go to your phone and try to change the language, you'll notice it hangs for like 2, 3, 5 seconds, maybe when it's changing the language. And it's just not a very. Experience right now, if you were to try to take what's happening right now and apply that on a per rep basis, every time you load an app that has a different language, that it would just hang for like five seconds and that's not good. So we don't know exactly how it'll work on Android 13 and I suspect it probably won't be a laggy experience because that would just be awful. A solution that one of listeners on this call right now, Karen mentioned is that the configuration change might be applied only to the app sandbox, so that other applications won't be affected

yeah. And I think that's probably, that's a really good point, you know, switching system languages, like the heaviness of that process, Google probably just wants to avoid users ever having to touch that setting to begin with aside from initials.

Oh, yeah, you'll, you'll set the system language to be your, whatever, your preferred languages. And then if there's a particular language that you find more comfortable in with a particular app, then you'll set that and it will be much more user-friendly that way. And I'm surprised it's taken Android this long to add this feature, but you know, better, late than never.

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

So this one the next feature, we are less sure about. The original report on XDA developers is not 100% certain that this feature will be added, but if it is added in the way it's described, it would be a monumental change to the way Acacia work on it. So right now, notifications can be posted by after they're installed and they do not require any permissions from the user. The moment you install an application, it has the ability to post notification. And if you've seen advertisements posted on your device, you know, that they can get pretty annoying because applications will see the notifications panel as a way to just promote themselves or promote their services. It's a common way for apps to try to get these to reengage with their application if they haven't opened it in a while. But in the end, it's just not a very user-friendly experience because most users are not going to go into settings and then revoke the ability of an application to post notifications after this. So what might be changing Andrew 13 is that Google is adding a new runtime permission called post notifications and what a runtime notification or what our one-time permission is, is a permission that can only be granted by the user after the application has been installed. And the user has to granted by explicitly tapping allow on the dialogue that appears like in the middle of the screen. So there's no. Trick the user into automatically opting in to notifications. They have to explicitly grant the app permission to do that. And by doing so that will probably significantly cut down on how many apps can abuse notifications for advertisements or spam, et cetera.

This would be a huge change for developers and for users alike. And I think we've seen. There's a, there's an interesting dynamic, the advertisements on Android because it's an advertising company and they're more accepting. I think, of that than apple historically has been. And so on iOS notifications, as far as I know, have always been often. They definitely have been as long as I've been using it. So I think that that is always been kind of a philosophical disagreement that may be Google had with apple. But I have to say that like, This seems like maybe a thing where, you know, in China, obviously we see manufacturers of Android phones doing all kinds of crazy things to notifications because a, they don't run GMs and they don't have to worry about compatibility so much. And B because the app spam situation in China, because they do not have. A truly like one size fits all app store. That's a coalition of app stores and they're all responsible for gatekeeping their own content. You can end up with a lot of bad content and also, you know, piracy and other things exist everywhere. So you have to look out for. And I think that we were all confused for so long. Like why would you want such aggressive notification management on Android? Why would you want to lock down applications so hard? And I have to say, I have slowly turned the other direction where I used to be so against opt-in notifications. I am now. I think I am pro opt-in notification because more and more apps that I use I've started abusing this. And even on iOS, it's still a problem, you know, but one of the, the things that developers do or companies, I should say, because I don't think individual, this is a super cool thing to do these reengagement tactics that they use in their applications to the notification trays, basically like. They start to obfuscate like the channels that are going to send you kind of promotion notifications. They make it more difficult. They buried in the settings with Android notification channels. You do have good control over that, provided the app, respects those channels and defines them properly. But on iOS, you know, I, I have apps where. I can't get rid of notification permissions because I need to get notifications from that app. But I also know it's still going to advertise to me. So this is a problem on all platforms. And it's interesting to see that Google is moving that direction because that is, that is a huge switch,

right? Traditionally Google is kind of wary about making everything permission, gated, because if you make everything opt in, then users will be much more likely. By default grant permission to everything, because if you make it annoying for an application to actually do what you installed it to do, then you're not going to be giving much thought to these permission prompts. So Google wants to add permissions for sensitive features such as access to the camera or location, but they don't want to overdo it and make people just click allow, allow, allow. So. It is interesting to see that Google is finally, or may finally be taking this approach to notifications because being able to post a notification is one of the core functionalities of an app. And it's one of the ways that an app, as you said, can, re-engage a user with the service app, if they haven't been using it for awhile, but it seems like it's gotten to a point where so many applications that have just abused that permission, that they've decided to relegate it to a runtime permission.

And I think that, you know, the that's also just kind of an effect, I think, of the way smartphones are used and what people use them for, you know, for example, gaming you know, I think the games, you know, if you've ever played a mobile game, you know, that most games are shameless abusers of notifications. Their developers are, let's say a little more cutthroat about re-engagement strategies, then I think most app developers. And so I think that, you know, probably. As Android gaming has become more popular, which it has. You probably do see more and more user complaints basically saying this, you know, like this game is spamming me or this app is spamming me and probably Google does get pressure from some developers to be like, Hey, listen, you know, like I'm getting like, Unfairly review bombed you know, for this behave, don't understand or that like, you know, either a user doesn't understand that my app is responsible for sending these notifications or they don't, you know, understand the way to like, like disengage from them or do turn them off. So I think that Google does have to consider both directions, but at the end of the day, Like when I look at the experience on Google Chrome, like you have to opt in to notifications on a web browser. And to me it would be insanity if you didn't have to opt in. And so that's, that's, what's funny to me about this is it's very, like, it's very personal and it's very context dependent where you want notifications. And I think that Google moving to an opt-in system is, you know, just honestly it's respecting that more. And I think I'm definitely forward at this point. Like I've convinced my. And I, we did not start there. Like probably if you asked me five years ago, it would have been this isn't terrible. I would have said this is a terrible idea,

greed. And the next major change that I'm sure many will think is a terrible idea, especially if you're a developer, but it's. From a user perspective, it's much appreciated is Google's ongoing war on background services, and I'm sure many developers absolutely hate the amount of restrictions on applications, but from a user's perspective, it is nice to know that, you know, something is being done to curb applications that abuse how much access they're allowed in the background. In terms of permissions in terms of services, they can run because, you know, you want your phone to last all day. You don't want a phone that day. You want something that you can unplug in the morning and last you throughout the Workday and maybe a second day without even having to recharge it overnight. So the feature that Google is supposedly working on is called terr T a R E, which stands for the Android resource. So basically right now over the years, Google has been addressing what applications can do in the background by changing how they queue tasks. So in the early days of Android and application could start a what's called a foreground service and they could basically run tasks as they pleased whenever they wanted. But over the years, Google started to cut down on. Foreground services and the ability for apps to start them. And right now, if an application wants to start a foreground service they need to have a persistent notification, which is, which makes it very obvious that an application is running in the background. And that basically shames a lot of apps away from that. Like right now, if I pull down my notification panel on. I see a persistent notification for you, because I always want that app to be running because I want it to be able to respond to events in real time, but very few applications need to do that. And so what Google has come up with our API is like alarm job scheduler and work manager. Some of these work on AOSP, some of these require a Google play services to work, but basically the Google play services or the Android system itself. Except jobs from applications and they will, it will decide how to queue them and it will run these jobs based on factors. Like whenever the device is plugged in, whenever it has sufficient battery life, et cetera. That's how things work right now and enter 13, it seems like Google will be enhancing this concept to basically adjust. How many jobs an application can queue. Cause right now there's a maximum of 50, that can be cute through these APIs. And it seems that the system right now is not very intelligent. It just lets applications, queue jobs. And then the API APIs you know, the Google play services decide when to run them based on like your charge rate, your charge level, et cetera. But what the Android research economy will do is it will stop. Quote-unquote credits to apps to spend. And the total number of credits that the Android recess economy will assign. What it's calling the balance will depend on things like the current battery level and how many credits are assigned to an app will depend on the type of task that the app wants to queue. Is what my understanding is of tear. So basically if an application wants to queue a task, it won't be treated the same. As another application that wants to queue another task the Android, which is under me, will determine how many tasks can be queued based on the current battery level. And it will decide how many tasks a app can queue based on how important that task is. So like some applications will be able to queue more or have their tasks executed earlier than others based on. The importance of those tasks. So it seems like the way that Android will be executing background tasks will be more intelligent and Android 13. And in effect that will improve the battery life of your.

So this is, this is another really human for me because you know, battery life is obviously like, you know, when I go between my iPhone and my pixel, like the battery life is very noticeably different. And the, yet I don't want to turn this into the phone right show, but like my pixel six, like notifications are incredibly delayed. You know, like that behavior is not actually. Like performing in the way I would like, and I do wonder you know, on the Android team's end of things, like this sounds very complex, Michelle, what you're describing, like a system of like credits, obviously developers, if they're not like actually exposed and having to think about this very actively. But the systems handling most of that that's, you know, makes it a little different, but it feels like. This is the same story we get from Google every year about battery life, which is we are going to use heterogeneous processing to do this more efficiently. We are going to make sure apps respect, like, you know, when they can schedule jobs and we're going to make this all more efficient and we're going to use automate herb. We're going to use AI or ML to like learn. And I have yet to see a lot of evidence of that actually working. Would you agree with that assessment or am I just like totally off base here?

I think the reason why we haven't seen like McKinley improve battery life over the years, it's more to do with the hardware of the devices rather than the software. I think if we were to run the same, like a current software release on really old hardware, we'd get amazing battery life. It's just that phones nowadays have just crazy high resolution displays a one 20 Hertz variable refresh. Super bright hole, led panels, all this, all these different sensors, like the cameras we have, multi-camera arrays all processing at the same time, it's just, there's just so much on the internals that would drain band even with crown tasks, you know, being a lot more restricted and that lead to better battery life. That's, that's not enough to keep up with the significant advancements in our. So, do we know if this is going to be like exclusively based on battery life or is it going to take other hardware like Ram into consideration to we don't know what the factors are? What, what terrible use to determine how to assign credits or what the total balance should be.

And I mean, we don't want to get into necessarily what Google will or won't, this is still not a released thing. But I guess, you know, what is, where do we see this having the biggest impact, I guess, what kind of applications do we feel would have like an outsize of. Basically like what applications are going to look at this and say, oh no, this is really bad. Or conversely, which ones are going to say, oh, this is really good. Because I'm sure that there are apps out there that probably blurry on the line between abusive or just eat G send a lot of notifications and you know, potential issues they could run into here with these changes.

Yeah. That's a good question. And honestly, I'm not entirely sure on about which applications would be the most effective and which applications would not be. From my understanding, the alarm manager API is used to schedule tasks that need to be executed at a specific time. While the job scheduler slash work manager, API APIs are used to basically defer a task to an undefined point in time because it doesn't need to be executed immediately or at a specific time. There are just so many different kinds of apps on the market that use these APIs. So I can't really tell you like with acted in which won't be. I know there'll be certain kinds of applications that will be more effective than others, and there's, there might be a lot of complaints about the way this is implemented, because I, I'm not sure if it would be immediately obvious to a developer, whether or not their app is less deprioritize over. We'll just have to see what kinds of document, what kinds of callbacks Google will provide to apps.

Yeah, another facet of this is the effect basically on OEMs because you know, Michelle was, you know, like when Google updates, CTS, and there are new battery saving features, CTS changes pretty significantly usually. Because Google doesn't want manufacturers changing these behaviors, at least not. Huge ways. You know, I don't know the nuances of like a lot of the power saving rules and CTS right now. Or excuse me,

CDD.

CTS is the compatibility test suite CDD is the document. But anyway, like ed is quite nitty gritty about like things you can and can't do with power saving features. Do you think it's likely that Google will, you know, have to enforce this on an OEM level?

I have a good feeling. This feature will be. Mandatory for Android 13 devices, but I don't know if Google will mandate the exact values or the parameters that they're setting up for care. I suspect that OEMs will be able to tweak the parameters that are, that are listed in those screenshots posted by AXA developers. There, there will probably be a default and Google play services would probably be able to modify those values. I think OEMs would probably have a level of control over it. Yeah. Because

they do currently with the adaptive battery settings. There are some values they can change. And I think that I don't want to point fingers here. We've heard of manufacturers adjusting these things, such that break the feature per se, but it makes it a lot less effective. I think that we've seen some phone companies that like, you know, crank those things all the way off so that you get all of your notifications instant. But battery life is very negatively impacted. And then we see it in the other direction. For some OEMs crank up the asynchronous like notifications so far that you can go like a half hour and not get the notification on your phone. So controlling the consistency of that experience is not like a. A concrete thing for Google, you know, they've created guardrails, but you know, we don't even know until the feature is announced. And then the phones that use the feature come out and then how would it perform on those phones? We don't even know how effective it is necessarily. So that's what makes it hard, but stuff like battery life to hardware, like you said, is a great point. You know, the phones are simply doing more work and we have to consider that. But on the other side of things, you know, with the software, you know, that's, that's also something that's changing, you know, year over year. So with with stuff with power, like, you know, it's, it's really hard to say because I think that manufacturers are going to have really strong opinions about how to manage their devices power, because it is the bears, they own it. And they may also have a different impression of like what their users want in the experience they expect. Samsung may have a very different set of like assumptions they're making in terms of how users want to receive their notifications and how critical that is versus say one plus and Google makes some accommodations there for them to, you know, tweak certain settings accordingly. But the problem is that for developers, I assume in general, that's very open.

I agree. And there are a few more major changes that I'd like to mention. The next one is possible full support for Bluetooth low-energy audio. So if you're unfamiliar the Bluetooth SIG the, basically the organization that defines the Bluetooth standard, they announced the low energy audio. Codec and the standard. And basically the promises that it makes is that it will enable high quality audio streaming at a very low power without massively increasing the data rate. So basically it's just a significant improvement across the board for audio playback and audio streaming over Bluetooth. And right now, although there are multiple Bluetooth chips on the market on devices that are shipping right now that support Ellie audio, Android itself does not support the new standard with a new codec, but that might change with Android 13 because Google has been working on an open source L C3 in coder L C3 is the codec that's used for both Bluetooth Ellie audio, and that's been submitted to. And they're also working on the setting settings for the new codec within developer options within, within the framework. So my guess is that Andrew 13 will probably be the first release where Android itself will support selecting Ellie audio as the ADP source codec. But we'll have to wait and see if. Device makers actually have audio products on the market that support Ellie audio, because you need both the audio sync and source. So we have the source, which is the smartphone, the device running Android 13 with the requisite Bluetooth chip, but you need to sync, which would be the earbud or headphone that supports Ellie audio. And I don't think there are any on the market right now, the support it.

And just for some context here, I'm reading up on this because. The reason we care about this this Bluetooth Le audio feature it's enabling things like basically, like you can have, you know, you're going to have two people listening to AirPods at the same time on an iPad. Well, Bluetooth is going to be able to do that now in theory which is great because everybody wants that. It's basically increasing the amount of bandwidth, not, not increasing the amount of bandwidth, but the amount of audio you can put over the. Yeah, so like it's much more efficient. So yeah, that's a great example, you know, of another feature that Google has to implement again on that OSTP level and how things move kind of slowly. Granted, this is pretty new. So that's, that's pretty fast movement by Google standards, but probably that still means consumer product impact. Won't be till early 20, 23 at the earliest.

And I'm the next change that I've, that I believe Google is working on based on comments made by Googlers is that there's worrying work done to decouple wifi scanning from location permissions. So for some context prior to Android 12, in order for an application to scan for nearby Bluetooth device, It would have to request the user to grant it location permission. And that led to a lot of confusion whenever Google wanted to roll out the COVID 19 contact tracing apps, because that would require scanning for new abrupt Bluetooth devices. But doing so would show a prompt, asking the user to grant their location permission. And so that led to a lot of users thinking these tracing apps are tracking my location. When all they're doing is just scanning for nearby Bluetooth devices. So what Google ended up doing and Android 12 is they added a new nearby device permission. So that apps wouldn't need to request for location access, just to scan for nearby police use devices. It seems like Andrew 13, we'll do something similar with wifi scanning. So in order for an app to scan for nearby wifi access points in 113, they may not need to ask for location permissions anymore. We haven't seen that brought up in any, in any of the images that are posted by x-ray developers, but a Googler has commented saying that that's one of their goals for Android 13. And the reason why right now, if you're wondering. Y Android requires location permission just to scan for nearby Bluetooth devices or wifi access points. Is that being able to get a list of nearby devices is actually something that can be used to infer your devices location. So that's the reason why they tied it to location permissions. It just ended up confusing users who thought that devices that just need to scan for those devices for legitimate purposes, maybe to connect to them or to find a better access point nearby. We're actually just tracking the location. So Google scrapped that idea and they're decoupling those two.

Yeah, and I think that's a semantic issue. I mean, for example, you could also say like, if you open Google maps, AR mode, like that's not a really good example because that's using location permission anyway. But if you were using an AR experience that could figure out where you were based on what the camera was looking at, is that a form of location? Well,

yes, it is.

But does that mean it needs to be tied to a location permission and things obviously gets super muddy there. And I think that's probably where they came down by discussion with the scanning behavior for wifi and Bluetooth that it's too nuanced to explain to users.

Okay. I think a really great example of where this confusion manifests is with nearby share basically Android's version of. I forgot the name of the iOS file sharing solution, but basically nearby share is the solution that lets you quickly share files with nearby a hundred devices. But right now if you were to use nearby share, you would have to grant the surface access to location and that might make you wonder why does a. Solution that just shares files with nearby devices need access to Michael location. And the answer is it actually, doesn't what it's doing. Is it scans for nearby Bluetooth devices? And then once it, once you, once a user picks a device to connect. It initiates a wifi direct connection to that device and that device, the other, the receiving device needs to scan for a local wifi access points and connect to that access point. So that's where the location permission comes in. And that's what the user is thinking that nearby shares actually tracking the location. And that's not the case. So by decoupling wifi scanning from location permissions nearby share in Android. We'll likely no longer ask for the user location. Ask for the near brown permission.

Interesting. I wonder if we should just start putting a giant sticker on every phone when you open it, it says your phone knows where you are. Do you accept it? Because at this point it's kind of true, no matter what anything else that we should we should hit on Michelle before we end this

week. There are a lot of other smaller changes that I'd love to talk about, but can't. You'll just have to wait and see, but there is one that there is public evidence of in AOSP and that I actually wrote a blog, wrote a blog post about two weeks ago. Now it's about how Google will use virtualization in. It's quite a complex topic, but I run down, I basically document the necessity of Google standardizing, the virtual machine framework and Android, and what they're doing to bring virtualization and how they're going to use it. I recommend giving that a read it's part of the Andrew dessert by column that I write, which is only accessible. If you sign up for the Android engineer.

Yeah. And you should absolutely sign up for that goes out. Every week and includes a embed of Michelle's column, which he, again, like, Mishaal said is exclusive to that newsletter. If you want to sign up for that newsletter, go to blog.esper.io. And I am typing that in right now. Yes. To verify it's up at the top right. Of the page from the desktop says subscribe to our Android newsletter. It's called the Android edge. And we'd appreciate it. If you all did that, we host these every week about Android because Esper is a company that cares deeply about Android. We built an operating system based on AOSP. And so we are immensely interested in what goes on under the hood of Google's open source operating system. So thank you for joining us everyone this week and we'll be back next week. With the holiday over in me, not at CES and apparently, almost nobody else either. Anyway. So we'll catch you next time and thanks for listening everybody.