Perhaps as a consequence of Android's flexibility, we often get asked by developers what does the Android team recommend when it comes to building apps? You’ve told us: you love our openness..but you’d also love us to marry it with an opinion about the right way to do things. And, to make sure the right way is also the easiest way. And so today, at the Android Dev Summit, the team wanted to answer that question for you.
We call our recommendation “modern Android development". Opinionated and powerful, for fast, easy development. Taking away everything that slows you down so you can focus on building incredible experiences. You can see it in the investments we’ve made like creating Android Studio and Jetpack. (Over 90% of our pro developers are using Android Studio today.) Kotlin and Compose are especially great recent examples. Kotlin is a modern, concise language -- something you asked us for and is now the recommended language for Android. Compose is a modern declarative UI toolkit built for the next 10 years. And this might sound a little strange, but we chose and designed these tools to be enjoyable to use: we think that’s important too. Both Kotlin and Compose also have a critically important property. They are designed to be compatible with your existing apps. This means you can phase in Kotlin code and Compose views on your timeline.
It all starts with a great modern language: Kotlin
Modern Android starts with fantastic language support.In fact, we recently passed a milestone where almost 60% of our top 1000 apps are using Kotlin. And we’re working with JetBrains to make it even better: faster kotlin compile speeds, incremental annotation processing with KAPT, better IDE typing latency, more lint checks, desugaring in D8 and R8, new optimizations in R8 that are aware of Kotlin-specific bytecode patterns. And we’re releasing full IDE support for Kotlin build scripts today. If you want to grow your skills, we are launching an Advanced Android course with Kotlin on Udacity. And, for those who are already experts, we’re also launching a new Android Developer Certification in Kotlin, available at a discount for the next three months. We’re working to make all of our supported first-class languages — Kotlin, the Java programming language, and C++ — better for you and your team, with Java8 library desugaring, NDK r21 with updated LLVM, GNU Make, Fortify enabled by default, and more.
Jetpack: Build high quality, powerful apps with less code
Jetpack is designed to solve real-world problems you face every day, and is used by over 84% of the top 10,000 Play Store apps. And we continue to make Jetpack even more helpful:
Compose: Android’s new UI toolkit to build beautiful, native apps, now in developer preview
Compose makes it easy to build beautiful, native apps. It provides a declarative way to build UIs which makes your code more intuitive and concise. Inspired by Kotlin, you can adopt Compose at your own pace thanks to seamless compatibility with the existing UI toolkit.
Today we are releasing the Jetpack Compose Developer Preview. All you need to do is download the latest Preview build of Android Studio. Compose is being developed completely in the open, in AOSP. The continuous feedback we receive has led to many API improvements and we want to thank you for providing feedback in our developer studies and the Kotlinlang Slack group. As we enter developer preview, we need even more feedback as we work towards bringing Jetpack Compose to beta next year and ready for use in production apps.
Android Studio 4.0 Canary
Today we also released the first canary of Android Studio 4.0 - built hand in hand with Compose for powerful, integrated tooling support. Android Studio 4.0 includes Compose Live Preview, Code Completion, and a full sample of a Compose app. You’ll also find the new Motion Editor, Java 8 Language library desugaring, full support for KTS files, Kotlin live templates, and more.
Android App Bundles and dynamic delivery testing improvements
In just eighteen months after launch, over 270K Android App Bundles are now in production covering 25% of all active installs. Based on your feedback, we’re making App Bundles and Dynamic Delivery much easier to test. Internal app sharing lets you share test builds of your app bundle as easily as you share APKs. You can now grant anyone in the team ability to upload artifacts. You don’t need to sign test versions with your production app signing key, you don’t need to use version codes, and you can upload debuggable artifacts. We’re also making it possible to get download links for old versions of your app from the Play Console, whether they’re app bundles or APKs. And starting today, we’re launching offline testing of dynamic delivery with the fake split install manager so can replicate splits being installed by the Play Store while testing locally.
A modern distribution platform, centered around user trust
User trust and safety has always been a top priority at Google Play, with human reviewers, constant improvements to play protect, and policy updates to evolve with the threats we see. As a result, apps that are installed from Google Play are an order of magnitude safer than from any other source. This year, we’ve been increasing all our detection capabilities for impersonators, repackaging, bad content and other forms of abuse, but we know there's more we can do, and the threats are constantly changing. With your help, we’ve reduced access to sensitive data and have made Play even safer for children and families. We restricted SMS/Call log permissions to only apps that need them as part of their core functionality, and as a result 98% fewer apps access this sensitive data. Thanks to your hard work, users are safer, and know they are safer when they download apps that request fewer permissions.
The Android Developer Challenge!
Over ten years ago, we announced the first Android Developer Challenge. Today, modern Android is shaping the next generation platform. So it seems kind of fitting to announce: the Android Developer Challenge is back! The first Developer Challenge we’re announcing is Helpful Innovation and Machine Learning. Take Live Captions: for the almost 500 million people who are deaf and hard of hearing, Live Captions bring content to life and is exactly the type of machine learning-powered innovation we expect to see more of someday, and with your help we can turn someday into today. You can read more about the challenge here.
So - that’s a quick tour of Modern Android and the road ahead across our developer experience! Whether you’re joining us for Android Dev Summit in person or on the livestream, we have nearly 60 sessions from over 100 speakers where we’ll go deep on everything you need to know about Android. Thank you!
Posted by The Android team
Developers like you have always played an important role in shaping the direction of Android, fueling the wave of Android innovation. It’s the reason that when we first launched the SDK for Android 10+ years ago, we simultaneously announced the Android Developer Challenge: a way to help reward model apps and show us what user problems you wanted to solve. As Android continues to push the boundaries into emerging areas like ML, 5G, foldables and more, we need your help to bring to life the consumer experiences that will define these new frontiers.
So we’re bringing back the Android Developer Challenge and asking you to help us unlock new experiences on Android, and help inspire other developers around these emerging technologies.
As we kick off this challenge, the first area we’ll be focusing on is On-Device Machine Learning. At Google, we’re big believers in how this new technology can open up a world of helpful innovation so you can get things done in ways you never thought possible. Take Live Captions: for the almost 500 million people who are deaf and hard of hearing, Live Captions bring content to life and is exactly the type of machine learning-powered innovation we expect to see more of someday, and with your help we can turn someday into today!
Bringing your idea to life in front of billions of eyes
Got an idea? Whether it’s still a concept or ready for users, tell us how you could use Google’s help, and how it supports the mission of using machine learning to help people get something done. Join the #AndroidDeveloperChallenge topic on GitHub, and share your idea as a repository under this topic. Don’t forget to come back here and officially submit your concept.
We’ll pick 10 concepts and provide expertise and guidance to those developers to help in their plans to bring their ideas to fruition. And once the app is ready, we’ll help showcase it in front of the billions of users on Google Play, through a collection and more. Here’s what those 10 developers will get:
Expertise and development support bootcamp: We’ll work with you to provide expertise and guidance to help in your plans to bring your app from concept to reality, including:
Exposure and street cred! Once your idea is ready for prime-time, we’ll help you get users, and celebrate you to the broader Android community, including:
Helpful innovation is an important investment area for us on the Android team, and On-Device Machine Learning has played a critical role in powering new features in the last several releases of Android. We’re just beginning to scratch the surface, and we can’t wait to see what you come up with!
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:
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.
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.
Posted by Dan Lavelle, Head of Learning Operations, Google Play
One year ago, we introduced the Academy for App Success , an e-learning platform to help apps and games businesses who want to grow on Android and Google Play. In that time we've seen tens of thousands of people register for free learning, complete over 50,000 courses, and provide an average course rating of 4.66 out of 5 stars. Thank you to everyone who has spent time learning about best practices, Play Console features, policies and other aspects that are critical to growing your business - we hope to see more of you in the future.
Since the debut of Play Academy, we've been working hard to expand our offering to cover the topics you want to learn about. In this time, we have:
We've also been listening to your feedback and have updated Play Academy with content to cover key areas that might interest you:
Google Play policy
Subscription model for games
Track installs, uninstalls, and upgrades
Our goal at Play Academy is to provide you with a free learning resource to optimize your use of Play Console features, learn best practices to apply to your app or game business, and stay on the right side of Google Play policy.
Over the coming year, we will continue to create and update content in these key areas, in addition to investing in new learning formats to complement our interactive e-learning content.
At Google Play, we're looking forward to another great year of learning with you.
It's easy to get started with Play Academy - simply head to g.co/playacademy, sign up for your free account, and choose from over 75 e-learning courses and assessments. While you're there, leave a rating and review on any courses you complete.
How useful did you find this blog post?
★ ★ ★ ★ ★
We’re less than 24 hours away from kicking off the 2019 Android Dev Summit, broadcasting live from the Google Events Center (MP7) in Sunnyvale, CA on October 23 & 24. We’ll be broadcasting the entire two days of the event live on YouTube, Twitter and on the Android Dev Summit website. Here’s what you need to know:
The summit kicks off on October 23 at 10 a.m. PDT with a keynote, where you'll hear from Dave Burke, VP Engineering for Android, Stephanie Cuthbertson, Director of Product Management and others on the present and future of Android development. From there, we'll dive into two days of deep technical content from the Android engineering team, on topics such as Android platform, Android Studio, Android Jetpack, Kotlin, Google Play, and more. The full agenda is here so you can plan your summit experience.
Tweet us your best questions using the hashtag #AskAndroid in the lead-up to the Android Dev Summit. We’ve gathered experts from Jetpack to Kotlin to Android 10, so we’ve got you covered. We’ll be answering your questions live between sessions on the livestream. Plus, we will share updates directly from the Google Events Center to our social channels, so be sure to follow along!
Posted by Madan Ankapura, Product Manager, Android
Google’s vision is to bring a safe and seamless connected experience to every car. Since 2017, we have announced collaborations with vehicle manufacturers like Volvo Car Group, General Motors and others to power infotainment systems with Android Automotive OS, Google’s open-source Android platform, and to enable integration of Google technology and services. Now with the reveal of Volvo’s XC40 Recharge and the previously announced Polestar 2, we are making progress on our vision with these brand new, customized infotainment systems that feature real-time updates to the Google Assistant, Google Maps and automotive apps created by Google, and the global developer community.
Volvo XC40 Recharge & its infotainment unit
With more manufacturers adding Android Automotive OS based infotainment systems to their vehicles, app developers have an opportunity to reach even more users with innovative, and drive optimized experiences.
Concept image from GM on Maps & Media integration
At Google I/O 2019, we published design guidelines for developing media apps for cars, added wizard support to Android Studio, updated emulator to have car specific controls and the Android Automotive OS emulator system image. These latest features helped Android developers start to design, as well as develop and test their existing media apps to run on Android Automotive OS (review developer documentation here).
Today, we’re announcing that developers can download an updated Android Automotive OS emulator system image that includes the Google Play Store. This means developers no longer have to wait to get their hands on a vehicle, but can design, develop, run apps right within the emulator, and can now test distribution via Play Console by requesting access.
In addition to the apps announced at Google I/O, more media app developers, including Amazon Music, Audioburst and YouTube Music, are adapting their apps for Android Automotive OS. The process of porting existing media apps that support Android Auto to this platform is simple and requires minimal development resources.
Audioburst, Amazon Music and YouTube Music running on the Android Automotive OS emulator
And if you want to learn more about creating apps for Android Automotive OS — join us at Android Dev Summit 2019. Come talk to us in our sandbox, tune in via livestream on YouTube, or post on the automotive-developers Google Group or Stack Overflow using android-automotive tags.
We hope to see you there!
Android NDK r21 is now in beta! It’s been a longer than usual development cycle (four months since NDK r20), so there’s quite a lot to discuss for this release.
We have the usual toolchain updates, improved defaults for better security and performance, and are making changes to our release process to better accommodate users that need stability without hindering those that want new features.
This release comes with new minimum system requirements. Following Android Studio and the SDK, 32-bit Windows is no longer supported. While this change will not affect most developers, this change does have an impact if you use 32-bit versions of Microsoft® Windows®. Linux users must have glibc 2.17 or newer.
One release a year will be our Long Term Support (LTS) release for users that want stability more than they need new features. The release will undergo a longer beta cycle before being released, and will receive bug fixes as backports until next year’s LTS release. Generally releasing in Q4, our first LTS release will be NDK r21.
The non-LTS releases each year, which we call the “rolling” release, will be similar to our current process. These will be approximately quarterly releases of our latest set of features, which will only be patched later for critical toolchain fixes. If you want the latest features from Clang and libc++, this is the release for you.
More detail, including the criteria we will use to determine what will be backported, what kinds of bugs will trigger a point release, and the bar we hold each release to can be found documented on our GitHub Wiki.
There are quite a lot of new things in this release, resolving bugs and helping you write better, safer code.
We’ve updated GNU Make to version 4.2, which enables --output-sync to avoid interleaving output with error messages. This is enabled by default with ndk-build. This also includes a number of bug fixes, including fixing the pesky CreateProcess errors on Windows.
--output-sync
CreateProcess errors on Windows
GDB has been updated to version 8.3, which includes fixes for debugging modern Intel CPUs.
As always, we’ve updated LLVM and all of its components (Clang, lld, libc++, etc) which includes many improvements.
The toolchain has been updated to r365631 (the master branch as of 10 July 2019). This includes fixes for quite a few bugs in the previous release, perhaps most importantly LLD no longer hangs when using multithreaded linking on Windows. OpenMP is now available as a dynamic library (and this is the new default behavior, so link with -static-openmp if you want to stick with the static runtime).
-static-openmp
A handful of driver improvements have been made to reduce the amount of compiler configuration required by each build system as well. Build system owners should check the updated Build System Maintainers guide.
libc++ has been updated to r369764.
Fortify is now enabled by default when using ndk-build or the CMake toolchain file (this includes ExternalNativeBuild users). Fortify enables additional checks in the standard library that can help catch bugs sooner and mitigate security issues. For example, without fortify the following code compiles fine:
ExternalNativeBuild
const char src[] = "this string is too long"; char dst[10]; strcpy(dst, src);
With fortify, the buffer overflow is diagnosed at compile-time:
test.cpp:10:18: error: 'strcpy' called with string bigger than buffer strcpy(dst, src); ^
It is not always possible for the compiler to detect this issue at compile-time. In those cases, a run-time check will be used instead that will cause the program to abort rather than continue unsafely.
If you’re using a build system other than ndk-build or CMake via the NDK’s toolchain file, this will not be enabled by default. To enable, simply define _FORTIFY_SOURCE=2. The most reliable way to do this is by adding -D_FORTIFY_SOURCE=2 to your compiler flags.
_FORTIFY_SOURCE=2
-D_FORTIFY_SOURCE=2
Clang can also statically detect some of these issues by using -Wfortify-source (also new in r21). This is on by default, but it’s recommended to enforce fixing issues with -Werror=fortify-source. Use this in addition to the C library features, not instead of, since the warnings do not cover the same cases as the C library extension, nor can it add run-time checks.
-Wfortify-source
-Werror=fortify-source
Note that because run-time support is required for fortify and the feature was gradually added to Android over time, the exact set of APIs protected by fortify depends on your minSdkVersion. Fortify is an improvement, but it is not a replacement for good tests, ASan, and writing safe code.
minSdkVersion
See FORTIFY in Android for an in-depth explanation of fortify.
Since August 2019, all existing and new apps are now required to support 64-bit before they can be released to Google Play; there’s an extension for a limited set of apps. For more information and help on adding support for 64-bit, see our guide.
Arm code is now built with Neon by default. In a previous release we enabled it conditionally based on minSdkVersion, but given the very small number of devices that don’t support Neon we now enable it unconditionally. This offers improved performance on all 32-bit Arm devices (64-bit Arm always had this, and it does not affect Intel ABIs).
As before, this behavior can be disabled for apps that need to continue supporting devices without Neon. Alternatively, those devices can be blacklisted in the Play Console. See https://developer.android.com/ndk/guides/cpu-arm-neon for more information.
Have a look at our roadmap to see what we’re working on next. The next few big things coming up are package management and better CMake integration.