Posted by Sam Lin, Product Manager, Android
With Project Marble, the Android Studio team focused our efforts on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. Performance is an underlying tenant to delivering a high quality IDE. To this end, we are sharpening our product focus and we will only support 64-bit operating systems going forward. Using Android Studio with an 64-bit operating systems enables efficient access to memory for both the IDE and the Android Emulator, and overall leads to a better development experience. While this change will not affect most Android Studio users, this change does have an impact if you use 32-bit versions of Microsoft® Windows®. To aid in this transition for those developers using 32-bit versions of Microsoft Windows, we want to give you details on the upcoming depreciation timeline plus steps to take to be ready for this upcoming change.
To minimize the impact of this change towards exclusively supporting 64-bit operating systems, we will first deprecate the 32-bit version. During the depreciation phase, both Android Studio and the Android Emulator will continue to work but the products will not receive new feature updates. During this transition period you can still download the product from the Android Studio web site. After one year, we will officially end product support and will remove the 32-bit product version download links. Note, if you have the 32-bit version of Android Studio previously installed during this period then the product should continue to work, but we will not provide a link for you to re-download the product. The exact dates for the depreciation and end-of-support period are in the table below:
There are a few advantages to using a 64-bit version of Android Studio, which include:
To recap, before ending support for the 32-bit version of Android Studio, we want to inform you in advance, provide guidance, and allow for a one-year lead time to help you migrate to a 64-bit operating system. You can still use 32-bit versions of Android Studio, but be mindful that these version will not receive future updates. Therefore, if you want to migrate we suggest you start planning early so that you can continue to get the latest product updates and take advantage of the performance improvements of a 64-bit development environment.
Posted by Karen Ng, Group Product Manager and Jisha Abubaker, Product Manager, Android
Last year, we launched Android Jetpack, a collection of software components designed to accelerate Android development and make writing high-quality apps easier. Jetpack was built with you in mind -- to take the hardest, most common developer problems on Android and make your lives easier.
Jetpack has seen incredible adoption and momentum. Today, 80% of the top 1,000 apps in the Play store are using Jetpack. We’ve also heard feedback from so many of you across our early access developer programs and user studies, as well as Reddit, Stack Overflow, and Slack, that has helped shape these APIs. Very humbly, thank you.
Today, we are excited to share with you 11 Jetpack libraries that can be used in development now and an early-development, open-source project called Jetpack Compose to simplify UI development.
CameraX
We've heard from many of you that developing camera apps or integrating camera functionality within your existing apps is hard. With the new CameraX library, we want to enable you to create great camera-driven experiences in your application without worrying about the underlying device behavior. This API is backwards compatible to Android 5.0 (API 21) or higher, ensuring that the same code works on most devices in the market. While it leverages the capabilities of camera2, it uses a simpler, use case-based approach that is lifecycle-aware eliminating significant amount of boilerplate code vs camera2. Finally, it enables you to access the same functionality as the native camera app on supported devices. These optional Extensions enable features like Portrait, Night, HDR, and Beauty.
LiveData and Lifecycles w/ coroutines
We heard you loud and clear and agree that LiveData must support your common one-shot asynchronous operations. With Lifecycle & LiveData KTX, you can do so with Kotlin coroutines that are lifecycle-aware. Kotlin coroutines have been well received by the developer community for how they simplify the way concurrency is handled within Android apps. We want to simplify it even further and enable you to use them safely by offering coroutine scopes tied to lifecycles, coroutine dispatchers that are lifecycle-aware, and support for simple asynchronous chains with the new liveData builder.
Benchmark
The Benchmark library provides you a quick way to benchmark your app code, whether it is written in Kotlin, the Java programming language or native code. We use this library to continuously benchmark Jetpack libraries we release to ensure we do not introduce any latency into your code. You can now do the same right within your development environment in Android Studio, easily measuring database queries, view inflation, or a RecyclerView scroll. The library takes care of what is needed to provide reliable and consistent results like handling warm-up periods, removing outliers, and locking CPU clocks.
Security
To maximize security of an application’s data at-rest, the new Security library implements security best practices for you. It provides strong security that balances encryption with performance for consumer apps like banking and chat. It also provides a maximum level of security for apps that require a hardware-backed keystore with user presence and simplifies many operations including key generation and validation.
ViewModel with SavedState
ViewModel provided you an easy way to save your UI data in the event of a configuration change. It did not save your app state in the event of process death, and many of you have been relying on SavedInstanceState alongside ViewModel. With the ViewModel with SavedState module, you can eliminate boilerplate code and gain the benefits of using both ViewModel and SavedState with simple APIs to save and retrieve data right from your ViewModel.
ViewPager2
ViewPager2, the next generation of ViewPager, is now based on RecyclerView and supports vertical scrolling and RTL (Right-to-Left) layouts. It also provides a much easier way to listen for page data changes with registerOnPageChangeCallback.
registerOnPageChangeCallback.
ConstraintLayout 2.0
ConstraintLayout 2.0 brings up new optimizations, and new way of customizing layouts, with the addition of helper classes. As part of ConstraintLayout 2.0, MotionLayout provides an easy way to manage motion and widget animation in your applications. You can easily describe transitions between layouts and animation of properties. MotionLayout is fully declarative in XML, allowing you to describe even complex transitions without requiring any code.
Biometrics Prompt
Users are accustomed to biometric credentials on their phones, but if your app requires a biometric login, it is important to make sure that users are provided a consistent and safe way to enter their credentials. The Biometrics library provides a simple system prompt giving the user a trustworthy experience.
Enterprise
With the Jetpack Enterprise library, your managed enterprise apps can send feedback back to Enterprise Mobility Management providers in the form of keyed app states, while taking advantage of backwards compatibility with managed configurations.
Android for Cars
With the Android for Cars libraries, you can provide your users a driver-optimized version of your app that will be automatically installed onto the vehicle’s infotainment system in vehicles equipped with the Android Automotive OS. It also allows your apps to work with the Android Auto app, providing the driver-optimized version anytime on their device.
And in case you missed it, we announced stable releases of Jetpack WorkManager (background processing) and Jetpack Navigation (in-app navigation) just a few months ago.
Today, we open-sourced an early preview of Jetpack Compose, a new unbundled toolkit designed to simplify UI development by combining a reactive programming model with the conciseness and ease-of-use of Kotlin. We have always done our best work when we did it with you - our developer community. That’s why we decided to develop Jetpack Compose in the open, starting today.
In that vein, we took a step back and chatted with many of you. We heard strong feedback from developers that they like the modern, reactive APIs that Flutter, React Native, Litho, and Vue.js represent. We also heard that developers love Kotlin, with over 53% of professional Android developers using it and with 20% higher language satisfaction ratings than the Java programming language. Kotlin has become the fastest-growing language in terms of number of contributors on GitHub.
So, we decided to invest in the reactive approach to declarative programming and create an easier way to build UIs with Kotlin.
We are building Compose with a few core principles:
A Compose application is made up of composable functions that transform application data into a UI hierarchy. A function is all you need to create a new UI component. To create a composable function just add the @Composable annotation to the function name. Under the hood, Compose uses a custom Kotlin compiler plug-in so when the underlying data changes, the composable functions can be re-invoked to generate an updated UI hierarchy. The simple example below prints a string to the screen.
We know that adopting any new framework is a big change for existing projects and codebases, which is why we’ve designed Compose like all of Jetpack -- with individual components that you can adopt at your own pace and are compatible with existing views.
If you want to learn more about Jetpack Compose or download its source to try it for yourself, check out http://d.android.com/jetpackcompose
We'd love to hear from you as we iterate on this exciting future together. Send us feedback by posting comments below, and please file any bugs you run into on AOSP or directly through the feedback buttons in the Android Studio Jetpack Compose build in AOSP. Since this is an early preview, we do not recommend trying this on any production projects.
Happy Jetpacking!
Posted by Jamal Eason, Product Manager, Android
Android Studio 3.5 Beta is ready to download today. Last year, at Google I/O, we heard from many of you that you wanted us to focus even more on quality and stability over features. Consequently, we kicked off Project Marble, focused on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. Android Studio 3.5 is the culmination of this effort. The results of Project Marble are focused on three core areas: system health, feature polish, and bugs. We are seeking your final round of feedback to make sure we didn't miss a key area that matters to you, so download Android Studio 3.5 on the beta channel today to let us know what you think.
Many times it can be difficult to see the range of changes that go into a quality release. Therefore, this post and our Google I/O talk on What’s New in Android Development Tools walk through a variety of changes in each of the major focus areas of Project Marble within Android Studio 3.5. We are certainly not done improving quality with Android Studio, but with the work and new infrastructure put into Project Marble for long term quality tracking we hope that you are even more productive in developing Android apps.
What's New in Android Development Tools (Google I/O'19)
System Health - Memory
One of the major points of feedback on Android Studio is how slow the IDE runs over time. Many times the reason behind this experience is due to unexpectedly reaching memory pressure or IDE memory leaks. We dug into this area, and as part of Project Marble, we have addressed over 33 impactful memory leaks. To identify leaks, we now measure out-of-memory exceptions on an internal dashboard on an on-going basis for those who opt-in to share data with us which enables us to focus and fix the most impactful issues. Starting with Android Studio 3.5, when the IDE runs out of memory, we capture some high level statistics about the size of the memory heap and dominant objects in the heap. With this data the IDE can do two things: suggest better memory settings and offer to do a deeper memory analysis.
Memory Settings
Memory Usage Report
System Health - Exceptions
We have revamped our exception process backend pipeline. Now with the opt-in data we have earlier signals of common exceptions in aggregate which lets us prioritize and fix issues earlier in the canary release process than before. Moreover, we reduced the amount of times we prompt you for exceptions, since the analytics and opt-in crash reports are now more actionable for our team. The net result is that you should see the blinky red exception report icon in the lower status bar of the IDE less frequently.
Android Studio Exception Bubble
System Health - User Interface Freezes
User Interface (UI) freezes are another common issue we heard from you. In Android Studio 3.5, we extended the infrastructure of the underlying Intellij platform, and now measure UI thread stops that last longer than a few moments. Over time, we will have a bigger picture of the top hit spots to focus our efforts on. For example, during the Project Marble development, we found in our data that XML code editing was notably slower in the IDE. With this data point, we optimized XML typing, and have measurably better performance in Android Studio 3.5. You can see below that editing data binding expressions in XML is faster due to typing latency improvements.
Code Editing Before - Android Studio 3.4 (left) and Code Editing After - Android Studio 3.5 (right)
System Health - Build Speed
We continued our investment in build speed. For those developers with larger projects, it is the number one concern. As we uncovered in our recent Medium blog post on build speed, many elements can affect build performance, sometimes slowing it down more than we can improve. However, during Project Marble, we made speed improvements by adding incremental build support to the top annotation processors including Glide, AndroidX data binding, Dagger, Realm, and Kotlin (KAPT). Incremental support can make a notable impact on build speed. For example, in our preliminary analysis, adding incremental support just for Kotlin has improved submodule non-ABI code changes for the Google I/O schedule app from 9.1 seconds to 3.6 seconds – a 60% improvement. Read more about the performance changes to the build system here.
System Health - IDE Speed
In the past, a pro-tip some developers used to do is to turn off Android Studio plugins such as Android NDK support to improve performance. While there is nothing wrong with disabling plugins to remove extra menus or options that you don't need, we removed some unnecessary performance hotspots for the Android NDK support that impacted overall IDE speed.
System Health - Lint Code Analysis
Android Lint is a code analysis framework in Android Studio that helps identify common programming mistakes. However, we learned from several user reports that Lint could be too slow—especially when running in batch analysis mode on large projects. After some digging, we found and fixed several large memory leaks, leading to a roughly 2x speedup in Lint performance. We also published a profiling tool that can help identify bottlenecks in individual Lint checks. Read more about the analysis and tool here.
System Health - I/O File Access for Windows
Many users of Android Studio use Microsoft Windows. Over time, we received a range of reports from users on this platform that build times and installation speeds were increasingly getting slower. After investigating the problem during Project Marble, we realized that recent anti-virus programs included Android Studio build and installation directories as active scan targets. Since these folders have many small files created and removed over time, the I/O and CPU are partially taxed and consequently impacts the overall build/sync performance of Android Studio.
Google Internal Data, 2.2GHz quad-core Intel Core i7, April 2019
System Health Notification - Anti-virus Check
System Health - Emulator CPU Usage
Many app developers enjoy the fast and responsive emulator which has had dramatic performance improvements in the last few years. However, we heard from you that the Android Emulator seems to take an inordinate amount of CPU cycles and triggers the cooling fans on laptops even when the emulator is idle in the background. After investigation and measurement, we found that Google Play Services and related services were aggressively running in the background because by default the emulator was set to AC charging instead of battery discharging. We switched the default to battery discharging, and background CPU usage declined by more than 3x. This change is just of the many optimizations we made to the Android Emulator during Project Marble. Learn more about the Android Emulator and Project Marble here.
Google Internal Data on Apple MacBook Pro (15” 2016), Emulator: Pixel 3 API 28
Feature Polish - Apply Changes
Being able to quickly edit and see code changes you have made without restarting your app is great for app development. Two years ago, the Instant Run feature was our attempt to enable this flow, but it ultimately fell short of expectations. During the Project Marble time period, we re-architectured and implemented from the ground-up a more practical approach in Android Studio 3.5 called Apply Changes. Apply Changes uses platform-specific APIs from Android Oreo and higher to ensure reliable and consistent behavior; unlike Instant Run, Apply Changes does not modify your APK. To support the changes, we re-architected the entire deployment pipeline to improve deployment speed, and also tweaked the run and deployment toolbar buttons for a more streamlined experience. Learn more about the architecture behind Apply Changes here.
Apply Changes Buttons
Feature Polish - Gradle Sync
A recent and annoying pain point in Android Studio is to have your project unexpectedly trigger red symbols across your app code, especially when re-opening your project. The Gradle build system retains a cache of all the dependencies in your home directory that allows the IDE to quickly sync without re-downloading new artifacts. The root cause for many of the recent incidents of red symbols appearing is that in a recent Gradle change, these caches were periodically deleted to save hard drive space. The IDE was unaware of the discrepancy and consequently generated red symbols for missing dependencies. Starting with Android Studio 3.5, we now have the conditional logic to check for this state. We certainly have more we can do in this area, but this is just one example of the types of issues we addressed for project sync during Project Marble.
Feature Polish - Project Upgrades
Ideally, the Android Studio team would like you to be on the latest version of the IDE since this is where the team does active feature development, bug fixing and performance improvements. We know that upgrading your Android Studio is not a seamless process as it should be with many issues revolving around fixing gradle plugin errors. With Android Studio 3.5, we have updated the user experience on output windows, pop-ups and dialog boxes to help clarify when you actually need to upgrade, plus we made more sync & build upgrade errors more actionable.
From a recent developer survey, we heard that many developers upgrade the Android Studio IDE and the Gradle plugin at the same time. As of the last several releases, the IDE and your gradle plugin can actually be updated independently. This means if you want the latest build system speed and correctness improvements, you can upgrade your Gradle plugin, but you can also wait until you're ready. Whether or not you upgrade you Gradle plugin at the same time as the IDE, we encourage you to be on the latest release of Android Studio 3.5 to start using all the enhancements from Project Marble.
Feature Polish - Layout Editor
Based on user research on the layout editor and input from you, we know that there are several performance and error-prone usability issues that make editing XML the only path forward, especially when working with ConstraintLayout. To address the general usability of the layout editor, we refined a wide range of interactions from constraint selection and deletion, to better device preview resizing. While XML code editing is still a click away, we hope you can see that these interaction refinements can be a big productivity boost when creating and editing layouts in Android Studio. Learn more about the full range of layout editor changes here.
Layout Editor Before - Android Studio 3.4 (left) and Layout Editor After - Android Studio 3.5 (right)
Feature Polish - Data Binding
During Project Marble, we also took a look at long standing issues with data binding. From a performance perspective, we found that creating data binding expressions in XML files would lead to severe hangs in the code editor. After fixing this issue we also improved code completion, navigation, and refactoring.
Feature Polish - App Deployment Flow
We streamlined the deployment flow during Project Marble, by adding a new dropdown to easily see and change the device you intend to deploy to and a new menu item to deploy to multiple devices.
App Deployment User Flow
Feature Polish - C++ Improvements
C++ project support was also a focus area during Project Marble. CMake builds are now up to 25% faster for large projects because the IDE now invokes parallel Ninja targets. Additionally, you will find an improved single build variant user interface panel that allows you to specify ABI targets separately.. And lastly, Android Studio 3.5 allows you to use multiple versions of the Android NDK side-by-side in your build.gradle file. This should allow you to have more reproducible builds and mitigate incompatibilities between NDK versions and the Android gradle plugin.
Single Variant Selection by ABI
Feature Polish - Intellij Platform Update
This release of the Android Studio includes the features and quality enhancements of the 2019.1 Intellij platform release. The 2019.1 Intellij updates has a range of improvements from custom themes to better version control system integration.
Feature Polish - Conditional Delivery for Dynamic Feature Support
Android Studio 3.5 enhances app bundle feature support with the addition of conditional delivery features for your app bundle. Conditional delivery allows you to set certain device configuration requirements for dynamic feature modules to be downloaded automatically during app install. You can set conditional delivery based on hardware features such as OpenGL versions, support for Augmented Reality, or you set conditions based on API level and user country.
Module Selection for Conditional Delivery
Feature Polish - Emulator Foldables & Pixel Device Support
This release of the IDE includes the Android Emulator skins for Pixel 3a and Pixel 3a XL. Additionally, the Android Studio supports the creation of foldable Android Virtual Devices.
Android Emulator - Foldable Support
Feature Polish - Chrome OS Support
Android Studio 3.5 is now officially supported on Chrome OS 75 and higher on high-end x86 based Chromebooks. During Project Marble we refined a few usability issues, and now have an installer for Android Studio and support app deployment to external USB connected Android devices. Learn more how to setup the IDE on Chrome OS here.
Android Studio on Chrome OS
To recap, Android Studio 3.5 has hundreds of bug fixes and notable changes in these core areas:
System Health
Feature Polish
Check our the Android Studio preview release notes page for more details and read about deep dives into several areas of Project Marble in the following Medium blog posts:
Opt-In & Feedback
The specific areas and the approach we took to optimize Android Studio for Project Marble were all based on your feedback and metrics data. The aggregate metrics you can opt-in to inside of Android Studio allow us to figure out if there are broader problems in the product for all users, and the data also allows the team to prioritize feature work appropriately. There are are a couple pathways to help us build better insights. At a baseline, you can opt-in to metrics, by going to Preferences /Settings → Appearance & Behavior → Data Sharing.
IDE Data Sharing
Additionally, throughout the year, you might see user sentiment emojis in the bottom corner of the IDE. Those icons are a lightweight way to inform the Android Studio team on how things are going and to give us in-context feedback, and the fastest way to log a bug and send to the team.
IDE User Feedback
Getting Started
Download
Download the beta version of Android Studio 3.5 from the download page. If you are using a previous release of Android Studio, you can simply update to the latest version of Android Studio. If you want to maintain a stable version of Android Studio, you can run the stable release version and beta release versions of Android Studio at the same time. Learn more.
To use the mentioned Android Emulator features make sure you are running at least Android Emulator v29.0.6 downloaded via the Android Studio SDK Manager.
As mentioned above, we appreciate any feedback on things you like, and issues or features you would like to see. If you find a bug or issue, feel free to file an issue. Follow us -- the Android Studio development team ‐ on Twitter and on Medium.
After nearly six months of development, Android Studio 3.4 is ready to download today on the stable release channel. This is a milestone release of the Project Marble effort from the Android Studio team. Project Marble is our focus on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. On top of many performance improvements and bug fixes we made in Android Studio 3.4, we are excited to release a small but focused set of new features that address core developer workflows for app building & resource management.
Part of the effort of Project Marble is to address user facing issues in core features in the IDE. At the top of the list of issues for Android Studio 3.4 is an updated Project Structure Dialog (PSD) which is a revamped user interface to manage dependencies in your app project Gradle build files. In another build-related change, R8 replaces Proguard as the default code shrinker and obfuscator. To aid app design, we incorporated your feedback to create a new app resource management tool to bulk import, preview, and manage resources for your project. Lastly, we are shipping an updated Android Emulator that takes less system resources, and also supports the Android Q Beta. Overall, these features are designed to make you more productive in your day-to-day app development workflow.
Alongside the stable release of Android Studio 3.4, we recently published in-depth blogs on how we are investigating & fixing a range of issues under the auspices of Project Marble. You should check them out as you download the latest update to Android Studio:
The development work for Project Marble is still on-going, but Android Studio 3.4 incorporates productivity features and over 300 bug & stability enhancements that you do not want to miss. Watch and read below for some of the notable changes and enhancements that you will find in Android Studio 3.4.
Resource Manager
Jetpack Import Intentions
Layout Editor Properties Panel
Project Structure Dialogue
Android Emulator - Pixel 3 XL Emulator Skin
To recap, Android Studio 3.4 includes these new enhancements & features:
Develop
Build
Test
Check out the Android Studio release notes, Android Gradle plugin release notes, and the Android Emulator release notes for more details.
Download the latest version of Android Studio 3.4 from the download page. If you are using a previous release of Android Studio, you can simply update to the latest version of Android Studio. If you want to maintain a stable version of Android Studio, you can run the stable release version and canary release versions of Android Studio at the same time. Learn more.
To use the mentioned Android Emulator features make sure you are running at least Android Emulator v28.0.22 downloaded via the Android Studio SDK Manager.
We appreciate any feedback on things you like, and issues or features you would like to see. If you find a bug or issue, feel free to file an issue. Follow us -- the Android Studio development team ‐ on Twitter and on Medium.
Posted by Sam Spencer, Technical Program Manager, Google Play
The Android Ice Cream Sandwich (ICS) platform is seven years old and the active device count has been below 1% for some time. Consequently, we are deprecating support for ICS in future releases of Google Play services. For devices running ICS, the Google Play Store will no longer update Play Services APK beyond version 14.7.99.
What does this mean as an Application developer:
The Google Play services SDK contains the interfaces to the functionality provided by the Google Play services APK, running as background services. The functionality required by the current, released SDK versions is already present on ICS devices with Google Play services and will continue to work without change.
With the SDK version changes earlier this year, each library can be independently released and may update its own minSdkVersion. Individual libraries are not required to change based on this deprecation. Newer SDK components may continue to support API levels 14 and 15 but many will update to require the higher API level. For applications that support API level 16 or greater, you will not need to make any changes to your build. For applications that support API levels 14 or 15, you may continue to build and publish your app to devices running ICS, but you will encounter build errors when updating to newer SDK versions. The error will look like this:
Error:Execution failed for task ':app:processDebugManifest'. > Manifest merger failed : uses-sdk:minSdkVersion 14 cannot be smaller than version 16 declared in library [com.google.android.gms:play-services-FOO:16.X.YY] Suggestion: use tools:overrideLibrary="com.google.android.gms:play_services" to force usage
Unfortunately, the stated suggestion will not help you successfully run your app on older devices. In order to use the newer SDK, you will need to use one of the following options:
1. Target API level 16 as the minimum supported API level.
This is the recommended course of action. To discontinue support for API levels that will no longer receive Google Play services updates, simply increase the minSdkVersion value in your app's build.gradle to at least 16. If you update your app in this way and publish it to the Play Store, users of devices with less than that level of support will not be able to see or download the update. However, they will still be able to download and use the most recently published version of the app that does target their device.
A very small percentage of all Android devices are using API levels less than 16. You can read more about the current distribution of Android devices. We believe that many of these old devices are not actively being used.
If your app still has a significant number of users on older devices, you can use multiple APK support in Google Play to deliver an APK that uses Google Play services 14.7.99. This is described below.
2. Build multiple APKs to support devices with an API level less than 16.
Along with some configuration and code management, you can build multiple APKs that support different minimum API levels, with different versions of Google Play services. You can accomplish this with build variants in Gradle. First, define build flavors for legacy and newer versions of your app. For example, in your build.gradle, define two different product flavors, with two different compile dependencies for the stand-in example play-services-FOO component:
productFlavors { legacy { minSdkVersion 14 versionCode 1401 // Min API level 14, v01 } current { minSdkVersion 16 versionCode 1601 // Min API level 16, v01 } } dependencies { legacyCompile 'com.google.android.gms:play-services-FOO:16.0.0' currentCompile 'com.google.android.gms:play-services-FOO:17.0.0' }
In the above situation, there are two product flavors being built against two different versions of play-services-FOO. This will work fine if only APIs are called that are available in the 16.0.0 library. If you need to call newer APIs made available with 17.0.0, you will have to create your own compatibility library for the newer API calls so that they are only built into the version of the application that can use them:
After building a release APK for each flavor, you then publish them both to the Play Store, and the device will update with the most appropriate version for that device. Read more about multiple APK support in the Play Store.
Today, at the Computer History Museum in Mountain View, CA, we kicked off the Android Dev Summit, taking a look back at the last 10 years of Android and then jumping into some important new features for Android developers. Here's a look at some of the things we shared!
As early as Android 1.6, Android and our partners have contemplated different screen sizes and densities, enabling the platform to power a broad category of form factors and new experiences like Android TV, Android Auto, Wear OS and even Android apps on Chromebooks. Phone screens are an area where Android partners set the bar, introducing "phablets" when phone screens were small. Fast forward to today, when a phablet is... just a phone, a standard size users have come to love.
Now we see a Android device makers creating a new category: Foldables. Taking advantage of new flexible display technology, the screen can literally bend and fold.
There are two variants broadly speaking: two-screen devices and one-screen devices. When folded, foldables look like phones, fitting in your pocket or purse. When unfolded, their defining feature is what we call screen continuity. For example, start a video with the folded smaller screen - and later you can sit down and unfold the device to get a larger tablet-sized screen for a beautiful, immersive experience. As you unfold, the app seamlessly transfers to the bigger screen without missing a beat. We're optimizing Android for this new form factor. And, making changes to help developers everywhere take advantage of the possibilities this creates for amazing new experiences, new ways to engage and delight your users. Tune in to the Foldables session at Dev Summit this week to learn more. Expect to see Foldables coming from several Android manufacturers, including one Samsung previewed today and plans to offer next year.
We made Kotlin a first class language on Android in 2017. This month we had over 118,000 new projects using Kotlin started in Android Studio - from those users who opt in to share metrics. That's a 10X increase from last year. It's become the fastest growing language in terms of growth of number of contributors on GitHub, and voted the #2 most loved language on Stack Overflow. In our surveys, the more developers use Kotlin, the higher their satisfaction.
Last week, JetBrains released the latest version of Kotlin, 1.3, which brings new language features, APIs, bug fixes, and performance improvements:
All of these new features of Kotlin 1.3 will be integrated into the Kotlin-specific APIs that we provide–a majority of which are through KTX extensions as part of Jetpack.
At Google I/O we announced Jetpack, the next generation of tools and Android APIs to accelerate Android application development. Jetpack builds on the foundations laid out by Support Library and Architecture. Already, 80% of top 1,000 apps and games are using one of the new Jetpack libraries in production.
This summer we moved AndroidX - Jetpack's evolution of the original Android Support Library - to public AOSP. This means you can see features and bug fixes implemented in real-time, and contribute to any of the AndroidX libraries. You can learn more about contributing here.
We've been working to get as much feedback and refinement as possible on two new Architecture Component libraries: Navigation and Work Manager, and we plan to move both to Beta this month. The Navigation Architecture Component offers a simplified way to implement Android's navigation principles in your application, using a single Activity. Plus, the new Navigation Editor in Android Studio creates and edits your navigation architecture. This eliminates navigation boilerplate, gives you atomic navigation operations, easier animated transitions and more. WorkManager makes it easy to perform background tasks in the most efficient manner, choosing the most appropriate solution based on the application state and device API level.
Navigation Editor
We're also excited to see Android Slices move to public Search experiments! At I/O this year we introduced Slices, a new way to bring users to your app. Slices are like a mini snippet of your app, where you can surface content and actions. You can book a flight, play a video, or call a ride. Slices is another example where we want to be open very early, but we want to take the time to get it right. We're moving into public EAP this month with Doist, Kayak and others. We'll run experiments surfacing Slices in Google search results. To learn more, there's also a session today at Dev Summit with more info and best practices.
Android Studio is our official IDE for Android development. We asked where do you spend the most time? When we gather data from Android Studio's opted-in users we see that build time are getting faster with every release, sometimes as fast as 20%, but we also see build time getting slower and slower over time. So, how can both things be true? We've been digging in hard to understand.
It turns out build is a pretty complicated ecosystem. Developer choices makes a huge difference. Our developers are using a very broad (and growing) combination of OSes, custom plug-ins, annotation processors, languages. All of these can significantly affect times. In one case, a plugin some users like to add was silently slowing build speeds by up to 45%. Learning this, we realized we need build profiling and analysis tools so you can easily understand what's slowing your build down. We're also investing more in our own plugins to accelerate performance to make sure we continue to improve the performance of core build.
Android Studio 3.3 launches beta 3 today. In coming releases expect to see a strong focus on quality and fundamentals: reducing the number of crashes and hangs, optimizing memory usage, and fixing user-impacting bugs. We also announced today that we're making Android Studio an officially supported IDE on Chrome OS early next year; learn more here.
App sizes have grown dramatically, up 5x since 2012. But larger apps have downsides: lower install conversion rates, lower update rates, and higher uninstalls. This is why we built the Android App Bundle, the new publishing format that serves only the code and resources a user needs to run your app on their specific device; on average apps see 35% size savings compared to a universal APK. The app bundle also saves you time and effort with each release since you don't need to use incomplete solutions like multi-APK. Android Studio 3.2 brought full IDE support of app bundles, and there are now thousands of app bundles in production totaling billions of installs, including Google's apps like YouTube, Google Maps, Google Photos, and Google News.
The app bundle now supports uncompressed native libraries; with no additional developer work needed, the app bundle now makes apps using native libraries an average of 8% smaller to download and 16% smaller on disk on M+ devices.
Once you switch to the app bundle you can also start modularizing your app. With dynamic feature modules, you can load any app functionality on demand instead of at install time. You don't need to keep big features that are only used once, on every single device forever; dynamic features can be installed and uninstalled dynamically when your app requests them.
We've heard that you'd like more controls to ensure that users are running the latest and greatest version of your app. To address this, we're launching an In-app Updates API. We're testing the API with early access partners and will be launching it to all developers soon.
You'll have two options with this API; the first is a full-screen experience for critical updates when you expect the user to wait for the update to be applied immediately. The second option is a flexible update, which means the user can keep using the app while the update is downloaded. You can completely customize the update flow so it feels like part of your app.
We're also making instant apps easier than ever to adopt. We recently made using web URLs optional, enabling you to take your existing play store deep link traffic and send users to your instant experience if it's available. Additionally, we've raised the instant app size limit to 10MB for the Try Now button on the Play Store and web banners to make it even easier to adopt.
In the Android Studio 3.3 beta, you can now build an instant-enabled app bundle. This means that you can now build and deploy both your Instant and installed experiences from a single Android Studio project, and include them in a single Android App Bundle. You only have to upload just ONE artifact for both instant and installed app.
As developers, your feedback has been critical in shaping these investment areas; you are part of how we work, from early ideas, to EAPs and canaries, Beta, and iterating after launch. We hope you join us for the next two days whether you're watching the 30+ sessions on the livestream, joining social, or with us in-person in Mountain View. From the team, a sincere thank you for all your thoughtful feedback and contributions. We hope you enjoy Android Dev Summit.
Today, Android Studio 3.2 is available for download. Android Studio 3.2 is the best way for app developers to cut into the latest Android 9 Pie release and build the new Android App bundle. Since announcing this update of Android Studio at Google I/O '18, we have refined and polished 20+ new features and focused our efforts on improving the quality for this stable release of Android Studio 3.2.
Every developer should use Android Studio 3.2 to transition to using an Android App Bundle, the new app publishing format. With very minimal work, you can generate an app bundle with Android Studio. Once you upload your app bundle to Google Play you can distribute smaller, optimized apps to your users. Early adopters have already seen between 11% - 64% in app size savings with app bundles over the legacy APK app size.
Another feature you do not want to miss is the Energy Profiler. This new profiler gives you a set of tools that will help you diagnose and improve the energy impact of your app. Better device battery life is one of the top most user requests, and with the Energy Profiler in Android Studio 3.2, you can do your part in improving device battery life by making sure your app is using the right amount of energy at the right time.
Lastly, you should also check out the new Android Emulator Snapshots feature. By using this feature, you can quickly take a snapshot of the current state of your emulator which includes the current state of the screen, apps, and settings. You can resume or boot into your emulator snapshot in under 2 seconds. For any app developer looking for super- fast boot times, or seeking to run tests in a predictable Android environment, Android Emulator Snapshots is a game changing feature for app development
On top of these major features, there are 20 new features plus many under-the-hood quality refinements in Android Studio 3.2. By using Android Studio 3.2, you can also develop for the latest technologies ranging from Android Jetpack, to the latest in Google Artificial Intelligence (AI) APIs with Android Slices.
Thank you to those who gave your early feedback on both the canary and beta releases. Your feedback helped us improve the quality and features in Android Studio 3.2. If you are ready for the next stable release, and want to use a new set of productivity features, Android Studio 3.2 is ready to download for you to get started.
Below is a full list of new features in Android Studio 3.2, organized by key developer flows.
Slices Provider Template
android.useAndroidX=true
gradle.properties
Build Android App Bundle
Android Emulator Snapshots
Energy Profiler
startMethodTracing(String tracePath)
stopMethodTracing()
To recap, the latest canary of Android Studio 3.2 includes these new major features:
Optimize
Check out the release notes for more details.
Download the latest version of Android Studio 3.2 from the download page. If you are using a previous canary release of Android Studio, make sure you update to Android Studio Canary 14 or higher. If you want to maintain a stable version of Android Studio, you can run the stable release version and canary release versions of Android Studio at the same time. Learn more.
To use the mentioned Android Emulator features make sure you are running at least Android Emulator v28.0.7+ downloaded via the Android Studio SDK Manager.
We appreciate any feedback on things you like, and issues or features you would like to see. Please note, to maintain high product quality, a couple features (e.g. Navigation Editor) you saw in earlier release channels are not enabled by default in the stable release channel. If you find a bug or issue, feel free to file an issue. Connect with us -- the Android Studio development team ‐ on our Google+ page or on Twitter.
