Posted by Chris Sells, Benjamin Poiesz, Karen Ng, Product Management, Android Developer Tools
Today we're excited to introduce Android Jetpack, the next generation of components, tools and architectural guidance to accelerate your Android app development.
Android Jetpack was inspired by the Support Library, a set of components to make it easy to take advantage of new Android features while maintaining backwards compatibility; it's currently used by 99% of every app in the Play Store. Following on that success, we introduced the Architecture Components, designed to make it easier to deal with data in the face of changes and the complications of the app lifecycle. Since we introduced those components at I/O just one year ago, an overwhelming number of you have adopted them. Companies such as LinkedIn, Zillow and iHeartRadio are seeing fewer bugs, higher testability and more time to focus on what makes their app unique.
The Android developer community has been clear -- not only do you like what we've done with these existing components, but we know that you want more! And so more is what you get.
Android Jetpack is a set of components, tools and guidance to make great Android apps. The Android Jetpack components bring together the existing Support Library and Architecture Components and arranges them into four categories:
Android Jetpack components are provided as "unbundled" libraries that are not part of the underlying Android platform. This means that you can adopt each component at your own speed, at your own time. When new Android Jetpack functionality is available, you can add it to your app, deploy your app to the Play Store and give users the new features all in a single day (if you're quick)! The unbundled Android Jetpack libraries have all been moved into the new androidx.* namespace (as described in detail in this post).
androidx.*
In addition, your app can run on various versions of the platform because Android Jetpack components are built to provide their functionality independent of any specific version, providing backwards compatibility.
Further, Android Jetpack is built around modern design practices like separation of concerns and testability as well as productivity features like Kotlin integration. This makes it far easier for you to build robust, high quality apps with less code. While the components of Android Jetpack are built to work together, e.g. lifecycle awareness and live data, you don't have to use all of them -- you can integrate the parts of Android Jetpack that solve your problems while keeping the parts of your app that are already working great.
We know that these benefits are important to you because of feedback like this:
"We had been thinking of trying out MVVM in our code base. Android Architecture Components gave us an easy template to implement it. And it's helped make our code more testable as well; the ability to unit test ViewModels has definitely increased code robustness."
-- Sumiran Pradhan, Sr. Engineer, Zillow
If you want to learn more about how companies are using Android Jetpack components, you can read the developer stories on the Android Developer site.
And finally, as you can see from the Android Jetpack diagram above, today we're announcing new components as well.
Android Jetpack comes with five new components:
The WorkMananager component is a powerful new library that provides a one-stop solution for constraint-based background jobs that need guaranteed execution, replacing the need to use things like jobs or SyncAdapters. WorkManager provides a simplified, modern API, the ability to work on devices with or without Google Play Services, the ability to create graphs of work, and the ability to query the state of your work. Early feedback is very encouraging but we love to make sure that your use cases are covered, too. You can see what we have so far and provide feedback on our alpha on the WorkManager component.
While activities are the system provided entry points into your app's UI, their inflexibility when it comes to sharing data between each other and transitions has made them a less than ideal architecture for constructing your in-app navigation. Today we are introducing the Navigation component as a framework for structuring your in-app UI, with a focus on making a single-Activity app the preferred architecture. With out of the box support for Fragments, you get all of the Architecture Components benefits such as Lifecycle and ViewModel while allowing Navigation to handle the complexity of FragmentTransactions for you. Further, the Navigation component allows you to declare transitions that we handle for you, automatically builds the correct Up and Back behavior, includes full support for deep links, and provides helpers for connecting Navigation into the appropriate UI widgets, like the navigation drawer and bottom navigation. But that's not all! The Navigation Editor in Android Studio 3.2 allows you to see and manage your navigation properties visually:
The Navigation component is also in alpha and we'd love your feedback.
Data presented in an app can be large and costly to load, so it's important to avoid downloading, creating, or presenting too much at once. The Paging component version 1.0.0 makes it easy to load and present large data sets with fast, infinite scrolling in your RecyclerView. It can load paged data from local storage, the network, or both, and lets you define how your content gets loaded. It works out of the box with Room, LiveData, and RxJava.
And finally, to round out the set of new features making their debut in Android Jetpack is the Slices component. A "slice" is a way to surface your app's UI inside of the Google Assistant as a result of a search:
You can learn all about the Slices component and how to integrate it into your app on the Android Developer website.
And last but not least, one goal of Android Jetpack takes advantage of Kotlin language features that make you more productive. Android KTX lets you transform Kotlin code like this:
view.viewTreeObserver.addOnPreDrawListener( object : ViewTreeObserver.OnPreDrawListener { override fun onPreDraw(): Boolean { viewTreeObserver.removeOnPreDrawListener(this) actionToBeTriggered() return true } });
into more concise Kotlin code like the following:
view.doOnPreDraw { actionToBeTriggered() }
This is just the first step in bringing Kotlin support to Android Jetpack components; our goal is to make Android Jetpack great for Kotlin developers (and of course Java developers!).You can read more about Android KTX on the Android Developer web site.
You can get started with Android Jetpack at developer.android.com/jetpack. You'll find docs and videos for Android Jetpack, see what's new in Android Jetpack components, participate in the community and give us feedback. We've also created a YouTube playlist devoted to Android Jetpack, so you can tune in for information about Android Jetpack, components, tools and best practices.
Getting Started with Android Jetpack will tell you how to bring the Android Jetpack components into your existing apps and help you get started with new Android Jetpack apps. Android Studio 3.2 has great tooling support for Android Jetpack. For building new apps, use the Activity & Fragment+ViewData activity, which you can get to from File | New | New Project in Android Studio:
With Android Jetpack, we're taking the benefits of the Support Library and the Architecture Components and turning it up a notch with new components, Android Studio integration and Kotlin support. And while Android Jetpack provides the next generation components, tools and guidance to accelerate your Android development, we've got a lot more that we want to do and we want your help. Please go to developer.android.com/jetpack and let us know what we can do to make your experience building Android apps even better.
Posted By Dave Burke, VP of Engineering
Earlier today we unveiled a beta version of Android P, the next release of Android. Android P puts AI at the core of the operating system and focuses on intelligent and simple experiences. You can read more about the new user features here.
For developers, Android P beta offers a range of ways to take advantage of these new smarts, especially when it comes to increasing engagement with your apps.
You can get Android P beta on Pixel devices by enrolling here. And thanks to Project Treble, you can now get the beta on top devices from our partners as well -- Essential, Nokia, Oppo, Sony, Vivo, and Xiaomi, with others on the way.
Visit android.com/beta for the full list of devices, and details on how to get Android P beta on your device. To get started developing with Android P beta, visit developer.android.com/preview.
Android P makes a smartphone smarter, helping it learn from and adapt to the user. Your apps can take advantage of the latest in machine intelligence to help you reach more users and offer new kinds of experiences.
Battery is the number one priority we hear from mobile phone users, regardless of the device they are using. In Android P we've partnered with DeepMind on a new feature we call Adaptive Battery that optimizes how apps use battery.
Adaptive Battery uses machine learning to prioritize access to system resources for the apps the user cares about most. It puts running apps into groups with different restrictions using four new "App Standby buckets" ranging from "active" to "rare". Apps will change buckets over time, and apps not in the "active" bucket will have restrictions in: jobs, alarms, network and high-priority Firebase Cloud Messages.
If your app is optimized for Doze, App Standby, and Background Limits, Adaptive Battery should work well for you right out of the box. We recommend testing your app in each of the four buckets. Check out the documentation for the details.
App Actions are a new way to raise the visibility of your app to users as they start their tasks. They put your app's core capabilities in front of users as suggestions to handle their tasks, from key touch-points across the system like the Launcher and Smart Text Selection, Google Play, Google Search app, and the Assistant.
Actions use machine learning to surface just the right apps to users based on their context or recent interactions. Because Actions highlight your app where and when it's most relevant, they're a great way to reach new users and re-engage with existing users.
To support App Actions, just define your app's capabilities as semantic intents. App Actions use the same catalog of common intents as conversational Actions for the Google Assistant, which surface on voice-activated speakers, Smart displays, cars, TVs, headphones, and more. There's no API surface needed for App Actions, so they will work on any supported Android platform version.
Actions will be available soon for developers to try, sign up here if you'd like to be notified.
Along with App Actions we're introducing Slices, a new way for your apps to provide remote content to users. With Slices you can surface rich, templated UI in places like Google Search and Assistant. Slices are interactive with support for actions, toggles, sliders, scrolling content, and more.
Slices are a great new way to engage users and we wanted them to be available as broadly as possible. We added platform support in Android P, and we built the developer APIs and templates into Android Jetpack, our new set of libraries and tools for building great apps. Through Jetpack, your Slices implementation can target users all the way back to Kitkat -- across 95% of active Android devices. We'll also be able to update the templates regularly to support new use cases and interactions (such as text input).
Check out the Getting Started guide to learn how to build with Slices -- you can use the SliceViewer tool to see how your Slices look. Over time we plan to expand the number of places that your Slices can appear, including remote display in other apps.
The Smart Reply feature in Gmail and Inbox are excellent examples of how machine intelligence can positively transform an app experience. In Android P we've brought Smart Replies to Notifications with an API to let you provide this optimization to your users. To make it easier to populate replies in your notifications, you can now use ML Kit -- see developers.google.com/mlkit for details.
In Android P we've extended the ML models that identify entities in content or text input to support more types like Dates and Flight Numbers and we're making those improvements available to developers through the TextClassifier API. We're also updating the Linkify API that automatically creates links to take advantage of these TextClassification models and have enriched the options the user has for quick follow on actions. Developers will have additional options of linkifying any of the entities recognized by the TextClassifier service. Smart Linkify has significant improvements in accuracy and precision of detection and performance.
Even better, the models are now updated directly from Google Play, so your apps can take advantage of model improvements using the same APIs. Once the updated models are installed, all of the entity recognition happens on-device and data is not sent over the network.
We put a special emphasis on simplicity in Android P, evolving Android's UI to streamline and enhance user tasks. For developers, the changes help improve the way users find, use, and manage your apps.
We're introducing a new system navigation in Android P that gives users easier access to Home, Overview, and the Assistant from a single button on every screen. The new navigation simplifies multitasking and makes discovering related apps much easier. In the Overview, users have a much larger view of what they were doing when they left each app, making it much easier to see and resume the activity. The Overview also provides access to search, predicted apps, and App Actions, and takes users to All Apps with another swipe.
In Android P we've also added a new Magnifier widget, designed to make it easier to select text and manipulate the text cursor in text. By default, classes that extend TextView automatically support the magnifier, but you can use the Magnifier API to attach it to any custom View, which opens it up to a variety of uses.
We're making it simple for users to identify and manage apps that are using battery in the background. From our work on Android Vitals, Android can detect battery-draining app behaviors such as excessive wake locks and others. Now in Android P, Battery Settings lists such apps and lets users restrict their background activities with a single tap.
When an app is restricted, its background jobs, alarms, services, and network access are affected. To stay off of the list, pay attention to your Android Vitals dashboard in the Play Console, which can help you understand performance and battery issues.
Background Restrictions ensures baseline behaviors that developers can build for across devices and manufacturers. Although device makers can add restrictions on top of the core set, they must provide user controls via Battery Settings.
We've added a standard API to let apps check whether they are restricted, as well as new ADB commands to let you manually apply restrictions to your apps for testing. See the documentation for details. We also plan to add restrictions related metrics to your Play Console Android Vitals dashboard in the future.
Android P introduces a new Dynamics Processing Effect in the Audio Framework that lets developers improve audio quality. With Dynamics Processing, you can isolate specific frequencies and lower loud or increase soft sounds to enhance the acoustic quality of your application. For example, your app can improve the sound of someone who speaks quietly in a loud, distant or otherwise acoustically challenging environment.
The Dynamics Processing API gives you access to a multi-stage, multi-band dynamics processing effect that includes a pre-equalizer, a multi-band compressor, a post-equalizer and a linked limiter. It lets you modify the audio coming out of Android devices and optimize it according to the preferences of the listener or the ambient conditions. The number of bands and active stages is fully configurable, and most parameters can be controlled in realtime, such as gains, attack/release times, thresholds, etc.
To see what you can do with the Dynamics Processing Effect, please see the documentation.
Android P provides a standard authentication experience across the growing range of biometric sensors. Apps can use the new BiometricPrompt API instead of displaying their own biometric auth dialogs. This new API replaces the FingerprintDialog API added in DP1. In addition to supporting Fingerprints (including in-display sensors), it also supports Face and Iris authentication, providing a system-wide consistent experience. There is a single USE_BIOMETRIC permission that covers all device-supported biometrics. FingerprintManager and the corresponding USE_FINGERPRINT permission are now deprecated, so please switch to BiometricPrompt as soon as possible.
Android P introduces Android Protected Confirmation, which use the Trusted Execution Environment (TEE) to guarantee that a given prompt string is shown and confirmed by the user. Only after successful user confirmation will the TEE then sign the prompt string, which the app can verify.
We've added StrongBox as a new KeyStore type, providing API support for devices that provide key storage in tamper-resistant hardware with isolated CPU, RAM, and secure flash. You can set whether your keys should be protected by a StrongBox security chip in your KeyGenParameterSpec.
Bringing a new version of Android to users takes a combined effort across Google, silicon manufacturers (SM), device manufacturers (OEMs), and carriers. The process is technically challenging and can take time -- to make it easier, we launched Project Treble last year as part of Android Oreo. Since then we've been working with partners on the initial bring-up and now we're seeing proof of what Treble can do.
Today we announced that 6 of our top partners are joining us to release Android P Beta on their devices -- Sony Xperia XZ2, Xiaomi Mi Mix 2S, Nokia 7 Plus, Oppo R15 Pro, Vivo X21UD and X21, and Essential PH‑1. We're inviting early adopters and developers around the world to try Android P Beta on any of these devices -- as well as on Pixel 2, Pixel 2 XL, Pixel, and Pixel XL.
You can see the full list of supported partner and Pixel devices at android.com/beta. For each device you'll find specs and links to the manufacturer's dedicated site for downloads, support, and to report issues. For Pixel devices, you can now enroll your device in the Android Beta program and automatically receive the latest Android P Beta over-the-air.
Try Android P Beta on your favorite device today and let us know your feedback! Check out our post on Faster Adoption with Project Treble for more details.
With more users starting to get Android P Beta on their devices, now is the time to test your apps for compatibility, resolve any issues, and publish an update as soon as possible. See the migration guide for steps and a recommended timeline.
To test for compatibility, just install your current app from Google Play onto a device or emulator running Android P Beta and work through the user flows. The app should run and look great, and handle the Android P behavior changes properly. In particular, pay attention to adaptive battery, Wi-Fi permissions changes, restrictions on use of camera and sensors from the background, stricter SELinux policy for app data, and changes in TLS enabled by default, and Build.SERIAL restriction.
It's important to test your apps for uses of non-SDK interfaces. As noted previously, in Android P we're starting a gradual process to restrict access to selected non-SDK interfaces, asking developers -- including app teams inside Google -- to use the public equivalents instead.
If your apps are using private Android interfaces and libraries, you should move to using public APIs from the Android SDK or NDK. The first developer preview displayed a toast warning for uses of non-SDK interfaces -- starting in Android P Beta, uses of non-SDK interfaces that are not exempted will generate errors in your apps -- so you'll now get exceptions thrown instead of a warning.
To help you identify reflective usage of non-SDK APIs, we've added two new methods in StrictMode. You can use detectNonSdkApiUsage() to warn when your app accesses non-SDK APIs via reflection or JNI, and you can use permitNonSdkApiUsage() to suppress StrictMode warnings for those accesses. This can help you understand your app's use of non-SDK APIs -- even if the APIs are exempted at this time, it's best to plan for the future and eliminate their use.
In cases where there is no public API that meets your use-case, please let us know immediately. We want to make sure that the initial rollout only affects interfaces where developers can easily migrate to public alternatives. More about the restrictions is here.
It's also important to test your app with display cutout. Now you can use several of our partner devices running Android Beta to make sure your app looks its best with a display cutout. You can also use the emulated cutout support that's available on any Android P device through Developer options.
When you're ready, dive into Android P and learn about the many new features and APIs you can take advantage of in your apps. To make it easier to explore the new APIs, take a look at the API diff reports (API 27->DP2, DP1->DP2) along with the Android P API reference. Visit the Developer Preview site for details. Also check out this video highlighting what's new for developers in Android P Beta.
To get started with Android P, download the P Developer Preview SDK and tools into Android Studio 3.1 or use the latest version of Android Studio 3.2. If you don't have a device that runs Android P Beta, you can use the Android emulator to run and test your app.
As always, your feedback is critical, so please let us know what you think — the sooner we hear from you, the more of your feedback we can integrate. When you find issues, please report them here. We have separate hotlists for filing platform issues, app compatibility issues, and third-party SDK issues.
Today, we launch an early preview of the new Android extension libraries (AndroidX) which represents a new era for the Support Library. Please preview the change and give us your feedback. Since this is an early preview, we do not recommend trying this on any production projects as there are some known issues.
The Support Library started over 7+ years ago to provide backwards compatibility to framework APIs. Over the years, the library has grown to include device-specific UX, debugging, testing and other utilities. The adoption of the Support Library has been phenomenal; most Android apps use the Support Library today. We want to increase our investment in this area, and it is critical that we lay a solid foundation.
In that vein, we took a step back and chatted with many of you. The feedback has been consistent and unanimous; the organic growth of the library has become confusing. There are components and packages named "v7" when the minimal SDK level we support is 14! We want to make it clear for you to understand the division between APIs that are bundled with the platform and which are static libraries for app developers that work across different versions of Android.
With that in mind, say "Hello World" to "AndroidX". As previously noted in the Android KTX announcement, we are adding new features under this package, and updating some existing ones.
android.* vs androidx.* namespaces
android.*
Writing Android apps means depending on two kinds of classes:
PackageManager
AppCompatActivity
ViewModel
Many times, unbundled libraries can be a better choice, since they provide a single API surface across different Android versions. This refactor moves the unbundled libraries - including all of the Support Library and Architecture Components - into the AndroidX package, to make it clear to know which dependencies to include.
Revised naming for packages and Maven artifacts
We redesigned the package structure to encourage smaller, more focused libraries that relieve pressure on apps and tests that aren't using Proguard or Multidex. Maven groupIds and artifactIds have been updated to better reflect library contents, and we have moved to prefixing library packages with their groupId to create an obvious link between the class that you are using and the Maven artifact from which it came.
Generally, you can expect the following mapping from old to new packages:
android.support.**
androidx.@
android.databinding.**
androidx.databinding.@
android.design.**
com.google.android.material.@
android.support.test.**
androidx.test.@
The Architecture Components libraries have also been moved under androidx and their package names simplified to reflect their integration with core libraries. A sample of changes to these libraries:
androidx
android.arch.**
android.arch.persistence.room.**
androidx.room.@
android.arch.persistence.**
androidx.sqlite.@
Additionally, following the introduction in 28.0.0-alpha1 of Material Components for Android as a drop-in replacement for Design Library, we have refactored the design package to reflect its new direction.
For a complete listing of mappings from 28.0.0-alpha1 (android.support) to 1.0.0-alpha1 (androidx), please see the full AndroidX refactoring map. Please note that there may be minor changes to this map during the alpha phase.
android.support
Per-artifact strict semantic versioning
Starting with the AndroidX refactor, library versions have been reset from 28.0.0 to 1.0.0. Future updates will be versioned on a per-library basis, following strict semantic versioning rules where the major version indicates binary compatibility. This means, for example, that a feature may be added to RecyclerView and used in your app without requiring an update to every other library used by your app. This also means that libraries depending on androidx may provide reasonable guarantees about binary compatibility with future releases of AndroidX -- that a dependency on a 1.5.0 revision will still work when run against 1.7.0 but will likely not work against 2.0.0.
Migration from 28.0.0-alpha1
Moving your app from android.support to androidx-packaged dependencies has two major parts: source refactoring and dependency translation.
Source refactoring updates your Java code, XML resources, and Gradle configuration to reference the refactored classes and Maven artifacts. This feature is available in Android Studio Canary 14 for applications targeting Android P.
If you depend on a library that references the older Support Library, Android Studio will update that library to reference androidx instead via dependency translation. Dependency translation is automatically applied by the Android Gradle Plugin 3.2.0-alpha14, which rewrites bytecode and resources of JAR and AAR dependencies (and transitive dependencies) to reference the new androidx-packaged classes and artifacts. We will also provide a standalone translation tool as a JAR.
What's next?
We understand this is a big change for existing projects and codebases. Our intention is to provide a strong foundation that sets Android library projects up for more sustainable growth, better modularity, and smaller code size.
We hope that these changes also make it easier for developers to discover features and implement high-quality apps in less time; however, we understand that migration takes time and may not fit into everyone's production schedule. For this reason, we will continue to provide parallel updates to an android.support-packaged set of libraries for the duration of the P preview SDK timeframe. These updates will continue the 28.0.0 versioning scheme that began with 28.0.0-alpha1 in March 2018, and they will continue to be source-compatible with existing projects that depend on the android.support package.
The stable release of 28.0.0 will be the final feature release packaged as android.support. All subsequent feature releases will only be made available as androidx-packaged artifacts.
We'd love to hear from you as we iterate on this exciting future. Send us feedback by posting comments below, and please file any bugs you run into on AOSP.
We look forward to a new era of Android libraries!
Posted by Dave Smith, Developer Advocate for IoT
Android Things is Google's managed OS that enables you to build and maintain Internet of Things devices at scale. We provide a robust platform that does the heavy lifting with certified hardware, rich developer APIs, and secure managed software updates using Google's back-end infrastructure, so you can focus on building your product.
After a developer preview with over 100,000 SDK downloads, we're releasing Android Things 1.0 to developers today with long-term support for production devices. Developer feedback and engagement has been critical in our journey towards 1.0, and we are grateful to the over 10,000 developers who have provided us feedback through the issue tracker, at workshop events, and through our Google+ community.
Today, we are announcing support for new System-on-Modules (SoMs) based on the NXP i.MX8M, Qualcomm SDA212, Qualcomm SDA624, and MediaTek MT8516 hardware platforms. These modules are certified for production use with guaranteed long-term support for three years, making it easier to bring prototypes to market. Development hardware and reference designs for these SoMs will be available in the coming months.
New SoMs from NXP, Qualcomm, and MediaTek
The Raspberry Pi 3 Model B and NXP i.MX7D devices will continue to be supported as developer hardware for you to prototype and test your product ideas. Support for the NXP i.MX6UL devices will not continue. See the updated supported platforms page for more details on the differences between production and prototype hardware.
One of the core tenets of Android Things is powering devices that remain secure over time. Providing timely software updates over-the-air (OTA) is a fundamental part of that. Stability fixes and security patches are supported on production hardware platforms, and automatic updates are enabled for all devices by default. For each long-term support version, Google will offer free stability fixes and security patches for three years, with additional options for extended support. Even after the official support window ends, you will still be able to continue to push app updates to your devices. See the program policies for more details on software update support.
Use of the Android Things Console for software updates is limited to 100 active devices for non-commercial use. Developers who intend to ship a commercial product running Android Things must sign a distribution agreement with Google to remove the device limit. Review the updated terms in the Android Things SDK License Agreement and Console Terms of Service.
The Android Things Console includes a new interface to configure hardware peripherals, enabling build-time control of the Peripheral I/O connections available and device properties such as GPIO resistors and I2C bus speed. This feature will continue to be expanded in future releases to encompass more peripheral hardware configurations.
Over the past several months, we've worked closely with partners to bring products built on Android Things to market. These include Smart Speakers from LG and iHome and Smart Displays from Lenovo, LG, and JBL, which showcase powerful capabilities like Google Assistant and Google Cast. These products are hitting shelves between now and the end of summer.
Startups and agencies are also using Android Things to prototype innovative ideas for a diverse set of use-cases. Here are some examples we are really excited about:
If you're building a new product powered by Android Things, we want to work with you too! We are introducing a special limited program to partner with the Android Things team for technical guidance and support building your product. Space is limited and we can't accept everyone. If your company is interested in learning more, please let us know here.
Take a look at the full release notes for Android Things 1.0, and head over to the Android Things Console to begin validating your devices for production with the 1.0 system image. Visit the developer site to learn more about the platform and explore androidthings.withgoogle.com to get started with kits, sample code, and community projects. Finally, join Google's IoT Developers Community on Google+ to let us know what you're building with Android Things!
Posted by John Posavatz, Product Manager, Android Auto
Since 2015, Android developers have been building and growing great apps for cars. Drivers are benefiting from thoughtfully designed apps that provide safe and seamless connected experiences, whether they drive one of many Android Auto compatible cars or use the Android Auto app on their phones.
Today, thousands of apps for Android Auto are available through the Google Play Store for millions of drivers in over 30 countries around the world. And because the Google Assistant is available on Android Auto, developers are able to build voice-powered experiences on their apps that let drivers get things done while keeping their eyes on the road.
But it doesn't end there -- great driving apps will soon reach beyond Android Auto users. Last year, carmakers Volvo Cars and Audi announced the development of new connected cars powered by Android. As an important next step, we are now working with Volvo Cars to bring the Play Store and the Google Assistant directly into their next-generation cars, along with Google Maps. The opportunities for developers are endless -- their apps are able to reach millions of Android Auto users today, and drivers of Android-powered cars in the future.
This week at Google I/O, we are sharing some updates that help developers build an even better in-car experience and become a part of the evolving ecosystem. We will be demonstrating those changes in our Sandbox by collaborating with several app developers, including iHeartRadio, Pandora, Pocket Casts, Spotify, Telegram, WhatsApp as well as Google's own apps (including Android Messages, Play Books and Play Music).
First, a fresh new design enables media apps to make their content more accessible through new visual templates. For example, browsable content is placed front and center as soon as you open up an app, enabling you to easily recognize and quickly start listening to songs and podcasts.
Second, new search capabilities allow media apps to directly integrate their results into Android Auto. This allows drivers to quickly discover tracks that are related to what they're currently listening to, such as a song's live version, or a song with the same name from a different artist.
Finally, we now support group messaging and RCS. Using the Google Assistant, you can easily communicate with a group of friends while keeping your hands on the wheel.
If you're attending I/O, come check out the Automotive session at Google I/O on May 9 at 9:30am PST. We will also be displaying three cars in the Sandbox area that showcase different integrations in real life, including a preview of Volvo's future infotainment system displayed in the current XC40. If you're not at I/O, you can still catch the livestream of the session. Developers can also sign up to learn more about the media and messaging updates as we release more information.
Posted by Doug Stevenson, Developer Advocate
Starting today, the Android SDKs for Google Play services and Firebase will be using a new build and versioning scheme. This may require some changes to the way you build your Android app, so be sure to read here thoroughly to get all the details.
Here's a quick summary of what's new in these SDKs:
Beginning with version 15 of all Play services and Firebase libraries, version numbers adhere to the semantic versioning scheme. As you know, semver is an industry standard for versioning software components, so you can expect that version number changes for each library indicate the amount of change in the library.
Each Maven dependency matching com.google.android.gms:play-services-* and com.google.firebase:firebase-* is no longer required to have the same version number in order to work correctly at build time and at run time. You will be able to upgrade each dependency independently from each other. As such, a common pattern for specifying the shared version number for Play and Firebase dependencies in Gradle builds will no longer work as expected. The pattern (now anti-pattern) looks like this:
com.google.android.gms:play-services-*
com.google.firebase:firebase-*
buildscript { ext { play_version = '15.0.0' } } dependencies { // DON'T DO THIS!! // The following use of the above buildscript property is no longer valid. implementation "com.google.android.gms:play-services-auth:${play_version}" implementation "com.google.firebase:firebase-auth:${play_version}" implementation "com.google.firebase:firebase-firestore:${play_version}" }
The above Gradle configuration defines a buildscript property called play_version with the version of the Play and Firebase SDKs, and uses that to declare dependencies. This pattern has been helpful to keep all the dependency versions together, as previously required. However, this pattern no longer applies starting with version 15 for each library. Each dependency that you use may now be at different versions. You can expect that individual library updates may not be released at the same time - they may be updated independently.
play_version
In order to support this change in versioning, the Play services Gradle plugin has been updated. If you're using this plugin, it appears like this at the bottom of build.gradle in your app module:
build.gradle
apply plugin: 'com.google.gms.google-services'
Here is what has changed in this plugin:
failOnVersionConflict()
The first version of this plugin that works with the new versioning system is 3.3.0. When working with the new versions of Play and Firebase libraries, it should be added to your buildscript classpath dependencies as follows:
classpath 'com.google.gms:google-services:3.3.0'
If you're not using this plugin, but you still want strict version checking of your dependencies, you can apply this new Gradle plugin instead:
apply plugin: 'com.google.android.gms.strict-version-matcher-plugin'
In order to use this plugin, you will also need to add the following to your buildscript classpath, obtained from Google's Maven Repository:
classpath 'com.google.android.gms:strict-version-matcher-plugin:1.0.0'
If you're not using Android Studio 3.1 to develop your app, you will need to upgrade in order to get the correct version checking behavior within the IDE. Get the newest version of Android Studio here.
With these changes in place, you are now able to adopt new versions of the various SDKs more freely, without a strict requirement to update everything at once. It also enables the development teams for each SDK to ship fixes and enhancements more quickly. Going forward, you can track the releases for Play services SDKs and Firebase SDKs with the provided links.
Posted by Purnima Kochikar, Director, Apps and Games Business Development, Google Play
This year's Google Play Awards will take place on Monday, May 7th, kicking off the week of Google I/O. Celebrating our third year, we're excited to highlight nine categories; some you may recognize from previous years, along with new additions highlighting growth areas and trends we're focused on, such as building for emerging markets.
Each year, the Google Play Awards recognize top apps and games on Google Play. They represent some of the best experiences available on Android, with an emphasis on overall quality, strong design, technical performance, and innovation. The nominees were selected by various teams across Google, and all meet criteria thresholds covering high star rating, Android vitals, and have had a launch or major update since April 2017.
Congratulations to this year's nominees below and don't forget to check them out on the Google Play store at g.co/play/gpa2018.
Standout Well-Being App
Apps empowering people to live the best version of their lives, while demonstrating responsible design and engagement strategies
Best Accessibility Experience
Apps or games enabling device interaction in an innovative way that serves people with disabilities or special needs
Best Social Impact
Apps or games that create a positive impact in communities around the world (focused on health, education, crisis response, refugees, financial health & fundraising functions)
Standout Indie
Games from indie developers that focus on artistic design, gameplay mechanics, and overall polish
Best Community Building Game
Games built to connect gamers, encouraging social interaction and community building
Best AR or VR Experience
Apps or games offering highly engaging and immersive experiences with optimal use of ARCore or Daydream UI
Standout Build for Billions Experience
Apps or games with optimized performance, localization, and culturalization for emerging markets
Standout Startup
Apps from new developers that offer a unique experience while achieving strong organic install growth.
Best Breakthrough Hit
New apps or games with excellent overall design, user experience, engagement and retention, and strong organic install growth
Check out the winners, and make sure to try out some of these great apps and games on Google Play at g.co/play/gpa2018.
How useful did you find this blogpost? ★ ★ ★ ★ ★
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
