May 11

Hello World, AndroidX

Posted by Alan Viverette (/u/alanviverette), Kathy Kam (@kathykam) , Lukas Bergstrom (@lukasb)

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

Writing Android apps means depending on two kinds of classes:

  • Classes like PackageManager, which are bundled with the operating system and can have different APIs and behavior for different Android versions
  • Classes like AppCompatActivity or ViewModel, which are unbundled from the operating system and ship in your apk. These libraries are written to provide a single API surface with behavior that’s as consistent as possible across Android versions.

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:

Old New** androidx.@
android.databinding.** androidx.databinding.@**** (in a future release) 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:

Old New
android.arch.** androidx.@**
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 ( 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.

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 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 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 package.

The stable release of 28.0.0 will be the final feature release packaged as 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!

Android Developers Blog

May 08

Say Hello to Android Things 1.0

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.

Powerful production hardware

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.

Secure software updates

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.

Hardware configuration

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.

Production ready

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:

  • Byteflies: Docking station that securely transmits wearable health data to the cloud
  • Mirego: Network of large photo displays driven by public photo booths in downtown Montreal

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.

Additional resources

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 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!

Android Developers Blog

Nov 20

Hello Places API for Android and iOS!

Posted by Jen Kovnats Harrington, Product Manager, Google Maps APIs

Originally posted to Google Geo Developers blog

People don’t think of their location in terms of coordinates on a map. They want context on what shops or restaurants they’re at, and what’s around them. To help your apps speak your users’ language, we’re launching the Places API for Android, as well as opening a beta program for the Places API for iOS.

The Places API web service and JavaScript library have been available for some time. By providing native support for Android and iOS devices, you can optimize the mobile experience with the new APIs by taking advantage of the device’s location signals.

The Places APIs for Android and iOS bridge the gap between simple geographic locations expressed as latitude and longitude, and how people associate location with a known place. For example, you wouldn’t tell someone you were born at 25.7918359,-80.2127959. You’d simply say, “I was born in Jackson Memorial Hospital in Miami, Florida.” The Places API brings the power of Google’s global places database into your app, providing more than 100 million places, like restaurants, local businesses, hotels, museums, and other attractions.

Key features include:

  • Add a place picker: a drop-in UI widget that allows your users to specify a place
  • Get the place where the user is right now
  • Show detailed place information, including the place’s name, address, phone number, and website
  • Use autocomplete to save your users time and frustration typing out place names, by automatically completing them as they type
  • Make your app stand out by adding new places that are relevant to your users and seeing the places appear in Google’s Places database
  • Improve the map around you by reporting the presence of a device at a particular place.

To get started with the Places API for Android, watch this DevByte, check out the developer documentation, and play with the demos. To apply for the Places API for iOS beta program, go here.

Join the discussion on

+Android Developers

Android Developers Blog

Jul 02

Hello World, meet our new experimental toolchain, Jack and Jill

Posted by Paul Rashidi, Developer Programs Engineer

We’ve been working on a new toolchain for Android that’s designed to improve build times and simplify development by reducing dependencies on other tools. Today, we’re introducing you to Jack (Java Android Compiler Kit) and Jill (Jack Intermediate Library Linker), the two tools at the core of the new toolchain.

We are making an early, experimental version of Jack and Jill available for testing with non-production versions of your apps. This post describes how the toolchain works, how to configure it, and how to let us know of your feature requests and any bugs you find.

So how does it work?

When the new tool chain is enabled, Jill will translate any libraries you are referencing to a new Jack library file (.jack). This prepares them to be quickly merged with other .jack files. The Android Gradle plugin and Jack collect any .jack library files, along with your source code, and compiles them into a set of dex files. During the process, Jack also handles any requested code minification. The output is then assembled into an APK file as normal. We also include support for multiple dex files, if you have enabled that support.

How do I use it?

Jack and Jill are already available in the 21.1.1+ Build Tools for Android Studio. Complementary Gradle support is also currently available in the Android 1.0.0+ Gradle plugin. To get started, all you need to do is make sure you’re using these versions of the tooling and then add a single line in your build.gradle file. Perform a build of your application to receive a newly built APK.

android {
    buildToolsRevision '21.1.1'
    defaultConfig {
      // Enable the experimental Jack build tools.
      useJack = true

If you want to build your app with both toolchains, Product Flavors are a great way to do this. Your build.gradle file might look something like the snippet below.

android {
    productFlavors {
        dev {
        experimental {
            useJack = true
        prod {

How do I configure my build?

We are making the transition to Jack as smooth as possible by supporting minification (shrinking and/or obfuscation), as well as repackaging (i.e. similar to tools like jarjar), while using the same input files as you are used to. Minification is available in the Gradle plugin immediately and repackaging will follow. You should continue to use the “minifyEnabled true” directive to reduce the size of your app among all other optimizations you would normally use. There are more details on our reference page (linked below) regarding the level of support for each type of optimization. We encourage you to provide feedback there if your current configuration isn’t supported.

Give us your feedback

We are attempting to make the toolchain as easy to test out as possible and we’re looking for your help to fine tune it. Use the reference page to find known issues, file feature requests, and report bugs. Happy building!

Join the discussion on

+Android Developers

Android Developers Blog