Yuzi download

Android Wear 2 0 Developer Preview

Posted by David Singleton, VP of Engineering

Today at Google I/O, we announced the most significant Android Wear update since its launch two years ago: Android Wear 2.0. Based on what we’ve learned from users and developers, were evolving the platform to improve key experiences on the watch, including watch faces, messaging, and fitness.

Android Wear 2.0 will be available to users this fall. We’re making a Developer Preview available today and plan to release additional updates throughout the summer, so please send us your feedback early and often. Also, please keep in mind that this preview is a work in progress, and is not yet intended for daily use.

What’s new?

• Standalone apps: Your Android Wear app can now access the internet directly over Bluetooth, Wi-Fi, or cellular, without relying on the Data Layer APIs. This means your app can continue to offer full functionality even if the paired phone is far away or turned off. Removing the requirement to use the Data Layer APIs also enables your app to offer the same functionality regardless of whether the watch is paired with an Android or iPhone. In addition, your app can receive push messages via Google Cloud Messaging and access AccountManager directly on the watch.
• New system UI: We’ve made a number of UI changes that will help users interact with your app more easily. A new notification design and app launcher make it easier to take action on notifications and launch your app, and a new watch face picker makes switching watch faces fast and fun. The system UI also adopts a dark color palette and makes better use of round displays. We recommend you test your existing Android Wear app and notifications with the new UI.
• Material design for wearables: The new Material Design for Wearables guide will help you make your app’s interface more consistent, intuitive, and beautiful. The new navigation drawer and action drawer components in the Wearable support library make it easy to align your app with the system UI’s new vertical layout. We’ve also provided guidance on how to adopt the dark color palette.
• Complications API: Complications are bite-sized pieces of information displayed to users directly on the watch face. Android Wear now has a system-wide framework to enable any app to show data on any watch face that implements the API. As an app developer, you can choose to publish your data to a wide variety of watch faces and make it easier for users to launch your app from the watch face. As a watch face developer, you can rely on data from a rich ecosystem of Wear apps without having to worry about sourcing it yourself.
• Input methods: Keyboard and handwriting input methods open up new ways to accept text from users on the watch. You can now use these new input methods in your app via RemoteInput and EditText, and notifications that already use RemoteInput for voice replies will automatically support the new input methods. We’ve ported over the full Android input method framework to the watch, so you can even create your own custom input methods if you wish.
• New MessagingStyle notification: Android Wear 2.0 includes a new notification template with a layout optimized for quick and responsive messaging. This template is also available on phones and tablets using Android N, so creating a great cross-device messaging experience is a breeze.
• Google Fit platform: Improvements to the Google Fit platform make it easier for your app to use fitness data and detect activity. You can register a PendingIntent to be notified of changes in the fitness data store, so you don’t have to keep querying for changes to weight, nutrition, and other data types. It’s also easier for your app to get a consistent daily step count on Android Wear -- with HistoryApi.readDailyTotal(), a step recording subscription is no longer required. Finally, apps will soon be able to detect (with consent) when the user starts walking, running, or biking.
• Support for Android N: Your Android Wear app can now take advantage of the latest Android N features such as Data Saver and Java 8 Lambda support. Also, let’s not forget the new emojis!

Get started and give us feedback!

The Android Wear 2.0 Developer Preview includes an updated SDK with tools, and system images for testing on the official Android emulator, the LG Watch Urbane 2nd Edition LTE, and the Huawei Watch.
To get started, follow these steps:

1. Take a video tour of the Android Wear 2.0 developer preview
2. Update to Android Studio v2.1.1 or later
3. Visit the Android Wear 2.0 Developer Preview site for downloads and documentation
4. Get the emulator system images through the SDK Manager or download the device system images
5. Test your app with your supported device or emulator
6. Give us feedback

We will update this developer preview over the next few months based on your feedback. The sooner we hear from you, the more we can include in the final release, so dont be shy!

Available link for download

Android Wear 2 0 Developer Preview 2

Posted by Hoi Lam, Android Wear Developer Advocate

At Google I/O 2016, we launched the Android Wear 2.0 Developer Preview, which gives developers early access to the next major release of Android Wear. Since I/O, feedback from the developer community has helped us identify bugs and shape our product direction. Thank you!

Today, we are releasing the second developer preview with new functionalities and bug fixes. Prior to the consumer release, we plan to release additional updates, so please send us your feedback early and often. Please keep in mind that this preview is a work in progress, and is not yet intended for daily use.

What’s new?

• Platform API 24 - We have incremented the Android Platform API version number to 24 to match Nougat. You can now update your Android Wear 2.0 Preview project’s compileSdkVersion to API 24, and we recommend that you also update targetSdkVersion to API 24.
• Wearable Drawers Enhancements - We launched the wearable drawers as part of the Android Wear 2.0 Preview 1, along with UX guidelines on how to best integrate the navigation drawer and action drawer in your Android Wear app. In Preview 2, we have added additional support for wearable drawer peeking, to make it easier for users to access these drawers as they scroll. Other UI improvements include automatic peek view and navigation drawer closure and showing the first action in WearableActionDrawer’s peek view. For developers that want to make custom wearable drawers, we’ve added peek_view and drawer_content attributes to WearableDrawerView. And finally, navigation drawer contents can now be updated by calling notifyDataSetChanged.
• Wrist Gestures: Since last year, users have been able to scroll through the notification stream via wrist gestures. We have now opened this system to developers to use within their applications. This helps improve single hand usage, for when your users need their other hand to hold onto their shopping or their kids. See the code sample below to get started with gestures in your app:

 public class MainActivity extends Activity { ... @Override /* KeyEvent.Callback */ public boolean onKeyDown(int keyCode, KeyEvent event) { switch (keyCode) { case KeyEvent.KEYCODE_NAVIGATE_NEXT: Log.d(TAG, "Next"); break; case KeyEvent.KEYCODE_NAVIGATE_PREVIOUS: Log.d(TAG, "Previous"); break; } // If you did not handle, then let it be handled by the next possible element as deemed by // Activity. return super.onKeyDown(keyCode, event); } } 

Get started and give us feedback!

The Android Wear 2.0 Developer Preview includes an updated SDK with tools and system images for testing on the official Android emulator, the LG Watch Urbane 2nd Edition LTE, and the Huawei Watch.

To get started, follow these steps:

1. Take a video tour of the Android Wear 2.0 developer preview
2. Update to Android Studio v2.1.1 or later
3. Visit the Android Wear 2.0 Developer Preview site for downloads and documentation
4. Get the emulator system images through the SDK Manager or download the device system images from the developer preview downloads page
5. Test your app with your supported device or emulator
6. Give us feedback

We will update this developer preview over the next few months based on your feedback. The sooner we hear from you, the more we can include in the final release, so dont be shy!

Available link for download

Deprecation of BIND LISTENER with Android Wear APIs

Posted by Wayne Piekarski, Developer Advocate, Android Wear

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

Interactive watch faces with the latest Android Wear update

Posted by Wayne Piekarski, Developer Advocate

The Android Wear team is rolling out a new update that includes support for interactive watch faces. Now, you can detect taps on the watch face to provide information quickly, without having to open an app. This gives you new opportunities to make your watch face more engaging and interesting. For example, in this animation for the Pujie Black watch face, you can see that just touching the calendar indicator quickly changes the watch face to show the agenda for the day, making the watch face more helpful and engaging.

Interactive watch face API

The first step in building an interactive watch face is to update your build.gradle to use version 1.3.0 of the Wearable Support library. Then, you enable interactive watch faces in your watch face style using setAcceptsTapEvents(true):

 setWatchFaceStyle(new WatchFaceStyle.Builder(mService) .setAcceptsTapEvents(true) // other style customizations .build()); 

To receive taps, you can override the following method:

@Override public void onTapCommand(int tapType, int x, int y, long eventTime) { }

You will receive events TAP_TYPE_TOUCH when the user initially taps on the screen, TAP_TYPE_TAP when the user releases their finger, and TAP_TYPE_TOUCH_CANCEL if the user moves their finger while touching the screen. The events will contain (x,y) coordinates of where the touch event occurred. You should note that other interactions such as swipes and long presses are reserved for use by the Android Wear system user interface.

And that’s it! Adding interaction to your existing watch faces is really easy with just a few extra lines of code. We have updated the WatchFace sample to show a complete implementation, and design and development documentation describing the API in detail.

Wi-Fi added to LG G Watch R

This release also brings Wi-Fi support to the LG G Watch R. Wi-Fi support is already available in many Android Wear watches and allows the watch to communicate with the companion phone without requiring a direct Bluetooth connection. So, you can leave your phone at home, and as long as you have Wi-Fi, you can use your watch to receive notifications, send messages, make notes, or ask Google a question. As a developer, you should ensure that you use the Data API to abstract away your communications, so that your application will work on any kind of Android Wear watch, even those without Wi-Fi.

Updates to existing watches

This update to Android Wear will roll out via an over-the-air (OTA) update to all Android Wear watches over the coming weeks. The wearable support library version 1.3 provides the implementation for touch interactions, and is designed to continue working on devices which have not been updated. However, the touch support will only work on updated devices, so you should wait to update your apps on Google Play until the OTA rollout is complete, which we’ll announce on the Android Wear Developers Google+ community. If you want to release immediately but check if touch interactions are available, you can use this code snippet:

PackageInfo packageInfo = PackageManager.getPackageInfo("com.google.android.wearable.app", 0); if (packageInfo.versionCode > 720000000) { // Supports taps - cache this result to avoid calling PackageManager again } else { // Device does not support taps yet }

Android Wear developers have created thousands of amazing apps for the platform and we can’t wait to see the interactive watch faces you build. If you’re looking for a little inspiration, or just a cool new watch face, check out the Interactive Watch Faces collection on Google Play.

Available link for download

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

Always on Android Wear apps with the Google Maps API

Originally posted on the Geo Developers Blog

Posted by Ankur Kotwal, Developer Advocate

Some Android Wear apps are most useful when they are always available to the user, even at a glance. Now, with Google Play Services 8.1, the Google Maps Android API supports ambient mode, the API that provides always-on capabilities. In ambient mode, the map adjusts its style to provide a simplified, low-color rendering of the map. All markers, objects, and UI controls disappear, keeping the map on the screen while letting the user know that it is not currently ready to accept user input. An important advantage is the camera position and zoom level are retained, thus keeping the user’s context within the map.

The screenshot below show how maps appear in interactive mode and in ambient mode.

To implement ambient mode in your maps, follow these steps:

1. Set your your targetSDKVersion to 22 or higher
2. Add the following dependencies to build.gradle for your app to add the wearable support library.

    dependencies { compile com.google.android.support:wearable:1.2.0 provided com.google.android.wearable:wearable:1.0.0 } 

3. Add the wearable shared library entry into the wearable app manifest:

    <application> <uses-library android_name="com.google.android.wearable" android_required="false" /> ... </application> 

4. Add the WAKE_LOCK permission to the handheld and wearable app manifest:

    <uses-permission android_name="android.permission.WAKE_LOCK" /> 

5. Have your Activity extend WearableActivity. This will provide the overrides that notify your app when the wearable enters, exits and provides screen updates in ambient mode.
6. In the onCreate() method of your activity, call the setAmbientEnabled() method. This tells the framework that the app should enter ambient mode rather than returning to the watch face.
7. Set your map to support ambient mode. You can do this by setting the attribute map:ambientEnabled="true" in the activitys XML layout file, or programmatically by setting GoogleMapOptions.ambientEnabled(true). This informs the API to pre-load necessary map tiles for ambient mode.
8. When the activity switches to ambient mode, the system calls the onEnterAmbient() method in your wearable activity. Override onEnterAmbient() and call MapFragment.onEnterAmbient() or MapView.onEnterAmbient(). The map changes to a non-interactive, low-color rendering of the map.
9. When in ambient mode, your app can update the display every minute by overriding onUpdateAmbient(). If you need more frequent updates, check out this guide.
10. When the activity leaves ambient mode, the system calls the onExitAmbient() method in your wearable activity. Override onExitAmbient() and call MapFragment.onExitAmbient() or MapView.onExitAmbient(). The map returns to the normal rendering and is now ready to accept user input.

With always-on maps on Android Wear, you can now show maps at a glance. For more information on these APIs check out the documentation and the sample code.

Available link for download

Check out Facer Hey KittyKitty and more in our Android Wear watch face roundup

from Android Central - Android Forums, News, Reviews, Help and Android Wallpapers http://ift.tt/2ao5sIy
via IFTTT

Available link for download