Home / Technology / The Android 11 interview: Googlers answer our burning questions

The Android 11 interview: Googlers answer our burning questions



The Android 11 interview: Googlers answer our burning questions

Aurich Lawson / Getty Images

We have built a certain tradition here at Ars. Every year at Google I / O, we have a chat to learn more about Android directly from the people who make it. Of course, almost every major event this year has been canceled due to the coronavirus pandemic, nothing is really normal and Google I / O has never happened.

We can still conduct interviews over the internet! While it happened later in the year as normal, we were still able to have our annual chat with some of the top Googlers at Android headquarters: Dave Burke, Vice President of Engineering at Android, and Iliyan Malchev, Principal Engineer at Android and lead of Project Treble.

We were prepared with questions about the more mysterious corners of Android 1

1, which actually led to a lot of interesting conversations about the future. You will learn about an upcoming rewrite of the Bluetooth stack, and there will be a lot of talk about modularity and ease of updating (as plans will hopefully one day allow you to update the Linux kernel and developer APIs as easily as you can download an app update).

This interview took place just days before Android 11 launched, which became final on September 8th. As usual, this has been marginally edited for the sake of clarity and I’ll be adding the required background in italics. Given the strange state of everything when we were all immersed in a Google Meet video chat, COVID was an obvious first issue.

Ars: How are you all dealing with COVID-19 in the Android developing country?

Dave Burke: Well. Like everyone else, when we moved from home it was a bit of a mess to say the least. We had to iron out a lot of developer productivity issues. Lots of people use powerful workstations to build the operating system with a USB attached phone and we wanted to find a way that they could still use their workstations but flash it to a phone that was tied to a laptop. So we did a lot of infrastructure work and so on to get everyone up and running. That actually worked out pretty well. I was pretty impressed.

Google Meet worked out great too. I remember thinking a few years ago, “Wow, Google is investing a lot in this videoconferencing material. Why not use something commercial?” But now I’m so glad that Google built its own. Many of us now use the meet rooms, so we have a lot of virtual, Slack-like channels, if you want to call it that. It was pretty good!

I mean, it was obviously difficult not to have things like corridor conversations, too. At the beginning we saw a drop in productivity of between 7 and 11 percent, I would say. Then it seemed to recover as people adjusted. We rolled back the schedule by about a month just because we need to take people in with that transition. The industry also took time to adapt, but yes it mostly works. Of course I think we would all love to go back to work.

Iliyan Malchev:: I think the biggest concern with COVID was just, “Will the ISP infrastructure be able to handle this huge surge in media consumption?” It seems to have held for the most part.

Burke: The other thing I’ve been working on is exposure notifications on Apple. So that was pretty intense. We’re building capacity to see if you’ve gotten close to someone who has tested positive for COVID-19. We did it quickly, so that was an exciting additional second job.

Oh yes, Android’s COVID exposure notifications will be broadcast to a smartphone near you. The APIs for this were shipped in Google Play Services and rolled out on virtually every two billion Google Play Android devices on the market. Full OS updates might depend on your device manufacturer, but Play Services updates will affect any phone that has the Play Store installed, so basically any Android phone outside of China.

Google will start to generate COVID apps itself so that states and other entities are easier to use.
Enlarge /. Google will start to generate COVID apps itself so that states and other entities are easier to use.

Google

The current problem with COVID tracking is that individual health organizations need to create apps that integrate with this API. In the US, this is usually your state government. States don’t really have skilled app developers on-call for something like this (is your local DMV website as disastrous as mine?). So far, only six states have COVID apps. It sounds like Google’s next step in fixing this is to build apps yourself. Hence, states only need to provide a configuration file to be operational.

Updates to the project lead

Project Mainline, also known as Google Play System Updates, is one of the biggest changes made to Android in a while. The function was first introduced in Android 10 and is an important step in the modularization of Android. Mainline has added a new “APEX” file type to package core system components for easy upgradability through the Play Store. Previously, the Play Store only shipped APK files which, since they were created for third-party apps, had all sorts of security and functional limitations that would not work for core system components. APEX files can only be from Google or your OEM, so these are much more powerful and can be started earlier on boot. For example, APEX files can update the app framework, which would never be possible with an app.

Mainline was also about getting OEMs on board, with Google taking over more of Android base code – code that was previously available to OEMs to customize. Google had to sit down with all of the OEMs (I imagine these meetings look like the Galactic Senate) and ask, “Do you really need to adjust how the DNS resolver works?” If all the answers come back “no” it becomes a mainline module and everyone agrees to send the same code. When customization issues arise, Google and OEMs work together to put code into a module that anyone can use.

That was Android 10. For Android 11, the last message we got on Mainline was Google’s first Developer Preview blog post from February, which featured “12 new modules” in Mainline. It didn’t provide much more detail than that.

Ars: Your blog post says there are “12 new Apex modules” in Android 11, but what exactly are they?

Burke: Yes there is a bunch. I have a list here: so statsd, our daemon for collecting statistics, and that makes sense because you want unified telemetry. Wi-Fi tethering is a new module. NNAPI – the API for neural networks – is yet another area that is changing rapidly as we learn more machine learning techniques. ADBD. Cell broadcast. There are some Wi-Fi modules. SDK expansion material. Oh, and also the media provider that supports the storage area, so we wanted this to be upgradeable.

I think there are now 21 modules in total and I think probably more important than the actual modules is the work that is put into the infrastructure to make them possible. We have a very advanced release management. We have short term, long term telemetry. We have AB capability. We have a filesystem snapshot in rollback. And the other part, of course, is just a cultural shift for the developers to learn how to write in a module that is constantly being updated. I’m pretty excited about the foundation that we’ve laid more than the specific modules because more is to come.

Ars: Since I’m talking about “more to come”, I wanted to ask about the “SDK expansion module” which sounds pretty important. Is that as interesting as I imagine it to be? Would you like to provide new API levels via the Play Store?

OK, time out, as I clarify this question: Android versions are identified to you and me by their version numbers, but internally Android identifies itself to apps with a number interchangeably called the “SDK level” or “API level”. All new functions, permissions and security restrictions in Android 11 are available to apps in “API Level 30”. In the past, the API levels have increased by +1 with each Android version (even with the smaller 0.1 releases, which is why we are at level 30).

The speculation with an SDK module is that Google would be able to deliver new SDK levels to developers, including new features, without having to bring out a full operating system update. This would be absolutely incredible for Android, as full OS updates are so poorly distributed and small in user base that developers are reluctant to support new APIs if no one can run them. API levels via Google Play would be like a rollout for Play Services, where a new feature can reach two billion devices practically overnight. This also sounds very difficult to believe, as a new developer API can hit any part of the operating system. How could you possibly update that through a single module?

Burke: I think the whole idea of ​​upgradable OS modules is a pretty profound change, so it’s all pretty interesting. But yes, in Android 11 – Android R, as we call it – we have the option of creating new system APIs and providing them in main modules. That is in R. In S. [Android S would be version 12], We’re going to plan to actually be able to expose new public APIs in mainline modules, so we’re really just expanding the breadth of what a module is and what is updateable.

Ars: That has to be more limited than a full OS update, right? How well can this work compared to an OTA? It sounds amazing, but also quite difficult.

Burke: Yeah, I think it’s early. You’re right. The challenge with updatable modules is that the module will be updated, but you cannot assume that everything around it will be updated. So you need to be careful and have stable internal APIs or boundaries between these interfaces.

So yeah, we’re still working. I think what you really want is for the API to just connect to another updatable module, otherwise it doesn’t make any sense. We’ll build the ability and then we’ll see what we’re going to use it for.


Source link