Posted by Fergus Hurley, Product Manager, Google Play
Millions of users rate and review your apps every day on Google Play. From feature requests to technical issues, ratings and reviews offer a wealth of information about what people like and dislike. Since 2013, you’ve been able to reply to reviews on Google Play, giving you a direct communication channel with your most engaged users. You've told us you value having this channel because it helps you iterate on user feedback faster on Android than other platforms. In the last few months, we’ve made a number of improvements in the Google Play Developer Console to help you better analyze and manage ratings and reviews so that you can improve your app experience and boost its rating.
Improvements to ratings and reviews
We recently revamped ratings and reviews with features you can now find on dedicated pages in the Developer Console:
The new ratings page in the Google Play Developer Console
See ratings over time: See how your rating changes daily, weekly, and monthly and easily spot any changes when you release a new version of your app.
Ratings breakdown: Break down your rating by country, language, device, app version, or Android version.
The new reviews page in the Google Play Developer Console
Review highlights: See common themes from what users say in reviews of your app – these are the same highlights that users see on the Play Store. Review highlights are shown when you have a high enough volume of reviews and are updated regularly to reflect the latest user experiences with your app.
Device metadata: See certain device data such as RAM, CPU, and screen size so you can more easily identify problems users are mentioning in user reviews and debug such issues.
Search review text: Search inside reviews to see what people are saying about a particular topic or keyword.
Replies & updates to reviews: When you reply to reviews, the user receives an email. Now, you can also opt-in to be emailed if the user updates their review or rating.
Learn from other developers on how to make the most of ratings and reviews
Photo Editor by Aviary is a photo editing app with a strong focus on simplicity and intuitive use. Ratings and reviews and other Android features allow Aviary to iterate on builds two to three times faster compared to other platforms while being in a regular dialogue with their users.
Glu Mobile is a mobile gaming company known for Racing Rivals, Cooking Dash 2016 and its upcoming Taylor Swift game. Ratings and reviews features help Glu engage their audience, gather feedback, and manage user satisfaction. “Google’s review highlights allow us to see a snapshot of game features users like or dislike at a glance. We monitor review trends, watch out for notifications, and respond to reviews for our games,” says Niccolo de Masi, Glu Mobile CEO. Here are some tips Glu is using to master ratings and reviews in the Developer Console:
Reply to reviews: Reply to user reviews of your game in the Google Play Developer Console. Help them with their issues or let them know that you're considering their feature suggestions. A positive experience could result in the user increasing their rating.
Use search: You can now search within all reviews and apply search filters for rating, language, app version, device and more. Use this feature to find specific user feedback, for example, on new content you’ve added.
Take action: Now, you can be notified when a user answers you or updates their review. You can immediately start working on improvements if you learned about an issue. If the feedback is positive, engage with your community and turn satisfied users into fans.
Analyze over time: Analyze ratings over time to learn more about how user satisfaction improves as you update your game. This allows you to understand if your latest feature update or bug fix results in higher user satisfaction.
Identify key themes: Google Play automatically surfaces review highlights that users are mentioning about your game. This makes it quick for you to analyze reviews and understand user feedback.
Posted by Roy Glasberg Global Lead, Launchpad Program & Accelerator
Last month, 24 promising startups from India, Indonesia, and Brazil came to Silicon Valley to participate in Google’s Launchpad Accelerator, a new program that provides late-stage startups (mobile apps) with mentoring and resources to successfully scale in their local economies.
During the intensive two-week Accelerator kickoff in our Mountain View headquarters, Google engineers from 11 product areas, as well as experts from other companies, were on hand to provide startups with mentorship on how to scale and monetize their apps, and ultimately, build successful businesses. Now back in their home countries, the teams will continue developing their products with the support of up to $50,000 in equity-free funding, six more months of ongoing mentorship, and a breadth of developer tools from the Launchpad Accelerator program.
So far, many startup participants have already seen an immediate impact. Two weeks after attending the kickoff event, Brazilian mobile game developer UpBeat Games was featured on Google Play and saw a 1,000% increase in app installations in Asia, as well as a 200% overall increase in active users, by leveraging analytics to better understand their users.
According to UpBeat Games founder Vinicius Heimbeck, “By working one-on-one with the mentors, we learned that we needed to be a data-driven company. We now have the right analytics tools to measure the results of our efforts and to learn from them to optimize the user experience. This all directly impacted our huge success once we were featured on Google Play.”
eFishery, an Indonesian startup that produces smart automated fish feeders, turned its focus on scaling since attending Launchpad Accelerator. “The mentors gave us great insight about how to build a scalable product and how to engage billions of users,” said co-founder and CEO Gibran Chuzaefah Amsi El Farizy. “We received both technical and practical advice on our business, from building back-end technology to embracing failure with the right mindset.”
Apply now for Launchpad Accelerator We are also excited to announce the second class for Launchpad Accelerator which will begin in June 2016.
If you are a startup from India, Indonesia, Brazil, or Mexico (a new addition!) and are interested in participating in the next wave, we encourage you to apply here by March 31. We expect to continue adding more countries to the program in the future, so be on the lookout!
When talking about the Android Support Library, it is important to realize this isn’t one monolithic library, but a whole collection of libraries that seek to provide backward-compatible versions of APIs, as well as offer unique features without requiring the latest platform version. Version 23.2 adds a few new support libraries as well as new features to many of the existing libraries.
Support Vector Drawables and Animated Vector Drawables
Vector drawables allow you to replace multiple png assets with a single vector graphic, defined in XML. While previously limited to Lollipop and higher devices, both VectorDrawable and AnimatedVectorDrawable are now available through two new Support Libraries support-vector-drawable and support-animated-vector-drawable, respectively.
Android Studio 1.4 introduced limited support for vector drawables by generating pngs at build time. To disable this functionality (and gain the true advantage and space savings of this Support Library), you need to add vectorDrawables.useSupportLibrary = true to your build.gradle file:
You’ll note this new attribute only exists in the version 2.0 of the Gradle Plugin. If you are using Gradle 1.5 you’ll instead use
// Gradle Plugin 1.5
android {
defaultConfig {
generatedDensities = []
}
// This is handled for you by the 2.0+ Gradle Plugin
aaptOptions {
additionalParameters "--no-version-vectors"
}
}
You’ll be able to use VectorDrawableCompat back to API 7 and AnimatedVectorDrawableCompat on all API 11 and higher devices. Due to how drawables are loaded by Android, not every place that accepts a drawable id (such as in an XML file) will support loading vector drawables. Thankfully, AppCompat has added a number of features to make it easy to use your new vector drawables.
Firstly, when using AppCompat with ImageView (or subclasses such as ImageButton and FloatingActionButton), you’ll be able to use the new app:srcCompat attribute to reference vector drawables (as well as any other drawable available to android:src):
And if you’re changing drawables at runtime, you’ll be able to use the same setImageResource() method as before - no changes there. Using AppCompat and app:srcCompat is the most foolproof method of integrating vector drawables into your app.
You’ll find directly referencing vector drawables outside of app:srcCompat will fail prior to Lollipop. However, AppCompat does support loading vector drawables when they are referenced in another drawable container such as a StateListDrawable, InsetDrawable, LayerDrawable, LevelListDrawable, and RotateDrawable. By using this indirection, you can use vector drawables in cases such as TextView’sandroid:drawableLeft attribute, which wouldn’t normally be able to support vector drawables.
AppCompat DayNight theme
While enabling the use of vector graphics throughout your app is already a large change to AppCompat, there’s a new theme added to AppCompat in this release: Theme.AppCompat.DayNight.
Prior to API 14, The DayNight theme and its descendents DayNight.NoActionBar, DayNight.DarkActionBar, DayNight.Dialog, etc. become their Light equivalents. But on API 14 and higher devices, this theme allows apps to easily support both a Light and Dark theme, effectively switching from a Light theme to a Dark theme based on whether it is ‘night’.
By default, whether it is ‘night’ will match the system value (from UiModeManager.getNightMode()), but you can override that value with methods in AppCompatDelegate. You’ll be able to set the default across your entire app (until process restart) with the static AppCompatDelegate.setDefaultNightMode() method or retrieve an AppCompatDelegate via getDelegate() and use setLocalNightMode() to change only the current Activity or Dialog.
When using AppCompatDelegate.MODE_NIGHT_AUTO, the time of day and your last known location (if your app has the location permissions) are used to automatically switch between day and night, while MODE_NIGHT_NO and MODE_NIGHT_YES forces the theme to never or always use a dark theme, respectively.
It is critical that you test your app thoroughly when using the DayNight themes as hardcoded colors can easily make for unreadable text or icons. If you are using the standard TextAppearance.AppCompat styles for your text or colors pulled from your theme such as android:textColorPrimary, you’ll find these automatically update for you.
However, if you’d like to customize any resources specifically for night mode, AppCompat reuses the night resource qualifier folder, making it possible customize every resource you may need. Please consider using the standard colors or taking advantage of the tinting support in AppCompat to make supporting this mode much easier.
By attaching a BottomSheetBehavior to a child View of a CoordinatorLayout (i.e., adding app:layout_behavior=”android.support.design.widget.BottomSheetBehavior”), you’ll automatically get the appropriate touch detection to transition between five state:
STATE_COLLAPSED: this collapsed state is the default and shows just a portion of the layout along the bottom. The height can be controlled with the app:behavior_peekHeight attribute (defaults to 0)
STATE_DRAGGING: the intermediate state while the user is directly dragging the bottom sheet up or down
STATE_SETTLING: that brief time between when the View is released and settling into its final position
STATE_EXPANDED: the fully expanded state of the bottom sheet, where either the whole bottom sheet is visible (if its height is less than the containing CoordinatorLayout) or the entire CoordinatorLayout is filled
STATE_HIDDEN: disabled by default (and enabled with the app:behavior_hideable attribute), enabling this allows users to swipe down on the bottom sheet to completely hide the bottom sheet
Keep in mind that scrolling containers in your bottom sheet must support nested scrolling (for example, NestedScrollView, RecyclerView, or ListView/ScrollView on API 21+).
If you’d like to receive callbacks of state changes, you can add a BottomSheetCallback:
// The View with the BottomSheetBehavior
View bottomSheet = coordinatorLayout.findViewById(R.id.bottom_sheet);
BottomSheetBehavior behavior = BottomSheetBehavior.from(bottomSheet);
behavior.setBottomSheetCallback(new BottomSheetCallback() {
@Override
public void onStateChanged(@NonNull View bottomSheet, int newState) {
// React to state change
}
@Override
public void onSlide(@NonNull View bottomSheet, float slideOffset) {
// React to dragging events
}
});
While BottomSheetBehavior captures the persistent bottom sheet case, this release also provides a BottomSheetDialog and BottomSheetDialogFragment to fill the modal bottom sheets use case. Simply replace AppCompatDialog or AppCompatDialogFragment with their bottom sheet equivalents to have your dialog styled as a bottom sheet.
Support v4: MediaBrowserServiceCompat
The Support v4 library serves as the foundation for much of the support libraries and includes backports of many framework features introduced in newer versions of the platform (as well a number of unique features).
Adding onto the previously released MediaSessionCompat class to provide a solid foundation for media playback, this release adds MediaBrowserServiceCompat and MediaBrowserCompat providing a compatible solution that brings the latest APIs (even those added in Marshmallow) back to all API 4 and higher devices. This makes it much easier to support audio playback on Android Auto and browsing through media on Android Wear along with providing a standard interface you can use to connect your media playback service and your UI.
RecyclerView
The RecyclerView widget provides an advanced and flexible base for creating lists and grids as well as supporting animations. This release brings an exciting new feature to the LayoutManager API: auto-measurement! This allows a RecyclerView to size itself based on the size of its contents. This means that previously unavailable scenarios, such as using WRAP_CONTENT for a dimension of the RecyclerView, are now possible. You’ll find all built in LayoutManagers now support auto-measurement.
Due to this change, make sure to double check the layout parameters of your item views: previously ignored layout parameters (such as MATCH_PARENT in the scroll direction) will now be fully respected.
If you have a custom LayoutManager that does not extend one of the built in LayoutManagers, this is an opt-in API - you’ll be required to call setAutoMeasureEnabled(true) as well as make some minor changes as detailed in the Javadoc of the method.
Note that although RecyclerView animates its children, it does not animate its own bounds changes. If you would like to animate the RecyclerView bounds as they change, you can use the Transition APIs.
Custom Tabs
Custom Tabs makes it possible to seamlessly transition to web content while keeping the look and feel of your app. With this release, you’ll now be able to add actions to a bottom bar for display alongside the web content.
With the new addToolbarItem() method, you’ll be able to add up to currently 5 (MAX_TOOLBAR_ITEMS) actions to the bottom bar and update them with setToolbarItem() once the session has begun. Similar to the previous setToolbarColor() method, you’ll also find a setSecondaryToolbarColor() method for customizing the background color of the bottom bar.
The most visible change may be the introduce of a second column used for action buttons (added by overriding onCreateButtonActions() or calling setButtonActions()). This makes it much easier to reach completion actions without having to scroll through the list of available GuidedActions.
Speaking of GuidedActions, there’s a number of new features to allow richer input including editable descriptions (via descriptionEditable()), sub actions in the form of a dropdown (with subActions()), and a GuidedDatePickerAction.
These components should make it much easier for you to get information from the user when absolutely required.
Available Now
Version 23.2 of the Android Support Library is available via your SDK Manager and Android Studio. Take advantage of all of the new features as well as additional bug fixes starting now! As always, file bug reports at b.android.com and connect with other developers on the Android Development Google+ community.
This is part 4 of a series on Google Sign-In that began with a blog post on the user experience improvements that launched with Google Play services 8.3. We then discussed the API updates that make the programming model much easier. Most recently, we went into how you can use Google Sign-In to authenticate a user with your backend server.
In this post, we’ll discuss how you can have your users sign in via your app to authorize your service for access to Google APIs, such as Google Drive, on their behalf.
When using Google Sign-In, it is easy to extend your integration with Google by requesting additional scopes for API access after sign-in, like storing the user’s pictures of food in Google Drive. Typically, you should request this access incrementally (not at initial sign-in) -- i.e. in the context of a user’s actions (for example, after an app user’s order has been delivered and they’d like to save a copy of their food photos), following best practices in user experience to make it most likely that the user will grant access, and aligning with the runtime permissions model in Android Marshmallow 6.0.
When you do this kind of integration, you probably want to access data from your server, so that you can continue to have access when the user is offline, or to store user-generated data in your own database. This flow would look like Figure 1. This also has the advantage of working across all platforms.
Figure 1. Accessing Google Services with Credentials.
To do this, follow these steps:
Step 1: As with the scenario in server authentication covered in the previous post, this sample provides canonical code for your Android app. In particular see the ServerAuthCodeActivity.
GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
.requestScopes(new Scope(Scopes.DRIVE_APPFOLDER))
// The serverClientId is an OAuth 2.0 web client ID
// Details at: http://ift.tt/1Ud86SJstart step 4
.requestServerAuthCode(serverClientId)
.requestEmail()
.build();
This requires you to get a web client ID for your server. Details on how to obtain this are available here (see Step 4).
In this case, the scope DRIVE_APPFOLDER is requested, meaning that the user will be asked to give the app permission to access their Google Drive. In addition to this, a server auth code will be requested.
If the sign-in is successful, the auth code can be extracted from the account object like this:
This auth code should then be sent to your server using HTTPS POST, and, after it is exchanged, will give your server access to the user’s Google Drive. [Important: you should send the code in an authenticated call to your backend to ensure that it is a legitimate request from the active user].
// Set path to the Web application client_secret_*.json file you downloaded from the
// Google Developers Console: http://ift.tt/1Vs6QsT
// You can also find your Web application client ID and client secret from the
// console and specify them directly when you create the GoogleAuthorizationCodeTokenRequest
// object.
String CLIENT_SECRET_FILE = "/path/to/client_secret.json"; // Be careful not to share this!
String REDIRECT_URI = "/path/to/web_app_redirect" // Can be empty if you don’t use web redirects
// Exchange auth code for access token
GoogleClientSecrets clientSecrets =
GoogleClientSecrets.load(
JacksonFactory.getDefaultInstance(), new FileReader(CLIENT_SECRET_FILE));
GoogleTokenResponse tokenResponse =
new GoogleAuthorizationCodeTokenRequest(
new NetHttpTransport(),
JacksonFactory.getDefaultInstance(),
"http://ift.tt/1GDfmSD",
clientSecrets.getDetails().getClientId(),
clientSecrets.getDetails().getClientSecret(),
authCode,
REDIRECT_URI)
.execute();
String accessToken = tokenResponse.getAccessToken();
String refreshToken = tokenResponse.getRefreshToken();
Long expiresInSeconds = tokenResponse.getExpiresInSeconds();
// You can also get an ID token from the exchange result if basic profile scopes are requested
// e.g. starting GoogleSignInOptions.Builder from GoogleSignInOptions.DEFAULT_SIGN_IN like the
// sample code as used here: http://goo.gl/0Unpq8
//
// GoogleIdToken googleIdToken = tokenResponse.parseIdToken();
Then, create a GoogleCredential object using the tokens from GoogleTokenResponse:
If a refresh token is available, you can persist the credentials using StoredCredential for later use if you need ongoing access to the API on behalf of the user.
Step 3: The credential can then be used to access Google services. Now, in our food delivery scenario, you might want to store or retrieve photos or receipts of finished deliveries in Google Drive. For example, it would look something like this:
This demonstrates the use of Google Sign-In credentials where your server can make Google API calls on behalf of your users. To learn more about this, and all Google Sign In technologies, visit the Google Identity Platform website.
Posted by Lily Sheringham, The Google Play Apps & Games team
We recently released the second edition of The Secrets to App Success on Google Play with more best practices for finding success growing an app or game business on Google Play. Today we’re sharing our first companion guide for developers, The Family Playbook, which includes information on developing high-quality apps and games for kids and families, along with advice from other developers.
The guide includes advice to help you optimize your user interface design for children, build interactive features that both educate and entertain, develop a business model, understand legal considerations, and plan age-appropriate marketing.
If you create family apps, opt-in to the Designed for Families developer program to designate your apps and games as family-friendly. Apps that meet the program requirements will be featured through Google Play’s family-friendly search and browse experiences and help parents discover great, age-appropriate content and make more informed choices.
Once you’ve checked out the guide, we’d love to hear your feedback so we can continue to improve our developer resources, please let us know what you think.
Android Developer Story: BabyFirst increases installs by 50% with Google Play
BabyFirst was founded to create good educational content for babies, toddlers and their parents. Their apps now have over 30 million downloads, with 40% more downloads on Google Play than other platforms.
We’re delighted to announce the availability of the People API. With it, you can retrieve data about an authenticated user’s connections from their Contacts. Previously, developers had to make multiple calls to the Google+ API for user profiles and the Contacts API for contacts. The new People API uses the newest protocols and technologies and will eventually replace the Contacts API which uses the GData protocol.
For example, if your user has contacts in her private contact list, a call to the API (if she provides consent to do so) will retrieve a list containing the contacts merged with any linked profiles. If the user grants the relevant scopes, the results are returned as a people.connections.list object. Each person object in this list will have a resourceName property, which can be used to get additional data about that person with a call to people.get.
The API is built on HTTP and JSON, so any standard HTTP client can send requests to it and parse the response. However, applications need to be authorized to access the APIs so you will need to create a project on the Google Developers Console in order to get the credentials you need to access the service. All the steps to do so are here. If you’re new to the Google APIs and/or the Developers Console, check out this first in a series of videos to help you get up-to-speed.
Full documentation on the people.connections.list method is available here.
The list of connections will have details on all the user’s social connections if the required scopes have been granted. Contacts will only be returned if the user granted a contacts scope.
Each Person item will have a resource_name associated with it, so additional data for that person will be accessible via a simple call:
Person person = peopleService.people().get("resourceName").execute();
In addition to merging data from multiple sources and APIs into a single cohesive data source, the new People API also exposes additional data that was not possible to get before, such as private addresses, phone numbers, e-mails, and birthdays for a user who has given permission.
We hope that these new features and data along with simplified access to existing data inspires you to create the next generation of cool web and mobile apps that delight your users and those in their circles of influence. To learn more about the People API, check out the official documentation here.
Android Studio 2.0 is latest release of the official Android IDE focused on build performance and emulator speed to improve the app development experience. With brand new features like Instant Run which enables you to quickly edit and view code changes, or the new & faster Android emulator, Android Studio 2.0 is the upgrade you do not want to miss. In preparation for the final release, you can download Android Studio 2.0 Beta in the Beta release channel. Overall, the Android Studio 2.0 release has a host of new features which include:
*Updated for Beta* Instant Run - Enables a faster code edit & app deployment cycle.
*Updated for Beta* Android Emulator - Brand new emulator that is faster than most real devices, and includes a brand new user interface.
*Updated for Beta* Google App Indexing Integration & Testing - Adding App Indexing into your app helps you re-engage your users. In the first preview of Android Studio 2.0 you could add indexing code stubs into your code. With the beta release you can now test and validate your URL links in your app all within the IDE.
Fast ADB - Installing and pushing files is now up to 5x faster using Android Studio 2.0 with an updated Android Debug Bridge (ADB) offered in platform-tools 23.1.0.
GPU Profiler Preview - For graphics intensive applications, you can now visually step through your OpenGL ES code to optimize your app or game
Integration of IntelliJ 15 - Android Studio is based on the efficient coding platform of Intellij. Check out the new features from IntelliJ here.
Check out the latest installment of Android Studio Tool Time to watch the highlights of the features.
New Features in Android Studio 2.0 Beta
Instant Run
We first previewed Instant Run in November; this latest beta release introduces a new capability called Cold Swap
Instant Run in Android Studio 2.0 allows you to quickly make changes to your app code while your app is running on an Android device or Android Emulator. Instead of waiting for your entire app to rebuild and redeploy after each code change, Android Studio 2.0 will try to incrementally build and push only the incremental code or resource change. Depending on the code changes you make, you can see the results of your change in under a second. By simply updating your app to use the latest Gradle plugin ( 'com.android.tools.build:gradle:2.0.0-beta2’ ), you can take advantage of this time saving features with no other modifications to your code. If your project is setup correctly with Instant Run, you will see a lightning bolt next to your Run button on the toolbar:
Instant Run Button
Behind the scenes, Android Studio 2.0 instruments your code during the first compilation and deployment of your app to your device in order to determine where to swap out code and resources. The Instant Run features updates your app on a best-effort basis and automatically uses one of the following swap methods to update your app:
Hot Swap - When only method implementations (including constructors) are changed, the changes are hot swapped. Your application keeps running and the new implementation is used the next time the method is called.
Warm Swap - When app resources are changed, the changes are warm swapped. This is similar to a hot swap, except that the current Activity is restarted. You will notice a slight flicker on the screen as the Activity restarts.
*New for Beta* Cold Swap - This will quickly restart the whole application. Typically for structural code change, including changes to the class hierarchy, method signatures, static initializers, or fields. Cold Swap is available when you deploy to targets with API level 21 or above.
We made major changes to Instant Run since the first preview of Android Studio 2.0, and now the feature works with more code and resources cases. We will continue to add more code change cases to Instant Run in future releases of Android Studio. If you have any suggestions, please feel free to send us a feature request and learn more about Instant Run here.
App Indexing
Supporting app indexing is now even easier with Android Studio 2.0. App Indexing puts your app in front of users who use Google Search. It works by indexing the URL patterns you provide in your app manifest and using API calls from your app to make content within your app available to both existing and new users. Specifically, when you support URLs for your app content, your users can go directly to those links from Google Search results on their device.
Code Generation Introduced in Android Studio 2.0 Preview, you can right click on AndroidManifest.xml or Activity method (or go to Code → Generate…→ App Indexing API Code) to insert HTTP URL stub codes into your manifest and app code.
*New for Beta* URL Testing & Validation What is new in Android Studio 2.0 Beta is that you can now validate and check the results of your URLs with the built-in validation tool (Tools → Android → Google App Indexing Test). To learn more about app indexing, click here.
Insert App Indexing API Code into your app
App Indexing Testing
App Indexing Test Results
Android Emulator
*Updated for Beta* The new and faster Android emulator also includes fixes and small enhancements for this beta release. Notably, we updated the rotation controls on the emulator toolbar and added multi-touch support to help test apps that use pinch & zoom gestures. To use the multi-touch feature, hold down the Alt key on your keyboard and right-click your mouse to center the point of reference or click & drag the left mouse button to zoom.
Pinch & Zoom Gesture with Multi-Touch
What's Next
Android Studio 2.0 is a big release, and now is good time to check out the beta release to incorporate the new features into your workflow. The beta release is near stable release quality, and should be relatively bug free. But as with any beta release, bugs may still exist, so, if you do find an issue, let us know so we can work to fix it. If you’re already using Android Studio, you can check for updates on the Beta channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). When you update to beta, you will get access to the new version of Android Studio and Android Emulator.
Connect with us, the Android Studio development team, on Google+.
Posted by Eitan Marder-Eppstein, Developer Engineering Lead, Project Tango
GPS helps us find our way outside whether it is turn by turn navigation to the nearest grocery or just getting us oriented in a new city. But once we get indoors, it is not quite as easy - GPS doesn't work, with accuracy dropping and navigation becoming all but impossible. This is one of the reasons why we started Project Tango, which has centimeter-scale accuracy of a device’s location, allowing better navigation and experiences in indoor spaces.
Over the past few weeks, we’ve been collecting amazing ideas from around the world for great apps for Lenovo’s Project Tango-powered phone. (Have an idea? If you can dream it, you can submit it!) As part of this program we're hosting workshops, focused on specific Tango features. And we just wrapped up a session that we hosted with Westfield Labs devoted to indoor location. Here are some of the highlights:
As you can see, everyone from retail brands to robot startups joined in on the fun—using Project Tango's motion tracking, depth perception, and area learning capabilities to build some amazing location-based apps. Some of our favorites included:
Wayfair made it possible to look through your phone and visualize how a piece of furniture would look in your home.
Lowe’s Innovation Labs improved in-store navigation by overlaying directions to individual items
And Aisle411 created a shop-along experience with some of your favorite celebrities
The next stop in our series is a utilities workshop, where we'll be going deep on getting things done with Project Tango—like taking 3D measurements, or mapping your home or building. In the meantime, keep submitting your ideas to the App Incubator (the deadline is February 15!), and we'll see you soon!
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.
