Tag Archives: Marshmallow

Marshmallow and User Data

Posted by Joanna Smith, Developer Advocate and Giles Hogben, Google Privacy Team

Marshmallow introduced several changes that were designed to help your app look after user data. The goal was to make it easier for developers to do the right thing. So as Android 6.0, Marshmallow, gains traction, we challenge you to do just that.

This post highlights the key considerations for user trust when it comes to runtime permissions and hardware identifiers, and points you to new best practices documentation to clarify what to aim for in your own app.

Permission Changes

With Marshmallow, permissions have moved from install-time to runtime. This is a mandatory change for SDK 23+, meaning it will affect all developers and all applications targeting Android 6.0. Your app will need to be updated anyway, so your challenge is to do so thoughtfully.

Runtime permissions mean that your app can now request access to sensitive information in the context that it will be used. This gives you a chance to explain the need for the permission, without scaring users with a long list of requests.

Permissions are also now organized into groups, so that users can make an informed decision without needing to understand technical jargon. By allowing your users to make a decision, they may decide not to grant a permission or to revoke a previously-granted permission. So, your app needs to be thoughtful when handling API calls requiring permissions that may have been denied, and about building in graceful failure-handling so that your users can still interact with the rest of your app.

Identifier Changes

The other aspect of user trust is doing the right thing with user data. With Marshmallow, we are turning off access to some kinds of data in order to direct developers down this path.

Most notably, Local WiFi and Bluetooth MAC addresses are no longer available. The getMacAddress() method of a WifiInfo object and the BluetoothAdapter.getDefaultAdapter().getAddress() method will both return 02:00:00:00:00:00 from now on.

However, Google Play Services now provides Instance IDs, which identify an application instance running on a device. Instance IDs provide a reliable alternative to non-resettable, device-scoped hardware IDs, as they will not persist across a factory reset and are scoped to an app instance. See the Google Developer's What is Instance ID? help article for more information.

What’s Next

User trust depends largely on what users see and how they feel. Mishandling permissions and identifiers increases the risk of unwanted/unintended tracking, and can result in users feeling that your app doesn’t actually care about the user. So to help you get it right, we’ve created new documentation that should enable developers to be certain that their app is doing the right thing for their users.

So happy developing! May your apps make users happy, and may your reviews reflect that. :)

Android Developer Story: Music app developer DJIT builds higher quality experiences and a successful businesses on Android

Posted by Lily Sheringham, Google Play team

Paris-based DJiT is the creator of edjing, one of the most downloaded DJ apps in the world, it now has more than 60 million downloads and a presence in 182 countries. Following their launch on Android, the platform became the largest contributor of business growth, with 50 percent of total revenue and more than 70 percent of new downloads coming from their Android users.

Hear from Jean-Baptiste Hironde, CEO & Co-founder, Séverine Payet, Marketing Manager, and Damien Delépine, Android Software Engineer, to learn how DJit improved latency on new Android Marshmallow, as well as leveraged other Android and Google Play features to create higher quality apps.



Find out more about building great audio apps and how to find success on Google Play.

S’more to love with the new Nexus phones available in India today

We introduced Android as an open platform that anyone can build on, and today there are 4,000+ Android devices in all shapes and sizes. Android’s diversity is why it’s become the most popular mobile platform in the world, and the latest version, Marshmallow, takes Android to a new level of performance.


With all the Android devices out there, we also want to show off how great an Android device can truly be—which is why we started our Nexus program. Today we’re introducing the latest Nexus treats to India both running Marshmallow, sweetened by amazing apps and sandwiched by some cutting-edge hardware.


Nexus 6P is the first full metal-body Nexus phone. Built by Huawei, this 5.7” phone is crafted from aeronautical-grade aluminum, with a powerful processor, a 12 MP camera and a USB Type-C port for fast charging. The Nexus 6P starts at Rs. 39,999.


You’re not the only one who misses your Nexus 5. We’ve brought it back with the new Nexus 5X, giving you great performance and a beautiful 5.2” screen, in a compact and light package. The Nexus 5X starts at Rs 31,990.


With Android Marshmallow, the new Nexus phones offer Now on Tap to help you get fast answers when you need them, fingerprint support for quick and secure access, more control over app permission, and Doze to help your battery work smarter.


Screen Shot 2015-10-09 at 2.38.37 AM.png


Starting today in India, you can now pre-order the new Nexus phones from leading e-tailers Amazon, Flipkart and also offline at major retail chains such as Reliance, Croma, The Mobile Store and many more.

Posted by David Shapero, Global Director of Chrome and Android Marketing

Android 6.0 Marshmallow coming to devices soon

Posted by, Dave Burke, VP of Engineering, Android

Starting next week, Android 6.0 Marshmallow will begin rolling out to supported Nexus devices around the world, including Nexus 5, Nexus 6, Nexus 7 (2013), Nexus 9, Nexus Player, and Android One. At the same time, we’ll be pushing the Android 6.0 source to the Android Open Source Project (AOSP), which marks the official beginning of public availability.

Today we also introduced two great new Nexus devices that will be among the first to run the Android 6.0 Marshmallow platform. These devices let your apps use the latest platform features and take advantage of the latest hardware optimizations from our partners. Let’s take a look at how to make sure your apps look great on these new devices.

Introducing Nexus 5X and Nexus 6P

Nexus 5X
Nexus 6P

The Nexus 5X is built in partnership with LG. It’s equipped with a 5.2-inch FHD LCD 1080p display, a Snapdragon™ 808 processor (1.8 GHz hexa-core, 64-bit), and a 12.3 MP rear camera. Offering top-line performance in a compact, lightweight device.

The Nexus 6P, built in partnership with Huawei, has a 5.7-inch WQHD AMOLED display, Snapdragon™ 810 v2.1 processor (2.0 GHz octa-core 64-bit), front-facing stereo speakers, and a 12.3 MP rear camera, all housed in a diamond-cut aluminum body.

Both devices have USB Type-C ports and fingerprint sensors, and include the latest hardware features for Android, such as: Android Sensor Hub, low-power Wi-Fi scanning with channel selection, batching, and BSSID hotlists, Bluetooth 4.2 with ultra low-power BLE notifications, and more.

Get your apps ready

Take some time to make sure your apps and games are ready to give your users the best mobile experience on these devices.

Check your assets

Resolution Screen size Density
Nexus 5x 1920 x 1080 px (730 x 410 dp) normal 420 dpi
Nexus 6P 2560 x 1440 px (730 x 410 dp) normal 560 dpi

Nexus 5X has a quantized density of 420 dpi, which falls in between the xhdpi and xxhdpi primary density buckets. Nexus 6P has a density of 560 dpi, which falls in between the xxhdpi and xxxhdpi buckets. The platform will scale down any assets from a higher resolution bucket, but if those aren’t available, then it will scale up the assets from a lower-density bucket.

For best appearance in the launcher, we recommend that you provide at least an xxxhdpi app icon because devices can display large app icons on the launcher.

For the rest of your assets, you can consider using vector assets or optionally add versions for the next-higher density bucket. This provides a sharper visual experience, but does increase apk size, so you should make an appropriate decision for your app.

Make sure you are not filtered on Google Play

If you are using the <compatible-screens>: element in your AndroidManifest.xml file, you should stop using it because it’s not scalable to re-compile and publish your app each time new devices come out. If you must use it, make sure to update your manifest to add a new configuration for Nexus 5X, since it uses a new density bucket (420). Otherwise, your app may be filtered from Google Play on these devices.

Wrapping up M Developer Preview

After three preview releases, and with the final OTA coming soon, it’s time to wrap up the Android M Developer Preview. The feedback you’ve provided has helped make Android 6.0 a great platform for apps and games. Developers in more than 200 countries have been using the Developer Preview to get their apps ready for Android 6.0 Marshmallow users everywhere.

More developer resources

If you haven’t taken a look at Android 6.0 Marshmallow yet, visit developer.android.com/mm for complete information about about what’s new for developers and important changes to plan for in your apps — runtime permissions, Doze and App Standby idle modes, Auto Backup for Apps, fingerprint support, and others.

We’ve also produced a playlist of developer videos to help you get the most out of all the new features in Android 6.0 Marshmallow. Check it out below.

Final testing and updates

Now is the time to finish up testing and prepare for publishing. You can use the Developer Preview 3 system images for final testing until early October. After the Android 6.0 public release, you’ll be able to download final images from the Nexus factory images page, and final emulator images from Android Studio.

Reminder: Devices flashed with an M Developer Preview build won’t receive the Android 6.0 update automatically. You’ll need to manually flash those devices to a public released image first.

Upload your apps to Google Play

When your apps are ready, you can update them to Google Play via the Developer Console on all release channels (Alpha, Beta & Production). For apps that target API level 23, Google Play will provide the new optimized download and autoupdate flow based on the runtime permissions model in Android 6.0. Give it a try!

To make sure that your updated app runs well on Android 6.0 Marshmallow and older versions, we recommend that you use the newly improved beta testing feature on Google Play to get early feedback. You can then do a staged rollout as you release the new version to all users.

What’s next?

In mid-October, we’ll be turning down the M Developer Preview community and the M Developer Preview issue tracker. If the you filed bugs against the preview that you want to leave open against the Android 6.0 final builds, you can file a new issue in the AOSP issue tracker.

Thanks to everyone who participated in the Android M Developer Preview. Let us know how this year’s preview met your needs by taking a short survey. Your feedback helps shape our future releases.


New Android Marshmallow sample apps

Posted by Rich Hyndman, Developer Advocate

Three new Android Marshmallow sample applications have gone live this week. As usual they are available directly from the Google Samples repository on GitHub or through the Android Studio samples browser.

Android Direct Share Sample



Direct Share is a new feature in Android Marshmallow that provides APIs to make sharing more intuitive and quick for users. Direct Share allows users to share content to targets, such as contacts, within other apps. For example, the direct share target might launch an activity in a social network app, which lets the user share content directly to a specific friend in that app.

This sample is a dummy messaging app, and just like any other messaging apps, it receives intents for sharing a plain text. It demonstrates how to show some options directly in the list of share intent candidates. When a user shares some text from another app, this sample app will be listed as an option. Using the Direct Share feature, this app also shows some of contacts directly in the chooser dialog.

To enable Direct Share, apps need to implement a Service extending ChooserTargetService. Override the method onGetChooserTargets() and return a list of Direct Share options.

In your AndroidManifest.xml, add a meta-data tag in your Activity that receives the Intent. Specify android:name as android.service.chooser.chooser_target_service, and point the android:value to the Service.

Android MidiSynth Sample

Android 6.0 introduces new support for MIDI. This sample demonstrates how to use the MIDI API to receive and play MIDI messages coming from an attached input device (MIDI keyboard).

The Android MIDI API (android.media.midi) allows developers to connect a MIDI device to an Android device and process MIDI messages coming from it.

This sample demonstrates some basic features of the MIDI API, such as:

  • Enumeration of currently available devices (including name, vendor, capabilities, etc)
  • Notification when MIDI devices are plugged in or unplugged
  • Receiving and processing MIDI messages

It also contains a simple implementation of an oscillator and note playback.

Android MidiScope Sample

A sample demonstrating how to use the MIDI API to receive and process MIDI signals coming from an attached device.

The Android MIDI API (android.media.midi) allows developers to connect a MIDI device to Android and process MIDI signals coming from it. This sample demonstrates some basic features of the MIDI API, such as enumeration of currently available devices (Information includes name, vendor, capabilities, etc), notification when MIDI devices are plugged in or unplugged, and receiving MIDI signals. This sample simply shows all the received MIDI signals to the screen log and does not play any sound for them.

Check out a sample today and jumpstart your Android Marshmallow development.

Building better apps with Runtime Permissions

Posted by Ian Lake, Developer Advocate

Android devices do a lot, whether it is taking pictures, getting directions or making phone calls. With all of this functionality comes a large amount of very sensitive user data including contacts, calendar appointments, current location, and more. This sensitive information is protected by permissions, which each app must have before being able to access the data. Android 6.0 Marshmallow introduces one of the largest changes to the permissions model with the addition of runtime permissions, a new permission model that replaces the existing install time permissions model when you target API 23 and the app is running on an Android 6.0+ device.

Runtime permissions give your app the ability to control when and with what context you’ll ask for permissions. This means that users installing your app from Google Play will not be required to accept a list of permissions before installing your app, making it easy for users to get directly into your app. It also means that if your app adds new permissions, app updates will not be blocked until the user accepts the new permissions. Instead, your app can ask for the newly added runtime permissions as needed.

Finding the right time to ask for runtime permissions has an important impact on your app’s user experience. We’ve gathered a number of design patterns in our new Permission design guidelines including best practices around when to request permissions, how to explain why permissions are needed, and how to handle permissions being denied.

Ask up front for permissions that are obvious

In many cases, you can avoid permissions altogether by using the existing intents system to utilize other existing specialized apps rather than building a full experience within your app. An example of this is using ACTION_IMAGE_CAPTURE to start an existing camera app the user is familiar with rather than building your own camera experience. Learn more about permissions versus intents.

However, if you do need a runtime permission, there’s a number of tools to help you. Checking for whether your app has a permission is possible with ContextCompat.checkSelfPermission() (available as part of revision 23 of the support-v4 library for backward compatibility) and requesting permissions can be done with requestPermissions(), bringing up the system controlled permissions dialog to allow the user to grant you the requested permission(s) if you don’t already have them. Keep in mind that users can revoke permissions at any time through the system settings so you should always check permissions every time.

A special note should be made around shouldShowRequestPermissionRationale(). This method returns true if the user has denied your permission request at least once yet have not selected the ‘Don’t ask again’ option (which appears the second or later time the permission dialog appears). This gives you an opportunity to provide additional education around the feature and why you need the given permission. Learn more about explaining why the app needs permissions.

Read through the design guidelines and our developer guide for all of the details in getting your app ready for Android 6.0 and runtime permissions. Making it easy to install your app and providing context around accessing user’s sensitive data are key changes you can make to build better apps.