Yuzi download

Create Intelligent Context Aware Apps with the Google Awareness APIs

Last month at Google I/O 2016 we announced the new Google Awareness APIs, enabling your apps to intelligently react to user context using snapshots and fences with minimal impact on system resources.

Today we’re proud to announce that the Google Awareness API is available to all developers through Google Play services.

Using 7 different types of context—including location, weather, user activity, and nearby beacons—your app can better understand your users’ current situations, and use this information to provide optimized and customized experiences.

The Awareness API offers two ways to take advantage of context signals within your app:

• The Snapshot API lets your app easily request information about the users current context. For example, "give me the users current location and the current weather conditions".
• The Fence API lets your app react to changes in user’s context - and when it matches a certain set of conditions. For example, "tell me whenever the user is walking and their headphones are plugged in". Similar to the Geofencing API, once an awareness fence is registered, it can send callbacks to your app even when its not running.

As a single, simplified surface, the Awareness APIs combine optimally processed context signals in new ways that were not previously possible, providing more accurate and insightful context cues, while also managing system resources to save battery and minimize bandwidth.

We’ve worked closely with some of our partners, who have already found amazing ways to integrate context awareness into their apps:

Trulia, an online residential real estate site, uses our Fence API to suggest open houses. When the weather is perfect and the user is walking around near a house they are interested in, Trulia sends a notification reminding them to stop by. This sort of tailored notification can help users engage with open houses at the perfect time for them.

SuperPlayer Music, on the other hand, uses our Snapshot API and Fence API to suggest the perfect music to match your mood. Whether you’re just finishing up a run and beginning to stretch, setting off on a long car ride, or just getting to the gym, their assistant can understand your context and suggest the right playlist for you.

With our initial set of signals and our awesome partners, we’re just getting started with the Awareness APIs. Join us on a journey to build tailored experiences within your apps, by getting started with the Google Awareness API developer documentation, and learn more by watching our Google I/O session

Available link for download

Enhancing Android Pay APIs

Posted by Pali Bhat, Senior Director, Product Management

Today, we’re enhancing our APIs, making it easier than ever for the developer community to integrate with Android Pay. With just a few lines of code, you can enable quick and seamless checkout to help increase purchase conversions and ongoing engagement.

Improve conversions within apps

We’ve been working with popular apps such as Airbnb, Yelp Eat24, Kickstarter, TicketMaster, Uber and many others to bring the ease of speedy checkouts to apps. We also want to make the same great in-app experience available to all developers, big or small. So we’re taking a few steps:

• Earlier today, we announced Android Instant Apps, which gives users the ability to pay using Android Pay with a single tap, without the friction of getting a user to install the app to complete their transaction. 

Example of Android Pay in Android Instant Apps

• We’re opening the Android Pay API to all developers selling physical goods and services in markets where Android Pay is available—just sign up at developers.google.com/android-pay/
• We’ve teamed up with payment processors globally so developers can integrate Android Pay with their Android apps in just a few hours.

Enhance mobile web payments

Many users continue to make purchases on mobile sites. But buying something from a website on your phone can be clumsy and cumbersome, which results in much lower conversion rates on mobile sites than on desktop sites.

To make painful web checkout forms a thing of the past, we will be launching PaymentRequest, a brand new web API that we are developing together with Chrome and standardizing across browsers through W3C. Android Pay will be part of this API to allow users to pay on mobile websites as they do in-store and in-app.

Example of Android Pay in PaymentRequest

Drive deeper engagement

Thanks for all the great feedback on our Save to Android Pay API since launch. You spoke and we’ve listened: We think you’ll be thrilled with the latest improvements to the Save to Android Pay API. The following enhancements help developers build stronger loyalty and engagement with new and existing customers:

• Enable users to add offers, loyalty cards and gift cards in the Android Pay app with the tap of a button. Simply add a deep link to an email, SMS message, push notification or within an app and you’re all set.
• Enroll new customers into a loyalty program in a variety of ways with the new simplified sign-up feature. Customers can sign-up either in store via a NFC tap or through a sign-up page linked from an Android Pay transaction notification.

Example sign-up feature for Walgreens Balance Reward®   via Save to Android Pay from transaction notification

We believe that mobile payments can make for a better, more secure shopping experience - so were in this together for the long haul. We’re building a robust Android Pay ecosystem, one that’s open and scalable, to enable developers to drive mobile payments - and their businesses - forward. Were very excited for the road ahead and we hope you are too.

To learn more about Android Pay and share your feedback, visit our developer pages.

Available link for download

Deprecation of BIND LISTENER with Android Wear APIs

If you’re an Android Wear developer, we wanted to let you know of a change you might need to make to your app to improve the performance of your user’s devices. If your app is using BIND_LISTENER intent filters in your manifest, it is important that you are aware that this API has been deprecated on all Android versions. The new replacement API introduced in Google Play Services 8.2 is more efficient for Android devices, so developers are encouraged to migrate to this as soon as possible to ensure the best user experience. It is important that all Android Wear developers are aware of this change and update their apps as soon as possible.

Limitations of BIND_LISTENER API

When Android Wear introduced the WearableListenerService, it allowed you to listen to changes via the BIND_LISTENER intent filter in the AndroidManifest.xml. These changes included data item changes, message arrivals, capability changes, and peer connects/disconnects.

The WearableListenerService starts whenever any of these events occur, even if the app is only interested in one type. When a phone has a large number of apps using WearableListenerService and BIND_LISTENER, a watch appearing or disappearing can cause many services to start up. This applies memory pressure to the device, causing other activities and services to be shut down, and generates unnecessary work.

Fine-grained intent filter API

In Google Play Services 8.2, we introduced a new fine-grained intent filter mechanism that allows developers to specify exactly what events they are interested in. For example, if you have multiple listener services, use a path prefix to filter only those data items and messages meant for the service, with syntax like this:

 <service android_name=".FirstExampleService"> <intent-filter> <action android_name="com.google.android.gms.wearable.DATA_CHANGED" /> <action android_name="com.google.android.gms.wearable.MESSAGE_RECEIVED" /> <data android_scheme="wear" android_host="*" android_pathPrefix="/FirstExample" /> </intent-filter> </service> 

There are intent filters for DATA_CHANGED, MESSAGE_RECEIVED, CHANNEL_EVENT, and CAPABILITY_CHANGED. You can specify multiple elements, and if any of them match, it will call your service and filter out anything else. If you do not include a element, all events will be filtered out and your service will never be called, so make sure to include at least one. You should be aware that registering in an AndroidManifest.xml for CAPABILITY_CHANGED will cause your service to be called any time a device advertising this capability appears or disappears, so you should use this only if there is a compelling reason.

Live listeners

If you only need these events when an Activity or Service is running, then there is no need to register a listener in AndroidManifest.xml at all. Instead, you can use addListener() live listeners, which will only be active when the Activity or Service is running, and will not impact the device otherwise. This is particularly useful if you want to do live status updates for capabilities being available in an Activity, but with no further background impact. In general, you should try to use addListener(), and only use AndroidManifest.xml when you need to receive events all the time.

Best practices

In general, you should only use a listener in AndroidManifest.xml for events that must launch your service. For example, if your watch app needs to send an interactive message or data to the phone.

You should try to limit the number of wake-ups of your service by using filters. If most of the events do not need to launch your app, then use a path and a filter that only matches the event you need. This is critical to limit the number of launches of your service.

If you have other cases where you do not need to launch a service, such as listening for status updates in an Activity, then register a live listener only for the duration it is needed.

Documentation

There is more information available about Data Layer events and the use of WearableListenerService, and tags in the manifest. Android Studio has a guide with a summary of how to convert to the new API. The Android Wear samples also show best practices in the use of WearableListenerService, such as DataLayer and XYZTouristAttractions. The changes needed are very small, and can be seen in this git diff from one of the samples here.

Removal of BIND_LISTENER

With the release of Android Studio 2.1, lint rules have been added that flag the use of BIND_LISTENER as a fatal error, and developers will need to make a small change to the AndroidManifest.xml to declare accurate intent filters. If you are still using BIND_LISTENER, you will receive the following error:

 AndroidManifest.xml:11: Error: The com.google.android.gms.wearable.BIND_LISTENER action is deprecated. [WearableBindListener] <action android_name="com.google.android.gms.wearable.BIND_LISTENER" /> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

This will only impact developers who are recompiling their apps with Android Studio 2.1 and will not affect existing apps on user’s devices.

For developers who are using Google Play Services earlier than 8.2, the lint rules will not generate an error, but you should update to a newer version and implement more accurate intent filters as soon as possible.

In order to give users the best experience, we plan to disable BIND_LISTENER in the near future. It is therefore important that developers take action now, to avoid any future disruption experienced by users of their apps.

Available link for download

Android N APIs are now final get your apps ready for Android N!

As we put the finishing touches on the next release of Android, which will begin to roll out to consumers later this summer, we’re releasing the 4th Developer Preview of Android N, including the Android N final SDK. And thanks to your continued feedback over the last three releases, all of the APIs are now final as well. If you’ve already enrolled your device in the Android Beta Program, (available at android.com/beta) you will receive an update to this Developer Preview shortly.

Get your apps ready for Android N

The final SDK for Android N is now available for download through the SDK Manager in Android Studio. It gives you everything you need to develop and test against the official APIs in the Android N platform. Once you’ve installed the final SDK, you can update your project’s compileSdkVersion to API 24 to develop with the Android N APIs and build and test on the new platform, for new features such as Multi-window support, direct-reply notifications, and others. We also recommend updating your app’s targetSdkVersion to API 24 to opt-in and test your app with Android N specific behavior changes. For details on how to setup your app with the final SDK, see Set up the Preview. For details on API level 24 check out the API diffs and the updated API reference, now hosted online.

Along with the Android N final SDK, we’ve also updated the Android Support Library to 24.0.0. This allows you to use multi-window and picture-in-picture callbacks, new notification features, methods for supporting Direct Boot, and new MediaBrowser APIs in a backward compatible manner.

Publish your apps to alpha, beta or production channels in Google Play

Now that you have a final set of APIs, you can publish updates compiling with, and optionally targeting, API 24 to Google Play. You can now publish app updates that use API 24 to your alpha, beta, or even production channels in the Google Play Developer Console. In this way, you can test your app’s backward-compatibility and push updates to users whose devices are running Developer Preview 4.

To make sure that your updated app runs well on Android N, as well as older versions, a common strategy is to use Google Play’s beta testing feature to get early feedback from a small group of users -- including developer preview users — and then do a staged rollout as you release the updated app to all users.

How to Get Developer Preview 4

Developer Preview 4 includes updated system images for all supported Preview devices as well as for the Android emulator. If you are already enrolled in the Android Beta program, your devices will get the Developer Preview 4 update right away, no action is needed on your part. If you aren’t yet enrolled in Android Beta, the easiest way to get started is by visiting android.com/beta and opt-in your eligible Android phone or tablet -- you’ll soon receive this (and later) preview updates over-the-air. As always, you can also download and flash this update manually. The N Developer Preview is available for Nexus 6, Nexus 5X, Nexus 6P, Nexus 9, and Pixel C devices, as well as General Mobile 4G [Android One] devices and the Sony Xperia Z3.

Thanks so much for all of your feedback so far. Please continue to share feedback or requests either in the N Developer Preview issue tracker, N Preview Developer community, or Android Beta community as we work towards the consumer release later this summer. We’re looking forward to seeing your apps on Android N!

Available link for download

First Preview of Android N Developer APIs Tools

Today we’re happy to announce a Developer Preview of the N release of Android! We’re doing something a little different this year by releasing the preview early… really early. By releasing a “work in progress” build earlier in development, we have more time to incorporate developer feedback. Also, the earlier preview allows us to hand off the final N release to device makers this summer, so they can get their hands on the latest version of Android earlier than ever. We’re looking forward to getting your feedback as you get your apps ready for N.

Here are a few APIs and features we want to highlight which are available as a part of the Android N Developer Preview today, with more to come as we continue developing the release:

Multi-window - A new manifest attribute called android:resizableActivity is available for apps targeting N and beyond. If this attribute is set to true, your activity can be launched in split-screen modes on phones and tablets. You can also specify your activitys minimum allowable dimensions, preventing users from making the activity window smaller than that size. Lifecycle changes for multi-window are similar to switching from landscape to portrait mode: your activity can handle the configuration change itself, or it can allow the system to stop the activity and recreate it with the new dimensions. In addition, activities can also go into picture-in-picture mode on devices like TVs, and is a great feature for apps that play video; be sure to set android:supportsPictureInPicture to true to take advantage of this.

Direct reply notifications: The RemoteInput notification API, which was originally added for Android Wear, now works in N for phones and tablets. Using the RemoteInput API enables users to reply to incoming message notifications quickly and conveniently, without leaving the notification shade. Learn more here.

Bundled notifications - With N, you can use the Notification.Builder.setGroup() method to group notifications from the same app together - for example individual messages from a messaging app. Grouped notifications can be expanded into individual notifications by using a two-finger gesture or tapping the new expansion button. Learn more here.

Efficiency - We launched Doze in Marshmallow to save battery when your device is stationary. In N, Doze additionally saves battery whenever the screen turns off. If you’ve already adapted your app for Doze, e.g. by using the GCM high priority message for urgent notifications, then you’re set; if not, here’s how to get started. Also, we’re continuing to invest in Project Svelte, an effort to reduce the memory needs of Android so that it can run on a much broader range of devices, in N by making background work more efficient. If you use JobScheduler for background work, you’re already on the right track. If not, N is a good time to make that switch. And to help you out, we’re making JobScheduler even more capable, so now you can use JobScheduler to react to things like changes to content providers.

Available link for download