Ur Rick Son / Getty Images
We have established a little tradition here at Ars. Every year on Google I / O, we have a sit down talk to learn more about Android directly from the people who created Android. Of course, this year, almost every major event was canceled due to a coronavirus epidemic, nothing really normal, and Google I / O never happened.
We can still do interviews on the internet! So when it happened years later than usual, we were still able to have an annual chat with some of the most important Google goers at Android headquarters: Dave Burke, VP of Android. Engineering, and Ilyan Malchev, Principal Engineer of Android and Chief Project Trouble.
We pondered with questions about the more mysterious corners of Android 11, which really made a lot of interesting things about the future. You’ll learn about the rewriting of the Bluetooth stack, and a lot more about modularity and easy updating (such as plans that hopefully, someday, will allow you to download the app and update the Linux kernel and developer API as easily as possible. Update).
The interview took place a few days before the launch of Android 11, which was finalized on September 8. As always, this has only been slightly edited for clarity, and I will include whatever background is needed in Italics. Seeing the weird state of everything we all did in the Google Meet video chat, COVID was clearly the first topic.
Aras: How are you all dealing with COVID-19 in the land of Android development?
Dave Burke: Good. Like everyone else, when we started working from home, to say the least was a bit of a waste. We have a lot of developer productivity items that can be used. Many people use high-powered workstations to create a USB operating system, which has a tethered phone over USB, and we wanted to find a way that they could still use their workstations but flash a phone that tethers on a laptop. Is. So we did a bunch of infrastructure and what not to lift and run everyone. It worked really well. I was very impressed.
Google Meet also worked very well. I remember a few years ago saying, “Wow, Google invests a lot in this video conferencing content, why not use something commercial?” But now I’m glad Google has built its own. Many of us now use meat rooms, so if you want to say it, we have a lot of virtual, slack-like channels. It’s been so good!
I mean it’s also obviously tough because it’s not things like corridor conversations. We saw somewhere between 7 and 11 percent in productivity, I would say, initially. Then it seemed to recover as the people adapted. We set the schedule after about a month, because we need to include people with that transition. The industry also needed time to adapt, but yes, it is largely functional. Of course, I think we would all be quite happy to get back to work.
Ilyan Malchev: I think the biggest concern going into COVID was just, ‘Will the ISP be able to handle this huge spike in infrastructure media usage?’ Looks like it holds up for the most part.
Burke: The other thing I’m working on is the contact notifications with Apple Pal, so it’s been very intense. We are building capacity to find out if we are approximate with someone who tested positive for COVID-19. We run on it quickly, so it’s an amazing extra second job.
Ah, yes, Android’s COVID exposure notifications roll out to your nearest smartphone. The APIO for this has been sent to Google Play Services and basically rolled out on all the two billion Google Play Android devices there. Full OS updates may be based on your device manufacturer, but Play Services updates hit every store in which the Play Store is installed, so basically every Android phone is out of China.
The current problem with covid tracking is that individual health organizations need to create applications that are plugged into this API, and U.S. In, it’s usually your state government. The states don’t really have app developers capable of doing something like this (is your local DMV website a disaster like mine?) So far, only six states currently have COVID apps. It looks like Google’s next step is to try and fix it, to build those apps, so states just need to supply a configuration file to get up and running.
Project mainline updates
Project Mainline, aka “Google Play System Updates” is the biggest change to come to Android in a while. This feature was introduced in Android 10, and is a big step in the modulation of Android. Mainline added a new “Apex” file type, designed to package core system components for easy updateability through the Play Store. Previously, the Play Store only sent APK files, as they were created with third-party applications in mind, so they come with all sorts of security and functionality limitations that would not work for native system components. Apex files can only come from Google or your OEM, so this provides a lot more power and start-up in the boot process. Apex files can do things like update the application framework, which you can never do with an application.
Mainline was also about taking OEM on-board, with Android taking more of Android’s base-code, which was previously available for OEM to customize. Google had to sit down with all the OEMs (I imagine these meetings sound like a galactic senate) and ask, “Do you really need to customize the way the DNS resolver works?” When all the answers return “no”, it becomes a mainline module and agrees to send the same part of each code. While there are customization concerns, Google and OEM are working together on upstream code in a module that everyone can use.
It was Android 10. For Android 11, we got the last news about the mainline, it was Google’s first developer preview blog post since February, saying that the mainline has “12 new modules”. It does not provide more details than that.
Aras: Your blog post said that Android 11 had “12 new top modules”, but what exactly is that?
Burke: Yes, there is a bunch. I have a list here: So statistics, which is our daemon for collecting statistics, and it makes sense because you want the same telemetry. Wi-Fi tethering is a new module. N.A.P.I. – Neural Networks API Again, this is another place that is changing rapidly as we learn more techniques in machine learning. ADBD. Cell transmission. There are some Wi-Fi modules. SDK extension content. Oh, and also the media provider, which adds up to the stopped storage, so we wanted it to be updated.
I think there are now a total of 21 modules and I think more than what the actual modules are that went into the structure to make that task possible. We have very advanced publishing management. We have short-term, long-term telemetry. We have AB capacity. We have a file system snapshot in rollback. And the second part, of course, is just a cultural change for developers to learn how to write in a module that is updated all the time. I’m so excited about the foundation that we’ve laid out more than what the special modules are because there’s still a lot to come.
Aras: Speaking of “more to come”, I wanted to ask about that “SDK extension module”, which seems very important. As interesting as the one I’m imagining? Do you want to deliver new API levels through the Play Store?
Well, time expires when I explain this question: Android versions are known to you and me by their version numbers, but internally known as Android, “SDK level” or “API level” Identify yourself with numbered apps. Therefore, all new features, permissions and security restrictions in Android 11 include “API Level 30.” Available for applications in In the past, the API level always increased to +1 with each Android release (even for smaller 0.1 releases, which is why we are at the 30 level).
Speculation with the SDK module is that Google will be able to send entire new SDK layers to developers, including new features, without having to proceed with a full OS update. This would be quite unreliable for Android, as full OS updates have such poor distribution and small user bases that developers are reluctant to support the new API when no one can run them. The API level on Google Play will be the same as the Play Services rollout, where a new feature could hit virtually two billion devices. This also seems very difficult to believe, as the new developer API can hit any part of the OS. How can you update it with one module?
Burke: I think the whole idea of updateable OS modules is a very profound shift, so it’s all very interesting. But yes, we have the ability in Android 11 – Android R to create new system APIs and deploy them to the main line modules. It s. Is in r [Android S would be version 12], We plan to be able to deliver really new public APIs to the mainline modules, so we really just know what the module is and what can be updated.
Aras: It’s going to be more limited than a full OS update, right? How well can it work compared to OTA? It seems surprising but also very difficult.
Burke: Yes, I think it’s too early. You are right The challenge with modules that can be updated is that the module updates but you can’t assume that everything around it is updated. So, you have to be very careful and there should be a stable internal API or boundary between those interfaces.
So yes, we are still working. I think what you really want is just to connect to another updateable module, otherwise it doesn’t make much sense. We are building capacity and then we will see how we use it.
