Posted by Raman Tenneti, AOSP Software Engineer and Ally Sillins, AOSP Program Manager
When we started the Android Open Source Project (AOSP) 10 years ago, we included some basic applications in the AOSP build for three main purposes:
However, as the Android ecosystem has matured over time, we've noticed a healthy growth of alternative applications - both as open source and proprietary implementations - developed by the developer community. These alternative applications are not only capable to serve the first two purposes, but often times showcase richer set of features demonstrating the power of Android. Late last year, we began to clean up these applications in AOSP to focus more effectively on the last purpose — their role to provide functionality to other Android applications as part of the platform.
To date, the following 3 apps have been cleaned up: Music, Calendar, and Calculator. See below for details on these updates. Going forward, you can expect to see similar efforts with the other applications in the AOSP repository.
As always, we're excited to hear your feedback on the developer website or through our AOSP forum.
AOSP's Music app can now playback music, one file at a time, and exposes itself as an intent handler for the android.media.browse.MediaBrowserService. The app has controls to play and pause, and a slider moving forward and backward. Features removed include: Music Icon, Artists, Albums, Songs, Playlists, Search, and Settings.
AOSP's Calendar app now exposes itself as an intent handler for the calendar events. New events cannot be created and existing events cannot be edited or deleted. The following features have been deleted: support for multiple accounts, reminders and settings. In addition, some features remain that are not needed for providing a part of the platform functionality: views for day, week, and month. This app may be further simplified in the future.
The calculator application is a standalone app, and does not function as part of the platform and hence has been removed from the AOSP build. However, the application will continue to exist as an open source project separately.
Posted by Vlad Radu, Product Manager and Nicholas Lativy, Software Engineer
The Google Play Developer API allows you to automate your in-app billing and app distribution workflows. At Google I/O ‘18, we introduced version 3 of the API, which allows you to transactionally start, manage, and halt staged releases on all tracks, through production, open testing, closed testing (including the new additional testing tracks), and internal testing.
In addition to these new features, version 3 also supports all the functionality of previous versions, improving and simplifying how you manage workflows. Starting December 1, 2019, versions 1 and 2 of the Google Play Developer API will no longer be available so you need to update to version 3 ahead of this date.
If you use the Google Play API client libraries (available for Java, Python, and other popular languages), we recommend upgrading to their latest versions, which already support version 3 of the API. In many cases, changing the version of the client library should be all that is necessary. However, you may also need to update specific code references to the version of the API in use - see examples in our samples repository.
Usage of the API can also be indirect, not by the app itself, but by a third-party plugin (e.g. a plugin for rolling out new releases). Many third-party plugins are already using version 3 of the API. If you use a plugin that does not support version 3, you will need to contact the maintainer.
Google Play Console has been displaying warnings since mid-May if we detected that your app was still using version 1 and version 2 endpoints. The message is based on all calls to the API in the last seven days and is refreshed daily. If you see this message, it means calls to the Publishing API version 1 or 2 are referencing your app.
If you currently use version 1 of the API, you may also need to link your API project to the Google Console before converting to version 3. Learn more about this process.
We hope you benefit from the new features of the Google Play Developer API and are looking forward to your continued feedback to help us improve the publishing experience on Google Play.
How useful did you find this blog post?
★ ★ ★ ★ ★
Posted by Wojtek Kaliciński, Developer Advocate, Android
Last year, we launched Android App Bundles and Google Play's Dynamic Delivery to introduce modular development, reduce app size and streamline the release process. Since then, we've seen developers quickly adopt this new app model in over 60,000 production apps. We've been excited to see developers experience significant app size savings and reductions in the time needed to manage each release, and have documented these benefits in case studies with Duolingo and redBus.
Thank you to everyone who took the time to give us feedback on our initial launch. We're always open to new ideas, and today, we're happy to announce some new improvements based on your suggestions:
When you adopt the Android App Bundle as the publishing format for your app, Google Play is able to optimize the installation by delivering only the language resources that match the device's system locales. If a user changes the system locale after the app is installed, Play automatically downloads the required resources.
Some developers choose to decouple the app's display language from the system locale by adding an in-app language switcher. With the latest release of the Play Core library (version 1.4.0), we're introducing a new additional languages API that makes it possible to build in-app language pickers while retaining the full benefits of smaller installs provided by using app bundles.
With the additional languages API, apps can now request the Play Store to install resources for a new language configuration on demand and immediately start using it.
The app can get a list of languages that are already installed using the SplitInstallManager#getInstalledLanguages() method.
SplitInstallManager#getInstalledLanguages()
val splitInstallManager = SplitInstallManagerFactory.create(context) val langs: Set<String> = splitInstallManager.installedLanguages
Requesting an additional language is similar to requesting an on demand module. You can do this by specifying a language in the request through SplitInstallRequest.Builder#addLanguage(java.util.Locale).
SplitInstallRequest.Builder#addLanguage(java.util.Locale)
val installRequestBuilder = SplitInstallRequest.newBuilder() installRequestBuilder.addLanguage(Locale.forLanguageTag("pl")) splitInstallManager.startInstall(installRequestBuilder.build())
The app can also monitor install success with callbacks and monitor the download state with a listener, just like when requesting an on demand module.
Remember to handle the SplitInstallSessionStatus.REQUIRES_USER_CONFIRMATION state. Please note that there was an API change in a recent Play Core release, which means you should use the new SplitInstallManager#startConfirmationDialogForResult() together with Activity#onActivityResult(). The previous method of using SplitInstallSessionState#resolutionIntent() with startIntentSender() has been deprecated.
SplitInstallSessionStatus.REQUIRES_USER_CONFIRMATION
SplitInstallManager#startConfirmationDialogForResult()
Activity#onActivityResult()
SplitInstallSessionState#resolutionIntent()
startIntentSender()
Check out the updated Play Core Library documentation for more information on how to access the newly installed language resources in your activity.
We've also updated our dynamic features sample on GitHub with the additional languages API, including how to store the user's language preference and apply it to your activities at startup.
Please note that while the additional languages API is now available to all developers, on demand modules are in a closed beta for the time being. You can experiment with on demand modules in your internal, open, and closed test tracks, while we work with our partners to make sure this feature is ready for production apps.
In Android Studio 3.3, we introduced a way to build app bundles that contain both the regular, installed version of your app as well as a Google Play Instant experience for modules marked with the dist:instant="true" attribute in their AndroidManifest.xml:
dist:instant="true"
AndroidManifest.xml
<manifest ... xmlns:dist="http://schemas.android.com/apk/distribution"> <dist:module dist:instant="true" /> ... </manifest>
Even though you could use a single project to generate the installed and instant versions of your app, up until now, developers were still required to use product flavors in order to build two separate app bundles and upload both to Play.
We're happy to announce that we have now removed this restriction. It's now possible to upload a single, unified app bundle artifact, containing modules enabled for the instant experience. This functionality is now available for everyone.
After you build an instant-enabled app bundle, upload it to any track on the Play Console, and you'll be able to select it when creating a new instant app release. This also means that the installed and instant versions of your app no longer need different version codes, which will simplify the release workflow.
You need to enable app signing by Google Play to publish your app using an Android App Bundle and automatically benefit from Dynamic Delivery optimizations. It is also a more secure way to manage your signing key, which we recommend to everyone, even if you want to keep publishing regular APKs for now.
Based on your feedback, we've revamped the sign-up flow for new apps to make it easier to initialize the key you want to use for signing your app.
Now developers can explicitly choose to upload their existing key without needing to upload a self-signed artifact first. You can also choose to start with a key generated by Google Play, so that the key used to locally sign your app bundle can become your upload key.
Read more about the new flow.
We have now added the ability to permanently uninstall dynamic feature modules that are included in your app's initial install.
This is a behavior change, which means you can now call the existing SplitInstallManager#deferredUninstall() API on modules that set onDemand="false". The module will be permanently uninstalled, even when the app is updated.
SplitInstallManager#deferredUninstall()
onDemand="false"
This opens up new possibilities for developers to further reduce the installed app size. For example, you can now uninstall a heavy sign-up module or any other onboarding content once the user completes it. If the user navigates to a section of your app that has been uninstalled, you can reinstall it using the standard on demand modules install API.
We hope you enjoy these improvements and test them out in your apps. Continue to share your feedback as we work to make these features even more useful for you!
Posted by Kacey Fahey, Developer Marketing, Google Play & Android
We're excited to host the Google Mobile Developer Day at Game Developers Conference 2019. We are taking this opportunity to share best practices and our plans to help your games businesses, which are fuelling incredible growth in the global mobile games market. According to Newzoo, mobile games revenue is projected to account for nearly 60% of global games revenue by 2021. The drivers of this growth come in many forms, including more developers building great games, new game styles blurring the lines of traditional genres, and the explosion of gaming in emerging markets - most notably in India.
Image Source: GamesIndustry.biz
To support your growth, Google is focused on improving the game development experience on Android. We are investing in tools to give you better insights into what is happening on devices, as well as in people and teams to address your feedback about the development process, graphics, multiplayer experiences, and more.
We have some great updates and new tools to improve game discovery and monetization on Google Play, which we also shared today during our Mobile Developer Day:
Pre-registration now in general availability
Starting today, we are launching pre-registration for general availability. Set up a pre-registration campaign in the Google Play Console and start marketing your games to build awareness before launch. Users who pre-register receive a notification at launch, which helps increase day one installs.
Google Play Instant gaining adoption
We have seen strong adoption of Google Play Instant with 3x growth in the number of instant games and 5x growth in the number of instant sessions over the last six months. Instant experiences allow players to tap the 'Try Now' button on your store listing page and go straight to a demo experience in a matter of seconds, without installing. Now, they're even easier to build with Cocos and Unity plug-ins and an expanded implementation partner program. Discover the latest updates on Google Play Instant.
Android App Bundles momentum and new large download size threshold
Over 60K apps and games on Google Play are now using the Android App Bundle publishing format, which is supported in Android Studio, Unity, and Cocos Creator. The app bundle uses Google Play's Dynamic Delivery to deliver a smaller, optimized APK containing only the resources needed for a specific device.
To better support high quality game experiences and reflect improved devices, we've also increased the size limit for APKs generated from app bundles to 150MB and raised the threshold for large download user warnings on the Google Play Store to 150MB, from 100MB.
Store listing experiments let you A/B test changes to your store listing on actual Play Store visitors. We recently rolled out improvements, introducing two new metrics - first time installers and D1 retained users - to more accurately reflect the performance of your store listings. These two new metrics are now reported with hourly intervals and are available via email notifications, letting you see results faster and track performance better.
Country targeted store listings allow you to tailor your app's store listing to appeal to users in different countries. You can customize the app title, icon, descriptions and graphic assets, allowing you to better appeal to users in specific target markets. For example, you can now tailor your store listing with different versions of the English language for users in India versus the United States.
Rewarded ads give players the choice to watch an advertisement in exchange for in-app items. With rewarded ads in Google Play, you can now create and manage rewarded ads through the Google Play Console. No additional SDK integrations are required.
We hope you try some of these new tools and keep sharing ideas so we can make Android and Google Play a better place to grow your business. We are committed to continue improving the platform and building tools that better serve the gaming community.
Get started today by visiting two new resources, a hub for developers interested in creating games on Android and games.withgoogle.com, for developers looking to connect and scale their business across Google. Many of these updates and resources come from community suggestions, so sign up for our monthly newsletter to stay informed.
Watch the session recordings and product updates shared during Google Mobile Developer Day.
Left to right: original icon, new icon (example), original icon in legacy mode
Posted by Jen Chai, Product Manager
Location data can deliver amazing, rich mobile experiences for users on Android such as finding a restaurant nearby, tracking the distance of a run, and getting turn-by-turn directions as you drive. Location is also one of the most sensitive types of personal information for a user. We want to give users simple, easy-to-understand controls for what data they are providing to apps, and yesterday, we announced in Android Q that we are giving users more control over location permissions. We are delighted by the innovative location experiences you provide to users through your apps, and we want to make this transition as straightforward for you as possible. This post dives deeper into the location permission changes in Q, what it may mean for your app, and how to get started with any updates needed.
Previously, a user had a single control to allow or deny an app access to device location, which covered location usage by the app both while it was in use and while it wasn't. Starting in Android Q, users have a new option to give an app access to location only when the app is being used; in other words, when the app is in the foreground. This means users will have a choice of three options for providing location to an app:
Some apps or features within an app may only need location while the app is being used. For example, if a feature allows a user to search for a restaurant nearby, the app only needs to understand the user's location when the user opens the app to search for a restaurant.
However, some apps may need location even when the app is not in use. For example, an app that automatically tracks the mileage you drive for tax filing, without requiring you to interact with the app.
The new location control allows users to decide when device location data is provided to an app and prevents an app from getting location data that it may not need. Users will see this new option in the same permissions dialog that is presented today when an app requests access to location. This permission can also be changed at any time for any app from Settings-> Location-> App permission.
We know these updates may impact your apps. We respect our developer community, and our goal is to approach any change like this very carefully. We want to support you as much as we can by (1) releasing developer-impacting features in the first Q Beta to give you as much time as possible to make any updates needed in your apps and (2) providing detailed information in follow-up posts like this one as well as in the developer guides and privacy checklist. Please let us know if there are ways we can make the guides more helpful!
If your app has a feature requiring "all the time" permission, you'll need to add the new ACCESS_BACKGROUND_LOCATION permission to your manifest file when you target Android Q. If your app targets Android 9 (API level 28) or lower, the ACCESS_BACKGROUND_LOCATION permission will be automatically added for you by the system if you request either ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION. A user can decide to provide or remove these location permissions at any time through Settings. To maintain a good user experience, design your app to gracefully handle when your app doesn't have background location permission or when it doesn't have any access to location.
ACCESS_BACKGROUND_LOCATION
ACCESS_FINE_LOCATION
ACCESS_COARSE_LOCATION
Users will also be more likely to grant the location permission if they clearly understand why your app needs it. Consider asking for the location permission from users in context, when the user is turning on or interacting with a feature that requires it, such as when they are searching for something nearby. In addition, only ask for the level of access required for that feature. In other words, don't ask for "all the time" permission if the feature only requires "while in use" permission.
To learn more, read the developer guide on how to handle the new location controls.
Posted by Ian Lake, Software Engineering Lead & Jisha Abubaker, Product Manager
Today we're happy to announce the stable release of the Android Jetpack Navigation component.
The Jetpack Navigation component's suite of libraries, tooling and guidance provides a robust, complete navigation framework, freeing you from the challenges of implementing navigation yourself and giving you certainty that all edge cases are handled correctly.
With the Jetpack Navigation component you can:
The Jetpack Navigation component adheres to the Principles of Navigation, providing consistent and predictable navigation no matter how simple or complex your app may be.
The Jetpack Navigation component provides a framework for in-app navigation that makes it possible to abstract away the implementation details, keeping your app code free of navigation boilerplate.
To get started with the Jetpack Navigation component in your project, add the Navigation artifacts available on Google's Maven repository in Java or Kotlin to your app's build.gradle file:
build.gradle
dependencies { def nav_version = 2.0.0 // Java implementation "androidx.navigation:navigation-fragment:$nav_version" implementation "androidx.navigation:navigation-ui:$nav_version" // Kotlin KTX implementation "androidx.navigation:navigation-fragment-ktx:$nav_version" implementation "androidx.navigation:navigation-ui-ktx:$nav_version" }
Note: If you have not yet migrated to androidx.*, the Jetpack Navigation stable component libraries are also available as android.arch.* artifacts in version 1.0.0.
navigation-runtime : This core library powers the navigation graph, which provides the structure of your in-app navigation: the screens or destinations that make up your app and the actions that link them. You can control how you navigate to destinations with a simple navigate() call. These destinations may be fragments, activities or custom destinations.
navigate()
navigation-fragment: This library builds upon navigation-runtime and provides out-of-the-box support for fragments as destinations. With this library, fragment transactions are now handled for you automatically.
navigation-ui: This library allows you to easily add navigation drawers, menus and bottom navigation to your app consistent with the Material Design guidelines.
Each of these libraries provide an Android KTX artifact with the -ktx suffix that builds upon the Java API, taking advantage of Kotlin-specific language features.
Available in Android Studio 3.3 and above, the Navigation Editor lets you visually create your navigation graph , allowing you to manage user journeys within your app.
With integration into the manifest merger tool, Android Studio can automatically generate the intent filters necessary to enable deep linking to a specific screen in your app. With this feature, you can associate URLs with any screen of your app by simply setting an attribute on the navigation destination.
Navigation often requires passing data from one screen to another. For example, your list screen may pass an item ID to a details screen. Many of the runtime exceptions during navigation have been attributed to a lack of type safety guarantees as you pass arguments. These exceptions are hard to replicate and debug. Learn how you can provide compile time type safety with the Safe Args Gradle Plugin.
Check out our brand new set of developer guides that encompass best practices to help you implement navigation correctly:
Here's what Emery Coxe, Android Lead @ HomeAway, has to say about the Jetpack Navigation component :
"The Navigation library is well-designed and fully configurable, allowing us to integrate the library according to our specific needs.
With the Navigation Library, we refactored our legacy navigation drawer to support a dynamic, runtime-based configuration using custom views. It allowed us to add / remove new screens to the top-level experience of our app without creating any interdependencies between discreetly packaged modules.
We were also able to get rid of all anti-patterns in our app around top-level navigation, removing explicit casts and hardcoded assumptions to instead rely directly on Navigation. This library is a fundamental component of modern Android development, and we intend to adopt it more broadly across our app moving forward.
Check out the migration guide and the developer guide to learn how you can get started using the Jetpack Navigation component in your app. We also offer a hands-on codelab and a sample app.
Also check out Google's Digital Wellbeing to see another real-world example of in-app navigation using the Android Jetpack Navigation component.
Please continue to tell us about your experience with the Navigation component. If you have specific feedback on features or if you run into any issues, please file a bug via one of the following links:
Platform
Android Studio
Google Play
Android Jetpack
Docs
News
