Tag Archives: Project Treble

Treble Plus One Equals Four

Posted by Iliyan Malchev (Project Treble Architect), Amith Dsouza (Technical Account Manager) , and Veerendra Bhora (Strategic Partnerships Manager)

Illustration of phone with settings logo in the screen

Extending Android updates on Qualcomm’s Mobile Platforms

In the past few years, the latest Android OS has been adopted earlier by OEMs and deployed in larger numbers to our users. The growth in adoption has been driven by OEMs delivering faster OS updates, taking advantage of the architecture introduced by Project Treble.

At the time Android 11 launched there were 667M active users on Android 10, 82% of whom got their Android 10 build via an over the air (OTA) update. Despite the events throughout 2020, there is a continued momentum among our partners to either launch their devices on Android 11 or offer Android 11 OTAs on their devices earlier.

Line graph comparing Android Pie, Android 10, and Android 11

Our efforts till now have been focussed on making OS updates easier and faster to deploy. The other side of this coin is supporting updates for a longer period of time, and today we’d like to provide an overview of the changes we are making to help our partners achieve this.

Project Treble was an ambitious re-architecture of Android that created a split between the OS framework and device-specific low-level software (called the vendor implementation) through a well-defined, stable vendor interface. As a part of this split, the Android OS framework guarantees backward compatibility with the vendor implementation, which is checked through a standardized compliance test suite - VTS. With each Android release, Project Treble publishes Generic System Images (GSIs) that are built from AOSP sources, and are guaranteed to be backwards-compatible with the previous 3 versions of vendor implementations, in addition of course to the current release—for a total span of four years. Devices launching with the new Android release must have vendor implementations compatible with that GSI. This is the primary vehicle for reducing fragmentation within the OS framework. While we allow and encourage our partners to modify the framework itself, the modifications post-Treble must be done in a way that reduces upgrade costs from one version to the next.

Besides the reuse of a vendor implementation across OS updates, the Treble architecture also facilitates the re-use of the same OS framework code across different vendor implementations.

Chart comparing Original OS framework to Updated OS framework

Another important change introduced by Project Treble is that new vendor-impacting requirements for Android devices are never retroactive. They apply only to devices launching on that Android version and not to devices upgrading from an older version. The term vendor-impacting here refers to requirements for new HALs, or for the shipping of a newer Linux kernel, to the device's vendor implementation. A good example might be a new revision of the camera HAL to support multiple rear camera sensors. Since the Android framework guarantees compatibility with the older HALs, we enable older vendor implementations to be reused by OEMs for upgrades without the considerable cost of updating them with new requirements.

This principle, combined with the backwards-compatibility guarantee, gives device manufacturers (OEMs) the flexibility to support upgrades both faster (since they have to upgrade just the framework, which would cover all of their devices, including those with older versions of the vendor implementation), as well as at a lower cost (since they do not have to touch the older vendor implementations).

However, seen from a System-on-Chip manufacturers’ perspective, this design introduces additional complexity. For each SoC model, the SoC manufacturers now needed to create multiple combinations of vendor implementations to support OEMs who would use that chipset to launch new devices and deploy OS upgrades on previously launched devices.

The result is that three years beyond the launch of a chipset, the SoC vendor would have to support up to 6 combinations of OS framework software and vendor implementations. The engineering costs associated with this support limited the duration for which SoC vendors offered Android OS software support on a chipset. For every single chipset, the software support timeline would look like this:

Timeline of OS framework

Considering that SoC providers have dozens of SoC models at any point of time, the full picture looks closer to this:

More accurate support timeline

The crux of the problem was that, while device requirements were never retroactive, the requirements for SoCs were. For example on Android Pie, SoCs had to support two versions of the Camera HAL API on a chipset if it was used to support new device launches and upgrades.

From this perspective, the solution was simple: we had to extend the no-retroactivity principle to the SoCs as well as to devices. With this change, the SoC provider would be able to support Android with the same vendor implementations on their SoCs for device launches as well as upgrades.

During the past year, we have been working hard to implement this solution. Building on our deep collaboration with our colleagues at Qualcomm, today we’re announcing the results of this work. Going forward, all new Qualcomm mobile platforms that take advantage of the no-retroactivity principle for SoCs will support 4 Android OS versions and 4 years of security updates. All Qualcomm customers will be able to take advantage of this stability to further lower both the costs of upgrades as well as launches and can now support their devices for longer periods of time.

Going one step further, we’re also reusing the same OS framework software across multiple Qualcomm chipsets. This dramatically lowers the number of OS framework and vendor implementation combinations that Qualcomm has to support across their mobile platforms and results in lowered engineering, development, and deployment costs. The diagram below indicates how significant the simplification is. From a software-support perspective, it's an altogether different situation:

Framework timeline with simplification

This change is taking effect with all SoCs launching with Android 11 and later. By working closely with Qualcomm to offer an extended period of OS and security updates, we are looking forward to delivering the best of Android to our users faster, and with greater security for an extended period of time.

All About Updates: More Treble

Posted by Iliyan Malchev, Project Treble Architect

Android 10, our newest release, brings helpful tools for both developers and consumers like suggested actions in Smart Reply to help you multitask faster, Dark theme for battery saving, Focus mode that keeps you from digital distractions, and more. And with almost 50 changes related to privacy and security, Android 10 gives you greater protection, transparency, and control over your data than ever before. It is important to both users and developers that these new releases find their way to mobile devices as fast as possible. In this post, we’ll share an update on the progress we’ve made with Project Treble, an initiative to help manufacturers update devices to new versions of Android more quickly.

Wait and See

When we launched Project Treble with Android 8.0 Oreo, we asked ourselves if our investment would pay off. There were two factors to consider in measuring the effectiveness of the program:

  • Complexity: The new architecture was a major overhaul, meaning it could only be implemented for devices launching with Android 8.0 Oreo and not for devices upgrading from Android 7.0 Nougat and older versions.
  • Time: We had to wait until we released Android 9 Pie to measure the rate of upgrades from Oreo and compare this number to the previous releases.

The Partner Beta Program

One of the earliest indications that Project Treble was having a positive effect was our ability to run the Beta program for Android 9 Pie on many more devices from more manufacturers. In addition to Google Pixels, we had 7 device models from 7 OEMs supporting Android 9 Pie Beta.

With Android 10, this year, we increased the number of devices to 18 (again, in addition to Pixels), representing 12 OEMs. This represents a significant increase over the previous year and shows that Project Treble is having an impact.

Distribution Chart

Beta releases are great, but how did we fare on actual upgrades? To answer this question, we considered two points in time. The first point is right before we released Android 9. The second point is right before we released Android 10. By each of these points in time, the previous release had had a year to reach devices.

In late July, 2018, just before Android 9 Pie was launched in AOSP, Android 8.0 (Oreo) accounted for 8.9% of the ecosystem. By comparison, in late August 2019, just before we launched Android 10, Android 9 (Pie) accounted for 22.6% of the ecosystem. This makes it the largest fraction of the ecosystem, and shows that Project Treble has had a positive effect on updatability.

Graph of Android Oreo Adoption rate

The adoption of Android Pie has been much higher than that of Android Oreo and Oreo MR1 when measured relative to the launch date.

Continuous Improvements in Updatability

The progress shown above results from work we did in Android 8.0 Oreo. We have made serious improvements with Android 9 Pie as well. The most significant one was our behind-the-scenes collaboration with silicon manufacturers. This work had the effect of reducing the average time to upgrade by more than 3 months, and we expect to see upgrades from Android 9 to Android 10 noticeably sooner this year.

There is also the sheer amount of hardening work on the architecture. We completed the seal between the vendor and system components of Android, which ensures that new versions of the top part of the OS run on older versions provided by our partners. We formalized the interface to the Android Linux kernel, expanded the Treble test suite (VTS), and did so much more. As a result, upgrades from Android 9 to Android 10 are going much more smoothly, as evidenced by direct feedback from our OEM and silicon partners.

We are beginning to see the effects already. This year, we saw two OEMs issue software updates to Android 10 on the day we announced it: Xiaomi and Essential. On the same day, OnePlus started a public beta program, and just a few days later, they started updating devices. HMD Global’s Nokia 8.1 just started receiving the update this week. In addition to these partners, many manufacturers such as ASUS, LG, Motorola, OPPO, Realme, Samsung, Sharp, Sony, Transsion, and Vivo have committed to updating some of their devices to Android 10 by the end of the year. Plus, new devices are already hitting shelves with Android 10, such as the OnePlus 7T. We are very excited that Samsung announced an open beta for Android 10 on their devices and started the rollout on October 12th, compared to November 15th last year.

The ROM developer community benefits from improved updatability as well. Mere days after the Android 10 launch, external developers ported it to 15 devices that launched on Android 8 and 9. This work was made much easier thanks to Project Treble, and we are very excited about the potential for open-source development on the OS. We made this even easier by publishing Google-signed Generic System Images (GSIs) and GMS binaries on android.com, as well as posting detailed instructions for developers to try them on their own.

DSU and Project Mainline

In Android 10, we delivered Dynamic System Updates (DSU). For every device launching on Android 10 that supports DSU, developers are able to install Google-signed Generic System Images and boot into them without having to touch the factory ROMs on their devices. We showcased this work at Google I/O, switching painlessly between GSIs and Factory ROMs on Pixel devices.

We also implemented Project Mainline, which allows Google to update directly, via the Play Store, components of the OS that are critical to security and app compatibility. Project Mainline is to the core of the Android OS what Project Treble is to its foundation. It is a dramatic improvement in the velocity of updates of the OS components that fall under its umbrella.

Project Mainline also builds on the work we've done on a less obvious part of Android, called Google Mobile Services (GMS), which has been receiving updates in this way for years. GMS is the part of your Android device that makes it work seamlessly with all of Google's services. Yet another piece, called Webview, is at the core of your browser and every application that interacts with the web. This security- and correctness-critical component also gets updated via Play Store.

Looking Forward

The Android ecosystem is truly vast. There are hundreds of phone manufacturers, dozens of SoC (mobile CPU) models, and thousands of very different devices. Creating an updatability architecture that covers all of them is a complex task. Android is committed to updatability in all forms, whether it’s real-time updates to first- and third-party apps, developer libraries such as Jetpack, or regular security updates for Android devices.

It has been exciting to see the impact of our efforts on updatability. We have a lot more work to do, and we are tirelessly investing on improving updates. I am proud of the progress we all—Android, Google at large, and our many partners—have made so far. I am very optimistic about the future and look forward to sharing our work for the next release of Android.

Fresher OS with Projects Treble and Mainline

Posted by Anwar Ghuloum, Engineering Director and Maya Ben Ari, Product Manager, Android

With each new OS release, we are making efforts to deliver the latest OS improvements to more Android devices.

Thanks to Project Treble and our continuous collaboration with silicon manufacturers and OEM partners, we have improved the overall quality of the ecosystem and accelerated Android 9 Pie OS adoption by 2.5x compared to Android Oreo. Moreover, Android security updates continue to reach more users, with an 84% increase in devices receiving security updates in Q4, when compared to a year before.

This year, we have increased our overall beta program reach to 15 devices, in addition to Pixel, Pixel 2 and Pixel 3/3a running Android Q beta: Huawei Mate 20 Pro, LGE G8, Sony Xperia XZ3, OPPO Reno, Vivo X27, Vivo NEX S, Vivo NEX A, OnePlus 6T, Xiaomi Mi Mix 3 5G, Xiaomi Mi 9, Realme 3 Pro, Asus Zenfone 5z, Nokia 8.1, Tecno Spark 3 Pro, and Essential PH-1.

But our work hasn’t stopped there. We are continuing to invest in efforts to make Android updates available across the ecosystem.

Safer and more secure devices with Project Mainline

Project Mainline builds on our investment in Treble to simplify and expedite how we deliver updates to the Android ecosystem. Project Mainline enables us to update core OS components in a way that's similar to the way we update apps: through Google Play. With this approach we can deliver selected AOSP components faster, and for a longer period of time – without needing a full OTA update from your phone manufacturer. Mainline components are still open sourced. We are closely collaborating with our partners for code contribution and for testing, e.g., for the initial set of Mainline components our partners contributed many changes and collaborated with us to ensure they ran well on their devices.

Project Mainline updates via Google Play infrastructure components in the Android OS Framework. The Framework components updated are located above the Treble Interface and Hardware-specific implementation, and below the Apps layer.

As a result, we can accelerate the delivery of security fixes, privacy enhancements, and consistency improvements across the ecosystem.

Project Mainline has security, privacy and consistency benefits. Security: Accelerate pushes and remove OEM dependency for critical security bugs. Privacy: Better protection for user’s data; increased privacy standards. Consistency: Device stability and compatibility; developer consistency.

Security: With Project Mainline, we can deliver faster security fixes for critical security bugs. For example, by modularizing media components, which accounted for nearly 40% of recently patched vulnerabilities, and by allowing us to update Conscrypt, the Java Security Provider, Project Mainline will make your device safer.

Privacy: Privacy has been a major focus for us, and we are putting a lot of effort into better protecting users’ data and increasing privacy standards. With Project Mainline, we have the ability to make improvements to our permissions systems to safeguard user data.

Consistency: Project Mainline helps us quickly address issues affecting device stability, compatibility, and developer consistency. We are standardizing time-zone data across devices. Also, we are delivering a new OpenGL driver implementation, ANGLE, designed to help decrease device-specific issues encountered by game developers.

Our initial set of components supported on devices launching on Android Q:

  • Security: Media Codecs, Media Framework Components, DNS Resolver, Conscrypt
  • Privacy: Documents UI, Permission Controller, ExtServices
  • Consistency: Timezone data, ANGLE (developers opt-in), Module Metadata, Networking components, Captive Portal Login, Network Permission Configuration

How does this work?

Mainline components are delivered as either APK or APEX files. APEX is a new file format we developed, similar to APK but with the fundamental difference that APEX is loaded much earlier in the booting process. As a result, important security and performance improvements that previously needed to be part of full OS updates can be downloaded and installed as easily as an app update. To ensure updates are delivered safely, we also built new failsafe mechanisms and enhanced test processes. We are also closely collaborating with our partners to ensure devices are thoroughly tested.

APEX file format. At the top level, an APEX file is a zip file in which files are stored uncompressed. The four files in an APEX file are: apex_manifest.json, AndroidManifest.xml, Apex_payload.img, apex_pubkey

Project Mainline enables us to keep the OS on devices fresher, improve consistency, and bring the latest AOSP code to users faster. Users will get these critical fixes and enhancements without having to take a full operating system update. We look forward to extending the program with our OEM partners through our joint work on mainline AOSP.

An Update on Project Treble

Posted by Iliyan Malchev, Project Treble Architect

Last week at the 2018 Android Dev Summit, we demonstrated the benefits of Project Treble by showing the same Generic System Image (GSI) running on devices from different OEMs. We highlighted the availability of GSI for Android 9 Pie that app developers can use to develop and test their apps with Android 9 on any Treble-compliant device.

Launched with Android Oreo in 2017, Project Treble has enabled OEMs and silicon vendors to develop and deploy Android updates faster than what was previously possible. Since then, we've been working with device manufacturers to define Vendor Interfaces (VINTF) and draw a clear separation between vendor and framework code on Android devices.

Going forward, all devices launching with Android 9 Pie or later will be Treble-compliant and take full advantage of the Treble architecture to deliver faster upgrades. Thanks to Treble, we expect to see more devices from OEMs running Android 9 Pie at the end of 2018 as compared to the number of devices that were running Android Oreo at the end of 2017.

The GSI is built from the latest available AOSP source code, including the latest bug fixes contributed by OEMs. Device manufacturers already use GSI to validate the implementation of the vendor interface on their devices, and Android app developers can now harness the power of the GSI to test their apps across different devices. With GSI, you can test your apps on a pure AOSP version of the latest Android dessert, including the latest features and behavior changes, on any Treble-compliant device that's unlocked for flashing.

We're continuing to work on making GSI even more accessible and useful for app developers. For example, the GSI could enable early access to future Android platform builds that you can run on a Treble-compliant Android 9 device, so you could start app development and validation before the AOSP release.

If you are interested in trying GSI today, check out the documentation for full instructions on how to build GSI yourself and flash it to your Treble-compliant device.

Faster Adoption with Project Treble

Posted by Iliyan Malchev, Project Treble Architect

Android P Beta available at android.com/beta

As Android continues to evolve, each new release of the OS brings new features, new user experiences, and better security. It is important that these new releases find their way to mobile devices as fast as possible.

Yesterday, we announced that the following devices, in addition to Pixel and Pixel 2, now support Android P Beta: Sony Xperia XZ2, Xiaomi Mi Mix 2S, Nokia 7 Plus, Oppo R15 Pro, Vivo X21, OnePlus 6 and Essential PH‑1. Android P Beta provides an opportunity for developers and early adopters around the world to try the latest Android release, test their apps, and provide feedback.

In this post, we provide an update to Project Treble and the technology that allowed us to bring Android Beta to more phones this year.

Building the Foundation

Bringing the new Android release quickly to the hands of users takes a combined effort between Google, silicon manufacturers (SM), device manufacturers (OEMs), and carriers. This process is technically challenging and requires aligning the schedules between our industry partners.

To reduce the technical difficulties, we launched Project Treble as part of Android Oreo.

The Silicon Manufacturers

Next, to capitalize on the foundation we built, we collaborated closely with the silicon manufacturers, where the journey of making an Android device always begins.

Any device with the latest version of Android must be based on an SoC with the proper software support for it. This software, commonly referred to as the Board Support Package (BSP), contains not only the chip-specific vendor implementation, but also all of the Android Open Source Project (AOSP) and pieces of the framework that are missing from AOSP itself (e.g., carrier-specific telephony functionality).

These BSPs are the starting point for all device launches. OEMs adapt the vendor implementation to their hardware and add their own custom framework components.

While silicon manufacturers always want the latest version of Android in their BSPs, the costs have been prohibitive. By making it possible for newer AOSP frameworks to run on older, already-released vendor implementations, Project Treble dramatically reduces the need for continuous investment in older silicon to support each Android release. Silicon manufacturers have to do all this work just once, rather than every time there is a new release of Android.

Solving the Timing Problem

However, that first time still has to happen. Below is a chart, which illustrates the effort the various actors expend over time as they go through each release. You can think of it as code churn or bug count over time.

The chart shows how there is very little time in the year for Google, silicon manufacturers, and the OEMs to all this work. Any overlap between phases causes code churn and introduces significant schedule risk. For OEMs who target the holiday season, it is often safer to launch on an older BSP with a year-old or even older Android version. This dynamic has been at the heart of the slow uptake of the latest Android release, even on flagship devices.

To solve this, we've worked closely with Qualcomm, MediaTek and Samsung SLSI to co-develop their BSPs, starting with Android P. Their BSPs are now ready for Android P on a much-accelerated schedule, reducing the overall effort significantly. These silicon manufacturers are now able to provide a stable and high-quality release much earlier than before, allowing OEMs to bring the latest innovations of Android to their customers across the globe.

This is an important step in accelerating the adoption of Android releases that bring numerous benefits to our partners, users, and Android developers. We look forward to seeing many more partners launch or upgrade devices to Android P.

Android O APIs are final, get your apps ready!

Posted by Dave Burke, VP of Engineering

Three weeks ago at Google I/O, we announced the second developer preview of Android O along with key themes, Fluid Experiences and Vitals, and highlighted our work towards a modular base with Project Treble. It was also an important milestone for us with the release of the first beta-quality candidate. We talked a lot about what's new in Android during the keynote and breakout sessions—if you missed the livestream, be sure to check out the full archive of talks here.

Today we're rolling out Developer Preview 3 with the final Android O APIs, the latest system images, and an update to Android Studio to help you get ready for the consumer release later in the summer. Watch for one more preview update coming in July that will bring you the near-final system images.

If you've already enrolled your device in the Android Beta Program, you'll receive an update to Developer Preview 3 shortly.

Make your app compatible with Android O

With the consumer launch approaching in the coming months, a critical first step is making your current app compatible with Android O. This will give your users a seamless transition to the new platform as it arrives on their devices.

If you haven't tested your app for compatibility yet, getting started is straightforward -- just enroll a supported device in Android Beta and get the latest update over-the-air, then install your current app from Google Play and test. The app should run and look great, and it should handle the Android O behavior changes properly -- in particular pay attention to background limits and changes in networking, security, and identifiers.

After you've made any necessary updates, we recommend publishing the compatible version of your app to Google Play right away -- without changing the app's platform targeting.

Enhance your app with Android O features and APIs

Extending your apps with Android O features can help you drive more engagement, offer new interactions, give users more control and security, and even improve your app's performance.

Notification channels and dots give you more ways to surface new content to users and bring them back into your app. Picture-in-picture keeps your app onscreen while users are multitasking, and autofill makes it simple for them to enter forms data and helps keep their data secure. Also check out adaptive icons, XML font resources, downloadable fonts and emoji, autosizing TextView, AAudio API, and many others. You'll also want plan your support for background execution limits and other important changes in vital system behavior for O apps.

Visit the O Developer Preview site to learn about all of the new features and APIs and how to build them into your apps.

Picture-in-Picture mode lets you keep users engaged while they are multitasking (left). Notification dots keep users active in your app and let them jump directly the app’s core functions (right).

Get started with Developer Preview 3

Today's preview update includes the latest version of the Android O platform with the final API level 26 and hundreds of bugfixes and optimizations. You can download the final API 26 SDK from the SDK Manager in Android Studio, and Android Support Library 26.0.0 beta 2 from Google's Maven repository.

Together, these give you everything you need to develop and test your apps with the official Android O APIs. Once you've installed the final SDK, you can update your project's compileSdkVersion to API 26 to compile against the official Android O APIs. We also recommend updating your app's targetSdkVersion to API 26 to opt-in and test your app with Android O specific behavior changes. See the migration guide for details on how to set up your environment to build with Android O.

APIs have changed since the second developer preview, so if you have existing code using Android O preview APIs, take a look at the diff report to see where your code might be affected.

If you're developing for Android O, we recommend updating to the latest version of Android Studio 3.0, now available in the canary channel. Aside from great new features like improved app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 includes build support for Instant Apps, an Adaptive Icon Wizard, and support for XML Fonts, and Downloadable Fonts.

Android Studio 3.0 includes tools for developing with Android O features lets you preview XML font resources in your app.

If you don't plan to use those features, you now have the option of developing for Android O using Android Studio 2.3.3 from the stable channel. Note that the tools for working with adaptive icons and downloadable fonts, and XML fonts are not available in Android Studio 2.3.3.

Publish your apps to alpha, beta or production channels in Google Play

Now that the APIs are final, you can publish APK updates compiling with, and optionally targeting, API 26 to your alpha, beta, or even production channels in Google Play. Publishing your O-targeted app during the preview lets you test compatibility on existing devices and push updates to devices running API 26 -- such as users who are enrolled in the Android Beta program.

To make sure that your updated app runs well on Android O as well as older versions, a common strategy is to use Google Play's beta testing feature to get early feedback from a small group of users -- including developer preview users — and then do a staged rollout as you release the updated app to all users.

How to get the preview update

Through the Android Beta program, developers and early adopters worldwide will soon be getting Developer Preview 3 on their devices. If you aren't yet enrolled, just visit android.com/beta and opt-in your eligible Android phone or tablet. As always, you can also download and flash this update manually. The O Developer Preview is available for Pixel, Pixel XL, Pixel C, Nexus 5X, Nexus 6P, and Nexus Player.

Thanks so much for all of your feedback so far. Please continue to share feedback or requests as we work towards the consumer release later this summer. We're looking forward to seeing your apps on Android O!

Google I/O 2017: Empowering developers to build the best experiences across platforms

By Jason Titus, Vice President, Developer Product Group
It's great to be in our backyard again for Google I/O to connect with developers around the world. The 7,200 attendees at Shoreline Amphitheatre, millions of viewers on the livestream, and thousand of developers at local I/O Extended events across 80+ countries heard about our efforts to make the lives of developers easier -- allowing them to focus on the problems they're trying to solve by minimizing the pain points of building a product.
Earlier this morning, our CEO Sundar Pichai talked about our various billion-user platforms. Whether it's Android or Chrome or the mobile Web, our success would not have been possible without the developer community. And during our Developer Keynote, we covered our heavy investments in tools and services for developers who build on our platforms every day.
We have a lot to cover over the next three days. Let's take a closer look at the major developer news at I/O so far:

Platforms that connect developers to billions of users around the world

  • Android O Developer Preview 2 — Get a look at the next release of Android O focused on fluid experiences that make Android even more useful, and our efforts to optimize battery life, startup time, graphic rendering time, and stability. Early adopters can opt in to the Android O Beta Program at android.com/beta and run Android O now.
  • Project Treble — Last week, we also introduced a new Android framework designed to help reduce the time and effort it takes device makers to upgrade a phone to a new version of Android, starting with Android O.
  • Android Go — We're optimizing Android to run smoothly on entry-level devices, starting with the O release. We're also designing Google apps to use less memory, storage space, and mobile data, including apps such as YouTube Go, Chrome, and Gboard.
  • Kotlin — Android is officially supporting the Kotlin programming language, in addition to the Java language and C++. Kotlin is a brilliantly designed, mature, production-ready language that we believe will make Android development faster and more fun.
  • Android Studio 3.0 Canary — Our new preview includes three major features to accelerate development flow: a new suite of app performance profiling tools to quickly diagnose performance issues, support for the Kotlin programming language, and increased Gradle build speeds for large sized app projects.
  • Mobile Web — AMP and Progressive Web Apps (PWAs) are re-defining modern mobile web development. AMP gets content in front of users fast and PWAs deliver app-focused experiences that are reliable, fast and engaging. We're seeing success stories from all around the world - travel company Wego has rolled out a successful AMP based PWA and Forbes has seen user engagement double since launching a PWA. If you're wondering how good your current web experience is, you can use Lighthouse - an automated tool for measuring web-page quality. Be sure to tune in this afternoon for the Mobile Web: State of the Union talk to hear more about building rich mobile web experiences.

Infrastructure and services to take mobile apps and the Web to the next level

  • Firebase — At last year's I/O, we expanded Firebase to a full mobile development platform with products to help you build your app and grow your business. Over a million developers now use Firebase, and we're doubling down on our efforts to simplify more every-day developer challenges. We're giving more insights to understand app performance through Firebase Performance Monitoring, introducing integration between Hosting and Cloud Functions, adding support for Phone Number Authentication, and continuing to improve Analytics in a number of ways. We've also started open sourcing our SDKs.
  • Mobile web developer certifications — At I/O'16 we launched the Associate Android Developer Certification. This year, we're adding two new certifications for web developers: the Mobile Sites Certification and the Mobile Web Specialist Certification.

Powerful tools to acquire and engage new users; grow successful businesses

  • Google Play Console — We announced several powerful, new features and reports in the Play Console to help developers improve their app's performance, manage releases with confidence, reach a global audience, and grow their business. The Play Console also has a new name, to reflect its broadened business uses, and a fresh look to make it easier to get things done.
  • Android Instant Apps — We opened Android Instant Apps, a new way to run Android apps without requiring installation, to all developers. Now anyone can build and publish an instant app. There are also more than 50 new experiences available for users to try out from a variety of brands, such as Jet, New York Times, Vimeo and Zillow.
  • Payments, Monetization & Ads — We introduced a Google Payment API that enables developers to give their customers the ability to pay in apps and online with credit or debit cards saved to their Google Account. New AdMob integration with Google Analytics for Firebase helps them monetize efficiently and updates to Universal Apps Campaigns will help them grow their user base.

New interfaces to push the limits of what's possible

  • Actions on Google for the Google Assistant — We brought Actions on Google to phones, introduced new features and functionality, improved our SDK and more. We also launched the Actions Console, a new developer console that helps developers work as a team, and collect data on app usage, performance and user discovery patterns. This new console is integrated with the Firebase and Google Cloud consoles.
  • VR and AR at Google — We'll have more to share on the latest Daydream platform features and developer tools during our "VR and AR at Google" session tomorrow (May 18) at 9:30 AM PT in the Amphitheatre and on the livestream.
It's important to us that developers are successful. In addition to building products that help solve developer challenges, we're on the ground in over 130 countries, growing and expanding the developer community through programs such as Women Techmakers & Google Developer Groups (GDGs). We're also investing in training programs like Google Developers Certification and courses through Udacity and other partners to help developers deepen their technical capability. We're also excited to announce two large multi-product developer events, Google Developer Days, which are planned for Europe (September 2017 in Krakow, Poland) and India (December 2017 in Bangalore, India). If you are interested to find out more, sign up for updates on g.co/gdd2017.
During Google I/O, attendees and viewers have an opportunity to dive deep into a number of these areas with 14 content tracks and 140+ breakout sessions -- covering Android to Assistant to VR -- and all livestreamed. We've also launched over 70 codelabs to get developers up and running with our latest APIs today.
Whether it's Android, Chrome, Play, VR/AR, the Cloud, and the Mobile Web — we're constantly investing in the platforms that connect developers to billions of users around the world. Thank you to the continued support and feedback from the developer community.

Here comes Treble: A modular base for Android

Posted by Iliyan Malchev, Project Treble team lead

On the Android team, we view each dessert release as an opportunity to make Android better for our users and our ecosystem partners. One thing we've consistently heard from our device-maker partners is that updating existing devices to a new version of Android is incredibly time consuming and costly.

With Android O, we've been working very closely with device makers and silicon manufacturers to take steps toward solving this problem, and we're excited to give you a sneak peek at Project Treble, the biggest change to the low-level system architecture of Android to date.

Life of an Android Release

First, it's helpful to understand the "life of an Android release". There are several steps a new Android release goes through before getting into the hands of users:

  1. The Android team publishes the open-source code for the latest release to the world.
  2. Silicon manufacturers, the companies that make the chips that power Android devices, modify the new release for their specific hardware.
  3. Silicon manufacturers pass the modified new release to device makers -- the companies that design and manufacture Android devices. Device makers modify the new release again as needed for their devices.
  4. Device makers work with carriers to test and certify the new release.
  5. Device makers and carriers make the new release available to users.

    With Project Treble, we're re-architecting Android to make it easier, faster and less costly for manufacturers to update devices to a new version of Android.

    The Vendor Interface

    Android was unveiled in 2007 as a free, open-source mobile operating system. From the beginning, we intended Android to be scaled across a variety of manufacturers. We knew that consistency of API was important for developers, so we created a compatibility program for the Developer API specified by the Compatibility Definition Document (CDD) and its associated Compatibility Test Suite (CTS), now comprising over a million tests.

    The result today is that app developers can write a single app that works across over a billion devices running on different hardware from different manufacturers.

    Project Treble aims to do what CTS did for apps, for the Android OS framework. The core concept is to separate the vendor implementation - the device-specific, lower-level software written in large part by the silicon manufacturers - from the Android OS Framework. This is achieved by the introduction of a new vendor interface between the Android OS framework and the vendor implementation. The new vendor interface is validated by a Vendor Test Suite (VTS), analogous to the CTS, to ensure forward compatibility of the vendor implementation.

    Benefits of Project Treble

    Today, with no formal vendor interface, a lot of code across Android needs to be updated when a device moves to a newer version of Android:

    With a stable vendor interface providing access to the hardware-specific parts of Android, device makers can choose to deliver a new Android release to consumers by just updating the Android OS framework without any additional work required from the silicon manufacturers:

    Project Treble will be coming to all new devices launched with Android O and beyond. In fact, the new Project Treble architecture is already running on the Developer Preview of O for Pixel phones.

    In addition to the architectural changes, we're working with our silicon and device partners to take their code changes, such as features for a carrier network in a specific country, and move them into the common Android Open Source Project (AOSP) codebase. For example, Sony and Qualcomm contributed dozens of features and hundreds of bugfixes to Android O so they no longer need to rework these patches with each new release of Android.

    We plan to publish the full documentation for Project Treble on source.android.com with the launch of O later this summer.