Showing posts with label sdk. Show all posts
Showing posts with label sdk. Show all posts

Monday, January 2, 2017

Google Play Services 8 4 SDK is available

Google Play Services 8 4 SDK is available


Posted by Laurence Moroney, Developer Advocate

We’re delighted to announce the availability of Google Play services 8.4. There’s a lot of new information to share with you about what’s available to you in this release.



Custom Email App Invites

App Invites is a technology that enables your users to share apps with people they know. In Google Play services 8.4 we’ve updated this to make it easier for them to share via email. Before this you could create a custom email that contained user defined text and an image, but now we’re allowing you to add content from the app directly into the message. It allows you to fully define the email body using HTML, and set the email subject line. So, for example, if you have a favorite cooking app that you want to share with your friends, your invite to use the app can include a favorite recipe from the app. They get the immediate benefit of being able to access the desired content, giving them a more informed choice about whether or not they decide to install the app to get richer and more content. Check out the App Invites sample on GitHub here.

Predicting User spend and churn in games

The Play Games Analytics developer experience is designed to enable game developers to better understand, manage, and optimize game experiences throughout the player lifecycle. With this in mind, we’ve extended the Player Stats API to help you better understand your players behavior, and based on this, entice them to stay in your game.

The churn prediction method will return data on the probability that the player will churn, i.e., stop playing the game. You can create content in response to this to entice them to stay in your game.

Additionally, the spend prediction method will return the probability that the player will spend something in the game. It’s up to you how to handle this data, but -- for example -- if there’s a low probability that the player will spend something, you could provide discounted in-app purchases or show ads.

Fused Location Provider Updates

The Fused Location Provider (FLP) in Google Play services provides location to your apps using a number of sensors, including GPS, WiFi and Cell Towers.

When desiring to save battery power, and using coarse updates, the FLP doesn’t use Global Positioning Services (GPS), and instead uses WiFi and Cell tower signals. In Google Play services 8.4, we have greatly improved how the FLP detects location from cell towers. Prior to this, we would get the location information relative to only the primary cell tower. Now, the FLP takes the primary tower and other towers nearby to provide a more accurate location. We’ve also improved location detection from WiFi access points, particularly in areas where GPS is not available -- such as indoors.

Maps API Improvements

Have you ever wished you could easily handle a tap on a suburb without having to add another layer on the map to intercept the taps? We’ve added an onClickListener for polygons, so you can easily add transparent polygons and intercept the taps directly. We’ve also added on click listeners to polylines and ground overlays.

Here’s how you can use a listener to detect a click on a polygon:

 map.setOnPolygonClickListener(new GoogleMap.OnPolygonClickListener() { @Override public void onPolygonClick(Polygon polygon) { ... } }); 

Info windows now also offer an OnInfoWindowCloseListener and an OnInfoWindowLongClickListener. The on close listener is particularly useful if you wish to zoom back out on the map after the user has looked at the detail associated with a particular marker.

 mMap.setOnInfoWindowCloseListener(new GoogleMap.OnInfoWindowCloseListener() {...}); 
 mMap.setOnInfoWindowLongClickListener(new GoogleMap.OnInfoWindowLongClickListener() {...}); 

For more details, and an example that uses these, see the ApiDemos sample on GitHub and check out the historical changes to this sample, so you can see how the new APIs work. Also see the Release Notes.

Support for Aztec bar codes

In Google Play services 7.8, we launched Vision APIs that supported face and barcode detection. One bar code format we didn’t support was Aztec bar codes, so with Google Play services 8.4 we’ve now added support for these.

Applications using BarcodeDetector in its default configuration (no barcode format restrictions) will automatically start decoding AZTEC codes.

Background Beacon Scanning

With Google Play services 8.4, the Nearby Messages API now supports background scanning for Eddystone, the open beacon format from Google. With this update, your app can be woken up when a BLE beacon is sighted. Back in July, Google Play Services 7.8 introduced the Nearby Messages API with a simple publish-subscribe interface. In the case of beacons, developers publish content by adding attachments to beacon records using Proximity Beacon API. These attachments are served back to your app when Nearby sights a beacon of interest.

New methods that we’ve added include a subscribe method for background beacon subscriptions where BLE scans are triggered at screen-on events; an associated unsubscribe event; and the ability to handle intents that you get when the Nearby API calls back during a background subscription.

Fitness Platform HistoryApi Improvements

We now support consistent step counts across the Google Fit app, other fitness apps and Android Wear watch faces with the HistoryApi.readDailyTotal() method. Please see the following documentation for more detail: https://developers.google.com/fit/android/history#read_daily_total_data?utm_campaign=play services_series_launch_121815&utm_source=anddev&utm_medium=blog

We also have a new HistoryApi.updateData() method. This method allows you to update data in one API call without having to delete and insert with two calls.

Place Picker Autocomplete Widget

Today we are announcing the mobile autocomplete widget, the latest addition to our existing set of programmatic autocomplete features on Android and iOS, as well as the addition of Autocomplete to our place picker widget. Autocomplete functionality assists users by automatically completing the name and address of a place as they type. Widgets make it even easier for developers to add autocomplete functionality to their application with just a small amount of code. Learn more about this at this blog post.


Available link for download

Read more »

Sunday, October 23, 2016

API 23 SDK now available for Android Wear

API 23 SDK now available for Android Wear


Posted by Wayne Piekarski, Developer Advocate

The new LG Watch Urbane 2nd Edition LTE is the first watch to run Android 6.0 Marshmallow (API 23) for Android Wear. Currently, all other Android Wear watches implement API 22, and in the coming months, these will receive an OTA update for API 23 as well.

So what does this mean for you as an Android Wear developer? You will need to ensure that your apps are compatible with both API 23 and API 22 watches. While you can start implementing the new features in this post, you still need to maintain backwards compatibility until all watches are upgraded.

New permissions model and samples

API 23 introduces a new runtime permissions model for both phones and watches. The new permissions model allows users to pick and choose which permissions to grant apps at the time of use. In addition, new permissions settings allow users to turn on and off app permissions at any time.

To use the new permissions model on Wear, read Permissions on Android Wear. This training guide provides an in-depth discussion of Wear-specific scenarios, such as when your Wear app relies on a phone-side permission. In addition, all of the Android Wear samples have been updated to use the new permissions model, and a new RuntimePermissionsWear sample shows how to handle permission requests across devices.

When you are ready, you can update your application on both the phone and watch side to use compileSdkVersion 23 and targetSdkVersion 23. Make sure that you check and request the permissions needed by your app at runtime, on both the phone and the watch. It is important that you do not change targetSdkVersion to 23 until you have implemented the permission checks properly, since it changes how the system installs and runs the app. For example, an API call that might have previously returned a result could now fail, causing the app to behave in unexpected ways.

-round and -notround resource qualifiers

API 23 makes it easier to build apps for both round and square Android Wear watches. We listened to your feedback and added new resource qualifiers for -round and -notround, so you can use the resource system to load the appropriate images, layouts, and strings based on the type of watch you are working with. You can also combine this with existing resource qualifiers -hdpi, -tvdpi, -280dpi, and -360dpi for the various Android Wear watches that are currently available. All of the existing classes in the wearable UI library, such as WatchViewStub, BoxInsetLayout, and WearableFrameLayout will continue to work as well, so you do not need to change your code. The -round and -notround resource qualifiers will not work on API 22 devices, so you cannot assume they will be available until all devices are on API 23.

Watches with speakers

The LG Watch Urbane 2nd Edition LTE is the first watch to include speaker support, so you can now add sounds to your Wear app. You can play audio files using the same APIs that are available on Android phones, such as AudioTrack, MediaPlayer, and ExoPlayer. Check out the sample and documentation to learn how to detect when the speaker is available on a Wear device and play sounds through it.

Intel x86 support

The new TAG Heuer Connected, along with other upcoming Android Wear watches, is based on Intel x86 processors. If you are working only with Java code, your apps will automatically work on any architecture. However, if you’re using the NDK, you’ll need to provide both armeabi-v7a and x86 shared libraries in your wearable APK. Since only one wearable app can be bundled in a phone app, it is not possible to deliver different APKs to different watches based on architecture. If your wearable APK is missing an x86 library, it will fail to install on x86 watches with INSTALL_FAILED_NO_MATCHING_ABIS and code -113.

If you are using Android Studio, you will need to adjust your build.gradle file to include:

ndk { abiFilters = [armeabi-v7a,x86] }

If you are using the NDK directly, you will need to modify your Application.mk file to use:

APP_ABI := armeabi-v7a x86

These changes should only be made for the wearable APK, and you can continue to support other ABIs on the phone side. You can test your application by checking if it works on the x86 emulator provided by the SDK Manager.

Updated emulator

New Android Wear emulator images for API 23 and x86 watches are available to download from the SDK Manager in Android Studio. We have also added profiles that represent every available Android Wear watch, so you can easily test on any device you want. It is also important that you understand and test all the combinations of phones (API <= 22, API = 23) and wearables (API 22, API 23), so that your app works for all users.

Updates to existing watches

The new emulator images allow you to get started immediately with testing and deploying updated apps for users with API 23 watches. The schedule for updating existing Android Wear watches via OTA updates has not been announced yet. We will announce the update schedule on the Android Wear Developers Google+ community. We’ll also let you know when the rollout is complete, and API 22 support for Android Wear is no longer needed.


Available link for download

Read more »

Tuesday, September 20, 2016

Develop a sweet spot for Marshmallow Official Android 6 0 SDK Final M Preview

Develop a sweet spot for Marshmallow Official Android 6 0 SDK Final M Preview


By Jamal Eason, Product Manager, Android

Android 6.0 Marshmallow

Whether you like them straight out of the bag, roasted to a golden brown exterior with a molten center, or in fluff form, who doesn’t like marshmallows? We definitely like them! Since the launch of the M Developer Preview at Google I/O in May, we’ve enjoyed all of your participation and feedback. Today with the final Developer Preview update, were introducing the official Android 6.0 SDK and opening Google Play for publishing your apps that target the new API level 23 in Android Marshmallow.

Get your apps ready for Android Marshmallow

The final Android 6.0 SDK is now available to download via the SDK Manager in Android Studio. With the Android 6.0 SDK you have access to the final Android APIs and the latest build tools so that you can target API 23. Once you have downloaded the Android 6.0 SDK into Android Studio, update your app project compileSdkVersion to 23 and you are ready to test your app with the new platform. You can also update your app to targetSdkVersion to 23 test out API 23 specific features like auto-backup and app permissions.

Along with the Android 6.0 SDK, we also updated the Android Support Library to v23. The new Android Support library makes it easier to integrate many of the new platform APIs, such as permissions and fingerprint support, in a backwards-compatible manner. This release contains a number of new support libraries including: customtabs, percent, recommendation, preference-v7, preference-v14, and preference-leanback-v17.

Check your App Permissions

Along with the new platform features like fingerprint support and Doze power saving mode, Android Marshmallow features a new permissions model that streamlines the app install and update process. To give users this flexibility and to make sure your app behaves as expected when an Android Marshmallow user disables a specific permission, it’s important that you update your app to target API 23, and test the app thoroughly with Android Marshmallow users.

How to Get the Update

The Android emulator system images and developer preview system images have been updated for supported Nexus devices (Nexus 5, Nexus 6, Nexus 9 & Nexus Player) to help with your testing. You can download the device system images from the developer preview site. Also, similar to the previous developer update, supported Nexus devices will receive an Over-the-Air (OTA) update over the next couple days.

Although the Android 6.0 SDK is final, the devices system images are still developer preview versions. The preview images are near final but they are not intended for consumer use. Remember that when Android 6.0 Marshmallow launches to the public later this fall, youll need to manually re-flash your device to a factory image to continue to receive consumer OTA updates for your Nexus device.

What is New

Compared to the previous developer preview update, you will find this final API update fairly incremental. You can check out all the API differences here, but a few of the changes since the last developer update include:

  • Android Platform Change:
    • Final Permissions User Interface — we updated the permissions user interface and enhanced some of the permissions behavior.
  • API Change:
    • Updates to the Fingerprint API — which enables better error reporting, better fingerprint enrollment experience, plus enumeration support for greater reliability.

Upload your Android Marshmallow apps to Google Play

Google Play is now ready to accept your API 23 apps via the Google Play Developer Console on all release channels (Alpha, Beta & Production). At the consumer launch this fall, the Google Play store will also be updated so that the app install and update process supports the new permissions model for apps using API 23.

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


Available link for download

Read more »