Develop
Important: This article is about the Develop, The best of Develop inspiration updated regularly with new designs and info, and featuring the best Develop
Originally Answered: What are the best sites?
Develop , We Always give correct and complete information about Develop, This document provides Develop We want to improve the quality of content for all. By using information about the content you have received, those involved in providing info in .

Advertisement
Showing posts with label Develop. Show all posts
Showing posts with label Develop. Show all posts

Wednesday, December 21, 2016

Introducing the ExifInterface Support Library

With the release of the href="https://developer.android.com/topic/libraries/support-library/revisions.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog#rev25-1-0">25.1.0 Support Library, there's a new entry in the family: the ExifInterface Support Library. With significant improvements introduced in Android 7.1 to the framework's href="https://developer.android.com/reference/android/media/ExifInterface.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog">ExifInterface, it only made sense to make those available to all API 9+ devices via the Support Library's ExifInterface.

The basics are still the same: the ability to read and write href="https://en.wikipedia.org/wiki/Exif?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog">Exif tags embedded within image files: now with 140 different attributes (almost 100 of them new to Android 7.1/this Support Library!) including information about the camera itself, the camera settings, orientation, and GPS coordinates.

Camera Apps: Writing Exif Attributes

For Camera apps, the writing is probably the most important - writing attributes is still limited to JPEG image files. Now, normally you wouldn't need to use this during the actual camera capturing itself - you'd instead be calling the Camera2 API href="https://developer.android.com/reference/android/hardware/camera2/CaptureRequest.Builder.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog#set(android.hardware.camera2.CaptureRequest.Key%3CT%3D,%20T)">CaptureRequest.Builder.set() with href="https://developer.android.com/reference/android/hardware/camera2/CaptureRequest.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog#JPEG_ORIENTATION">JPEG_ORIENTATION, href="https://developer.android.com/reference/android/hardware/camera2/CaptureRequest.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog#JPEG_GPS_LOCATION">JPEG_GPS_LOCATION or the equivalents in the Camera1 href="https://developer.android.com/reference/android/hardware/Camera.Parameters.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog">Camera.Parameters. However, using ExifInterface allows you to make changes to the file after the fact (say, removing the location information on the user's request).

Reading Exif Attributes

For the rest of us though, reading those attributes is going to be our bread-and-butter; this is where we see the biggest improvements.

Firstly, you can read Exif data from JPEG and raw images (specifically, DNG, CR2, NEF, NRW, ARW, RW2, ORF, PEF, SRW and RAF files). Under the hood, this was a major restructuring, removing all native dependencies and building an extensive test suite to ensure that everything actually works.

For apps that receive images from other apps with a content:// URI (such as those sent by apps that href="https://developer.android.com/about/versions/nougat/android-7.0-changes.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog#sharing-files">target API 24 or higher), ExifInterface now works directly off of an InputStream; this allows you to easily extract Exif information directly out of content:// URIs you receive without having to create a temporary file. class="prettyprint">Uri uri; // the URI you've received from the other app
InputStream in;
try {
in = getContentResolver().openInputStream(uri);
ExifInterface exifInterface = new ExifInterface(in);
// Now you can extract any Exif tag you want
// Assuming the image is a JPEG or supported raw format
} catch (IOException e) {
// Handle any errors
} finally {
if (in != null) {
try {
in.close();
} catch (IOException ignored) {}
}
}

Note: ExifInterface will not work with remote InputStreams, such as those returned from a href="https://developer.android.com/reference/java/net/HttpURLConnection.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog">HttpURLConnection. It is strongly recommended to only use them with content:// or file:// URIs.

For most attributes, you'd simply use the href="https://developer.android.com/reference/android/support/media/ExifInterface.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog#getAttributeInt(java.lang.String,%20int)">getAttributeInt(), href="https://developer.android.com/reference/android/support/media/ExifInterface.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog#getAttributeDouble(java.lang.String,%20double)">getAttributeDouble(), or href="https://developer.android.com/reference/android/support/media/ExifInterface.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog#getAttribute(java.lang.String)">getAttribute() (for Strings) methods as appropriate.

One of the most important attributes when it comes to displaying images is the image orientation, stored in the aptly-named href="https://developer.android.com/reference/android/support/media/ExifInterface.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog#TAG_ORIENTATION">TAG_ORIENTATION, which returns one of the ORIENTATION_ constants. To convert this to a rotation angle, you can post-process the value. class="prettyprint">int rotation = 0;
int orientation = exifInterface.getAttributeInt(
ExifInterface.TAG_ORIENTATION,
ExifInterface.ORIENTATION_NORMAL);
switch (orientation) {
case ExifInterface.ORIENTATION_ROTATE_90:
rotation = 90;
break;
case ExifInterface.ORIENTATION_ROTATE_180:
rotation = 180;
break;
case ExifInterface.ORIENTATION_ROTATE_270:
rotation = 270;
break;
}

There are some helper methods to extract values from specific Exif tags. For location data, the href="https://developer.android.com/reference/android/support/media/ExifInterface.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog#getLatLong(float[])">getLatLong() method gives you the latitude and longitude as floats and href="https://developer.android.com/reference/android/support/media/ExifInterface.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog#getAltitude(double)">getAltitude() will give you the altitude in meters. Some images also embed a small thumbnail. You can check for its existence with href="https://developer.android.com/reference/android/support/media/ExifInterface.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog#hasThumbnail()">hasThumbnail() and then extract the byte[] representation of the thumbnail with href="https://developer.android.com/reference/android/support/media/ExifInterface.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog#getThumbnail()">getThumbnail() - perfect to pass to href="https://developer.android.com/reference/android/graphics/BitmapFactory.html?utm_campaign=android_launch_exifsupportlibrary_122116&utm_source=anddev&utm_medium=blog#decodeByteArray(byte[],%20int,%20int)">BitmapFactory.decodeByteArray().

Working with Exif: Everything is optional

One thing that is important to understand with Exif data is that there are no required tags: each and every tag is optional - some services even specifically strip Exif data. Therefore throughout your code, you should always handle cases where there is no Exif data, either due to no data for a specific attribute or an image format that doesn't support Exif data at all (say, the ubiquitous PNGs or WebP images).

Add the ExifInterface Support Library to your project with the following dependency:

class="prettyprint">compile "com.android.support:exifinterface:25.1.0"

But when an Exif attribute is exactly what you need to prevent a mis-rotated image in your app, the ExifInterface Support Library is just what you need to #BuildBetterApps

Friday, December 16, 2016

Games authentication adopting Google Sign-In API


Posted by Clayton Wilkinson, Developer Platform Engineer



Some changes are coming to Play Game Services in early 2017:


Changes to Google API Client building



In November, we announced an href="https://developers.googleblog.com/2016/11/moving-to-google-sign-in-for-a-better-user-experience-and-higher-conversion-rates.html">update
to Google Sign-In API. Play Game Services is being updated to use Google
Sign-In API for authentication. The advantages are:


  • Games and Sign-In in same client connection.
  • Single API for getting Auth code to send to backend servers.


This change unifies the Google Sign-in and the Games API Sign-in, so there are
updates to how to build the Google API Client:



class="prettyprint">// Defaults to Games Lite scope, no server component
GoogleSignInOptions gso = new
GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_GAMES_SIGN_IN).build();

// OR for apps with a server component
GoogleSignInOptions gso = new
GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_GAMES_SIGN_IN)
.requestServerAuthCode(SERVER_CLIENT_ID)
.build();

// OR for developers who need real user Identity
GoogleSignInOptions gso = new
GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_GAMES_SIGN_IN)
.requestEmail()
.build();

// Build the api client.
mApiClient = new GoogleApiClient.Builder(this)
.addApi(Games.API)
.addApi(Auth.GOOGLE_SIGN_IN_API, gso)
.addConnectionCallbacks(this)
.build();
}

@Override
public void onConnected(Bundle connectionHint) {
if (mApiClient.hasConnectedApi(Games.API)) {
Auth.GoogleSignInApi.silentSignIn(mApiClient).setResultCallback(
new ResultCallback() {
@Override
public void onResult(GoogleSignInResult googleSignInResult) {
// In this case, we are sure the result is a success.
GoogleSignInAccount acct =
googleSignInResult.getGoogleSignInAccount());

// For Games with a server, send the auth code to your server.
String serverAuthCode = signInAccount.getServerAuthCode();

// Use the API client as normal.
Player player = Games.API.getCurrentPlayer(mApiClient);
}
}
);
} else {
onSignedOut();
}
}

Account creation within iOS is no longer supported



  • Currently, there is no support for new players to create a Play Games
    account on iOS. Additionally, the Google+ integration has been removed from
    iOS. As a result "social" APIs will return result codes indicating success, but
    return empty lists. This includes the "standard" UIs for leaderboards and
    multiplayer invitations.

Google+ is no longer integrated



  • href="http://android-developers.blogspot.com/2016/01/play-games-permissions-are-changing-in.html">Announced
    last year, Games is decoupled from Google+ during this transition. As a
    result the public APIs for getting connected players via circles stopped
    working, but the standard UIs for multiplayer invitations and social
    leaderboards continued to work. Starting from February 2017, the standard UIs
    will also not display the Social graph results as Google+ data becomes
    inaccessible. This will affect multiplayer games, social leaderboards, and
    gifts API on Android. The effect will be that these APIs will return
    successfully, but with an empty list of players.


List of APIs that are deprecated by removing Google+ integration (and their C++
equivalents):


  1. href="https://developers.google.com/android/reference/com/google/android/gms/games/Players.html?utm_campaign=product area_discussion_games_121616&utm_source=anddev&utm_medium=blog#getPlayerSearchIntent(com.google.android.gms.common.api.GoogleApiClient)">Games.Players.getPlayerSearchIntent()
  2. href="https://developers.google.com/android/reference/com/google/android/gms/games/Players.html?utm_campaign=product area_discussion_games_121616&utm_source=anddev&utm_medium=blog#loadConnectedPlayers(com.google.android.gms.common.api.GoogleApiClient,%20boolean)">Games.Players.loadConnectedPlayers()
  3. href="https://developers.google.com/android/reference/com/google/android/gms/games/Players.html?utm_campaign=product area_discussion_games_121616&utm_source=anddev&utm_medium=blog#loadInvitablePlayers(com.google.android.gms.common.api.GoogleApiClient,%20int,%20boolean)">Games.Players.loadInvitablePlayers()
  4. The value href="https://developers.google.com/android/reference/com/google/android/gms/games/leaderboard/LeaderboardVariant.html?utm_campaign=product area_discussion_games_121616&utm_source=anddev&utm_medium=blog#COLLECTION_SOCIAL">LeaderboardVariant.COLLECTION_SOCIAL
  5. href="https://developers.google.com/android/reference/com/google/android/gms/games/multiplayer/Invitations.html?utm_campaign=product area_discussion_games_121616&utm_source=anddev&utm_medium=blog#loadInvitations(com.google.android.gms.common.api.GoogleApiClient,%20int)">Invitations.loadInvitations()
  6. href="https://developers.google.com/android/reference/com/google/android/gms/games/multiplayer/realtime/RealTimeMultiplayer.html?utm_campaign=product area_discussion_games_121616&utm_source=anddev&utm_medium=blog#getSelectOpponentsIntent(com.google.android.gms.common.api.GoogleApiClient,%20int,%20int,%20boolean)">RealtimeMultiplayer.getSelectOpponentsIntent()
  7. href="https://developers.google.com/android/reference/com/google/android/gms/games/multiplayer/turnbased/TurnBasedMultiplayer.html?utm_campaign=product area_discussion_games_121616&utm_source=anddev&utm_medium=blog#getSelectOpponentsIntent(com.google.android.gms.common.api.GoogleApiClient,%20int,%20int,%20boolean)">TurnBasedMultiplayer.getSelectOpponentsIntent()
  8. All methods in the href="https://developers.google.com/android/reference/com/google/android/gms/games/request/GameRequest?utm_campaign=product area_discussion_games_121616&utm_source=anddev&utm_medium=blog">Requests
    package.


We realize this is a large change, but moving forward Play Game Services are
much better aligned with the rest of the Mobile platform from Google and will
lead to better developer experience for Android game developers.

Tuesday, December 13, 2016

Android Wear 2.0 for China - Developer Preview

Posted by Hoi Lam, Developer Advocate


Today at Google
Developer Day China
, we are happy to announce a href="https://developer.android.google.cn/wear/preview/?utm_campaign=android wear_launch_chinadeveloperpreview_121316&utm_source=anddev&utm_medium=blog">developer preview
of Android Wear 2.0 for developers creating apps for China. Android Wear 2.0 is
the biggest update since our partners launched their first devices in China last
year.



We're making a Developer Preview available today and plan to release additional
updates in the coming months. Please send us your feedback by href="http://g.co/wearpreviewbug">filing bugs or posting in our href="https://plus.google.com/communities/113381227473021565406">Android Wear
Developers community.


Developing for the Chinese Market



With Android Wear 2.0, apps can access the internet directly on Android Wear
devices. As a result, for the majority of apps, having a companion phone
application is no longer necessary. This means that most developers creating
apps for Android Wear 2.0 may no longer need to import the Google Play services
library.



There are two situations where developers will need to import Google Play
services for China:


  • Apps that require direct interaction with the paired mobile
    device
    - some experiences require Android Wear to connect directly to a
    paired phone. In this case, the href="https://developer.android.google.cn/training/wearables/data-layer/?utm_campaign=android wear_launch_chinadeveloperpreview_121316&utm_source=anddev&utm_medium=blog">Data
    Layer API introduced in Android Wear 1.0 will continue to function.
  • New href="https://developer.android.google.cn/training/articles/wear-location-detection.html?utm_campaign=building-for-wear-215&utm_source=dac&utm_medium=blog">FusedLocationProvider
    for China
    - we have added location detection to the SDK for Chinese
    developers. With the user's permission, your app can receive location updates
    via the FusedLocationProvider.


You can find more details about how to import the China compatible version of
Google Play services library href="https://developer.android.google.cn/training/wearables/apps/creating-app-china.html?utm_campaign=android wear_launch_chinadeveloperpreview_121316&utm_source=anddev&utm_medium=blog">here.


Product testing for Android Wear 2.0 for China



The Android Wear 2.0 Developer Preview includes an updated SDK with tools, and
system images for testing using the Huawei Watch.



To get started, follow these steps:


  • Update to Android Studio v2.1.1 or later
  • Visit the href="https://developer.android.google.cn/wear/preview/?utm_campaign=android wear_launch_chinadeveloperpreview_121316&utm_source=anddev&utm_medium=blog">Android Wear 2.0
    Developer Preview site for downloads and documentation
  • href="https://developer.android.google.cn/wear/preview/downloads.html?utm_campaign=android wear_launch_chinadeveloperpreview_121316&utm_source=anddev&utm_medium=blog">Download
    the device system images
  • Test your app with your supported device

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 don't be shy!




Android Wear 2.0 中国版 - 开发者预览版



编辑: 林海泉, Android Wear 开发平台负责人



今天在上海举办的Google
开发者大会
上,我们正式宣布了一款专门针对中国市场的Android Wear 2.0 href="https://developer.android.google.cn/wear/preview/">开发者预览版。Android Wear
2.0系统,将是自我们的合作伙伴首次发布手表产品以来最重大的更新。



开发者预览版已于今日正式上线。与此同时,我们也计划在未来的几个月内持续进行更新。请您将您遇到的问题在此href="http://g.co/wearpreviewbug">提交反馈,或者在我们的href="https://plus.google.com/communities/113381227473021565406">Android
Wear开发者论坛发表意见。


为中国市场开发应用



在Android Wear 2.0系统中,应用可以由Android
Wear手表直接连接至互联网。因此,对于大多数应用来说,手机端的伴侣应用也就变得不再必要。这也意味着,多数为Android Wear
2.0开发应用的开发者将不再需要引用Google Play services客户端库。



目前,在两个情况下开发者仍然需要引入Google Play Services客户端库来为中国市场开发应用:


  • 需要与手机直接进行通信的应用 - 有一些用例需要Android
    Wear手表与已配对手机直接连接。在这种情况下,Android Wear 1.0中引入的href="https://developer.android.google.cn/training/wearables/data-layer/">Data
    Layer API仍然可以继续使用。
  • 使用 href="https://developer.android.google.cn/training/articles/wear-location-detection.html?utm_campaign=building-for-wear-215&utm_source=dac&utm_medium=blog">FusedLocationProvider
    - 我们在最新的中国版SDK中加入了定位的支持。在用户的许可下,您的应用可以通过FusedLocationProvider来接收定位更新。


您可以在href="https://developer.android.google.cn/training/wearables/apps/creating-app-china.html">这里找到关于如何引入与中国版兼容的Google
Play service的更多信息。


Android Wear 2.0 中国版产品测试



Android Wear 2.0 开发者预览版包括最新的SDK套件,手表测试系统镜像(基于华为手表)。



情按照以下步骤进行测试:


  • 更新到Android Studio至v2.1.1以上版本
  • 访问 Android Wear
    2.0 开发者预览版
    ,那里的文件下载与文档下载部分
  • href="https://developer.android.google.cn/wear/preview/downloads.html">下载手表系统镜像
  • 在手表上测试您的应用

开发反馈



我们会根据您的反馈在未来的几个月中更新开发者预览版。您给我们的反馈越早,我们将会在最终的发布版本中包含更多针对您的反馈的解决方案。敬请期待!

Android Wear 2.0 Developer Preview 4: Authentication, In-App Billing, and more

Posted by Hoi Lam, Developer
Advocate




A key part of Android Wear 2.0 is letting
watch apps work as standalone apps, so users can respond to messages, track
their fitness, and use their favorite apps, even when their phone isn't around.
Developer Preview 4 includes a number of new APIs that will help you build more
powerful standalone apps.


Seamless authentication



To make authentication a seamless experience for both Android phone and iPhone
users, we have created new APIs for href="https://developer.android.com/wear/preview/features/auth-wear.html?utm_campaign=android wear_launch_developerpreview_121316&utm_source=anddev&utm_medium=blog">OAuth
and added support for one-click Google Sign-in. With the OAuth API for
Android Wear, users can tap a button on the watch that opens an authentication
screen on the phone. Your watch app can then authenticate with your server side
APIs directly. With Google Sign-In, it's even easier. All the user needs to do
is select which account they want to authenticate with and they are done.


In-app billing



In addition to paid apps, we have added href="https://developer.android.com/training/in-app-billing/index.html?utm_campaign=android wear_launch_developerpreview_121316&utm_source=anddev&utm_medium=blog">in-app
billing support, to give you another way to monetize your Android Wear app
or watch face. Users can authorize purchases quickly and easily on the watch
through a 4-digit Google Account PIN. Whether it's new levels in a game or new
styles on a watch face, if you can build it, users can buy it.


Cross-device promotion



What if your watch app doesn't work standalone? Or what if it offers a better
user experience when both the watch and phone apps are installed? We've been
listening carefully to your feedback, and we've added href="https://developer.android.com/wear/preview/features/standalone-apps.html?utm_campaign=android wear_launch_developerpreview_121316&utm_source=anddev&utm_medium=blog#detecting-your-app">two
new APIs (PlayStoreAvailability and RemoteIntent)
to help you navigate users to the Play Store on a paired device so they can
more easily install your app. Developers can also open custom URLs on the phone
from the watch via the new RemoteIntent API; no phone app or data
layer is required.



class="prettyprint">// Check Play Store is available
int playStoreAvailabilityOnPhone =
PlayStoreAvailability.getPlayStoreAvailabilityOnPhone(getApplicationContext());

if (playStoreAvailabilityOnPhone == PlayStoreAvailability.PLAY_STORE_ON_PHONE_AVAILABLE) {
// To launch a web URL, setData to Uri.parse("https://g.co/wearpreview")
Intent intent =
new Intent(Intent.ACTION_VIEW)
.addCategory(Intent.CATEGORY_BROWSABLE)
.setData(Uri.parse("market://details?id=com.google.android.wearable.app"));
// mResultReceiver is optional; it can be null.
RemoteIntent.startRemoteActivity(this, intent, mResultReceiver);
}

Swipe-to-dismiss is back



Many of you have given us the feedback that the swipe-to-dismiss gesture from
Android Wear 1.0 is an intuitive time-saver. We agree, and have reverted back to
the previous behavior with this developer preview release. To support
swipe-to-dismiss in this release, we've made the following platform and API
changes:


  • Activities now automatically support swipe-to-dismiss.
    Swiping an activity from left to right will result in it being dismissed and the
    app will navigate down the back stack.
  • New Fragment and View support. Developers can wrap the
    containing views of a Fragment or Views in general in the new
    SwipeDismissFrameLayout to implement custom actions such as going
    down the back stack when the user swipes rather than exiting the activity.
  • Hardware button now maps to "power" instead of "back" which
    means it can no longer be intercepted by apps.


Additional details are available under the href="https://developer.android.com/wear/preview/behavior-changes.html?utm_campaign=android wear_launch_developerpreview_121316&utm_source=anddev&utm_medium=blog">behavior
changes section of the Android Wear Preview site.


Compatibility with Android Wear 1.0 apps



Android Wear apps packaged using the legacy embedded app mechanism can now be
delivered to Android Wear 2.0 watches. When a user installs a phone app that
also contains an embedded Android Wear app, the user will be prompted to install
the embedded app via a notification. If they choose not to install the embedded
app at that moment, they can find it in the Play Store on Android Wear under a
special section called "Apps you've used".



Despite support for the existing mechanism, there are significant benefits for
apps that transition to the href="https://developer.android.com/wear/preview/features/app-distribution.html?utm_campaign=android_discussion_wearpreview_092916&utm_source=anddev&utm_medium=blog#publish">multi-APK
delivery mechanism. Multi-APK allows the app to be searchable in the Play
Store on Android Wear, to be eligible for merchandising on the homepage, and to
be remotely installed from the web to the watch. As a result, we strongly
recommend that developers move to multi-APK.


More additions in Developer Preview 4



  • href="https://developer.android.com/wear/preview/features/ui-nav-actions.html?utm_campaign=android wear_launch_developerpreview_121316&utm_source=anddev&utm_medium=blog">Action
    and Navigation Drawers: An enhancement to peeking behavior
    allows the user to take action without scrolling all the way to the top or
    bottom of a list. Developers can further fine-tune drawer peeking behavior
    through new APIs, such as setShouldPeekOnScrollDown for the action
    drawer.
  • href="https://developer.android.com/wear/preview/features/wearable-recycler-view.html?utm_campaign=android wear_launch_developerpreview_121316&utm_source=anddev&utm_medium=blog">WearableRecyclerView:
    The curved layout is now opt-in, and with this, the WearableRecyclerView is now
    a drop-in replacement for RecyclerView.
  • href="https://developer.android.com/wear/preview/features/complications.html?utm_campaign=android wear_launch_developerpreview_121316&utm_source=anddev&utm_medium=blog#using_fields_for_complication_data">Burn-in
    protection icon for complications: Complication data providers can now
    provide icons for use on screens susceptible to burn-in. These burn-in-safe
    icons are normally the outline of the icon in interactive mode. Previously,
    watch faces may have chosen not to display the icon at all in ambient mode to
    prevent screen burn-in.

Feedback welcome!



Thanks for all your terrific feedback on Android Wear 2.0. Check out href="http://g.co/wearpreview">g.co/wearpreview for the latest builds and
documentation, keep the feedback coming by href="http://g.co/wearpreviewbug">filing bugs or posting in our href="https://plus.google.com/communities/113381227473021565406">Android Wear
Developers community, and stay tuned for Android Wear Developer Preview 5!

Announcing updates to Google’s Internet of Things platform: Android Things and Weave


Posted by Wayne Piekarski,
Developer Advocate for IoT



The Internet of Things (IoT) will bring computing to a whole new range of
devices. Today we're announcing two important updates to our IoT developer
platform to make it faster and easier for you to create these smart, connected
products.



We're releasing a Developer Preview of Android Things, a comprehensive way to
build IoT products with the power of Android, one of the world's most supported
operating systems. Now any Android developer can quickly build a smart device
using Android APIs and Google services, while staying highly secure with updates
direct from Google. We incorporated the feedback from Project Brillo to include
familiar tools such as Android Studio, the Android Software Development Kit
(SDK), Google Play Services, and Google Cloud Platform. And in the coming
months, we will provide Developer Preview updates to bring you the
infrastructure for securely pushing regular OS patches, security fixes, and your
own updates, as well as built-in Weave connectivity and more.



There are several turnkey hardware solutions available for you to get started
building real products with Android Things today, including Intel Edison, NXP
Pico, and Raspberry Pi 3. You can easily scale to large production runs with
custom designs of these solutions, while continuing to use the same Board
Support Package (BSP) from Google.



We are also updating the Weave platform to make it easier for all types of
devices to connect to the cloud and interact with services like the Google
Assistant. Device makers like Philips Hue and Samsung SmartThings already use
Weave, and several others like Belkin WeMo, LiFX, Honeywell, Wink, TP-Link, and
First Alert are implementing it. Weave provides all the cloud infrastructure, so
that developers can focus on building their products without investing in cloud
services. Weave also includes a Device SDK for supported microcontrollers and a
management console. The Weave Device SDK currently supports schemas for light
bulbs, smart plugs and switches, and thermostats. In the coming months we will
be adding support for additional device types, custom schemas/traits, and a
mobile application API for Android and iOS. Finally, we're also working towards
merging Weave and Nest Weave to enable all classes of devices to connect with
each other in a secure and reliable way. So whether you started with Google
Weave or Nest Weave, there is a path forward in the ecosystem.




This is just the
beginning of the IoT ecosystem we want to build with you. To get started, check
out Google's IoT developer site,
or go directly to the Android
Things
, Weave,href="https://developers.google.com/weave"> and href="https://cloud.google.com">Google Cloud Platform sites for
documentation and code samples. You can also join href="http://g.co/iotdev">Google's IoT Developers Community on Google+ to
get the latest updates and share and discuss ideas with other developers.



Tuesday, December 6, 2016

Saving Data: Reducing the size of App Updates by 65%


Posted by Andrew Hayden, Software Engineer on Google Play



Android users are downloading tens of billions of apps and games on Google Play.
We're also seeing developers update their apps frequently in order to provide
users with great content, improve security, and enhance the overall user
experience. It takes a lot of data to download these updates and we know users
care about how much data their devices are using. Earlier this year, we
announced that we started using href="https://android-developers.blogspot.com/2016/07/improvements-for-smaller-app-downloads.html">the
bsdiff algorithm href="https://android-developers.blogspot.com/2016/07/improvements-for-smaller-app-downloads.html">(by
Colin Percival). Using bsdiff, we were able to reduce the size of app
updates on average by 47% compared to the full APK size.



Today, we're excited to share a new approach that goes further — href="https://github.com/andrewhayden/archive-patcher/blob/master/README.md">File-by-File
patching
.href="https://github.com/andrewhayden/archive-patcher/blob/master/README.md">
App Updates using File-by-File patching are, on average,
65% smaller than the full app, and in some cases more than 90%
smaller.



The savings, compared to our previous approach, add up to 6 petabytes of user
data saved per day!



In order to get the new version of the app, Google Play sends your device a
patch that describes the differences between the old and new versions
of the app.



Imagine you are an author of a book about to be published, and wish to change a
single sentence - it's much easier to tell the editor which sentence to change
and what to change, rather than send an entirely new book. In the same way,
patches are much smaller and much faster to download than the entire APK.



Techniques used in File-by-File
patching



Android apps are packaged as APKs, which are ZIP files with special conventions.
Most of the content within the ZIP files (and APKs) is compressed using a
technology called href="https://en.wikipedia.org/w/index.php?title=DEFLATE&oldid=735386036">Deflate.
Deflate is really good at compressing data but it has a drawback: it makes
identifying changes in the original (uncompressed) content really hard. Even a
tiny change to the original content (like changing one word in a book) can make
the compressed output of deflate look completely different. Describing
the differences between the original content is easy, but describing
the differences between the compressed content is so hard that it leads
to inefficient patches.



Watch how much the compressed text on the right side changes from a one-letter
change in the uncompressed text on the left:




File-by-File therefore is based on detecting changes in the uncompressed data.
To generate a patch, we first decompress both old and new files before computing
the delta (we still use bsdiff here). Then to apply the patch, we decompress the
old file, apply the delta to the uncompressed content and then recompress the
new file. In doing so, we need to make sure that the APK on your device is a
perfect match, byte for byte, to the one on the Play Store (see href="https://source.android.com/security/apksigning/v2.html">APK Signature
Schema v2 for why).



When recompressing the new file, we hit two complications. First, Deflate has a
number of settings that affect output; and we don't know which settings were
used in the first place. Second, many versions of deflate exist and we need to
know whether the version on your device is suitable.



Fortunately, after analysis of the apps on the Play Store, we've discovered that
recent and compatible versions of deflate based on zlib (the most popular
deflate library) account for almost all deflated content in the Play Store. In
addition, the default settings (level=6) and maximum compression settings
(level=9) are the only settings we encountered in practice.



Knowing this, we can detect and reproduce the original deflate settings. This
makes it possible to uncompress the data, apply a patch, and then recompress the
data back to exactly the same bytes as originally uploaded.



However, there is one trade off; extra processing power is needed on the device.
On modern devices (e.g. from 2015), recompression can take a little over a
second per megabyte and on older or less powerful devices it can be longer.
Analysis so far shows that, on average, if the patch size is halved then the
time spent applying the patch (which for File-by-File includes recompression) is
doubled.



For now, we are limiting the use of this new patching technology to auto-updates
only, i.e. the updates that take place in the background, usually at night when
your phone is plugged into power and you're not likely to be using it. This
ensures that users won't have to wait any longer than usual for an update to
finish when manually updating an app.



How effective is File-by-File
Patching?



Here are examples of app updates already using File-by-File Patching:
















Application


Original Size


Previous (BSDiff) Patch Size


(% vs original)


File-by-File Patch Size (% vs original)



71.1 MB


13.4 MB (-81%)


8.0 MB (-89%)



32.7 MB


17.5 MB (-46%)


9.6 MB (-71%)



17.8 MB


7.6 MB (-57%)


7.3 MB (-59%)



18.9 MB


17.2 MB (-9%)


13.1 MB (-31%)



52.4 MB


19.1 MB (-64%)


8.4 MB (-84%)



16.2 MB


7.7 MB (-52%)


1.2 MB (-92%)









Disclaimer: if you see different patch sizes when you press "update"
manually, that is because we are not currently using File-by-file for
interactive updates, only those done in the background.


Saving data and making our
users (& developers!) happy



These changes are designed to ensure our community of over a billion Android
users use as little data as possible for regular app updates. The best thing is
that as a developer you don't need to do anything. You get these reductions to
your update size for free!




If you'd like to know more about File-by-File patching, including the technical
details, head over to the href="https://github.com/andrewhayden/archive-patcher">Archive Patcher GitHub
project where you can find information, including the source code. Yes,
File-by-File patching is completely open-source!



As a developer if you're interested in reducing your APK size still further,
here are some href="https://developer.android.com/topic/performance/reduce-apk-size.html?utm_campaign=android_discussion_filebyfile_120616&utm_source=anddev&utm_medium=blog">general
tips on reducing APK size.


Monday, December 5, 2016

Welcoming Android 7.1.1 Nougat



Posted by Dave Burke, VP of Engineering





Android Nougat

Android 7.1.1 Nougat!





Today we're rolling out an update to Nougat -- Android 7.1.1 for Pixel and Pixel
XL devices and the full lineup of supported Nexus devices. We're also pushing
the Android 7.1.1 source code to the href="https://source.android.com/">Android Open Source Project (AOSP) so
that device makers can get their hands on the latest version of Android.



With Android 7.1.1 officially on it's way to users, it's a good time to make
sure your apps are ready.


What's in Android 7.1.1?



Android 7.1.1 is an incremental release that builds on the features already
available on Pixel and Pixel XL devices, adding a handful of new features for
consumers
as well as optimizations and bug fixes on top of the base Android 7.1
platform (API level 25).



If you haven't explored the developer features, you'll want to take a look at href="https://developer.android.com/guide/topics/ui/shortcuts.html">app shortcuts,
href="https://developer.android.com/about/versions/nougat/android-7.1.html?utm_campaign=android_launch_androidnougat_120516&utm_source=anddev&utm_medium=blog#circular-icons">round
icon resources, and href="https://developer.android.com/preview/image-keyboard.html?utm_campaign=android_launch_androidnougat_120516&utm_source=anddev&utm_medium=blog">image keyboard
support, among others -- you can see the href="https://developer.android.com/about/versions/nougat/android-7.1.html?utm_campaign=android_launch_androidnougat_120516&utm_source=anddev&utm_medium=blog">full list of
developer features here. For details on API Level 25, check out the href="https://developer.android.com/sdk/api_diff/25/changes.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">API
diffs and the href="https://developer.android.com/reference/packages.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">API
reference.



You can find an overview of all of the href="https://developer.android.com/about/versions/nougat/index.html">Android
Nougat developer resources here, including details on the core Android 7.0
Nougat behavior changes and developer features.c


Coming to consumer devices soon



We're starting the Android 7.1.1 rollout today, and we expect it to reach all
eligible devices over the next several weeks. Pixel and Pixel XL devices will
get the over-the-air (OTA) update, as will Nexus 5X, Nexus 6P, Nexus 6, Nexus 9,
Nexus Player, Pixel C, and General Mobile 4G (Android One) devices. Devices
enrolled in the Android Beta
Program
will receive the final version as well. As always, you can also
download and flash this
update manually
.



We've also been working with our device manufacturer partners to bring Android 7.1.1
to their devices in the months ahead.


Make sure your apps are ready



Take this opportunity to test your apps for compatibility and optimize them to
look their best on Android 7.1.1, such as by providing href="https://developer.android.com/about/versions/nougat/android-7.1.html?utm_campaign=android_launch_androidnougat_120516&utm_source=anddev&utm_medium=blog#circular-icons">round
icons and adding href="https://developer.android.com/guide/topics/ui/shortcuts.html?utm_campaign=android_launch_androidnougat_120516&utm_source=anddev&utm_medium=blog">app shortcuts.
We recommend compiling your app with, and ideally targeting, API 25. See our href="http://android-developers.blogspot.com/2016/11/final-update-to-android-7-1-developer-preview.html">recent
post for details.



With the final platform we’re updating the platform and build tools in Android Studio, as well as the
API Level 25 emulator system images. The latest
version of the support library (href="https://developer.android.com/topic/libraries/support-library/revisions.html?utm_campaign=android_launch_androidnougat_120516&utm_source=anddev&utm_medium=blog">25.0.1)
is also available for you to href="https://developer.android.com/reference/android/support/v13/view/inputmethod/InputConnectionCompat.OnCommitContentListener.html">add
image keyboard support, href="https://developer.android.com/reference/android/support/design/widget/BottomNavigationView.html?utm_campaign=android_launch_androidnougat_120516&utm_source=anddev&utm_medium=blog">bottom
navigation, and other features for devices running API Level 25 or earlier.



We're also providing downloadable factory and OTA images on the href="https://developers.google.com/android/images?utm_campaign=android_launch_androidnougat_120516&utm_source=anddev&utm_medium=blog">Nexus Images page to
help you do final testing on your Pixel and Nexus devices. To help scale your
testing, make sure to take advantage of href="http://android-developers.blogspot.com/2016/11/android-dev-preview-in-firebase-test-lab.html">Firebase
Test Lab for Android and run your tests in the cloud at no charge through
the end of December.



After your final testing, publish your apps to your alpha, href="https://developer.android.com/distribute/engage/beta.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">beta,
or production channels in the href="https://play.google.com/apps/publish/">Google Play Developer Console.


What's next?



We'll soon be closing open bugs logged against Developer Preview builds, but
please keep the feedback coming! If you still see an issue that you filed in the
preview tracker, just href="https://source.android.com/source/report-bugs.html">file a new issue
against Android 7.1 in the AOSP issue tracker. You can also continue to give us
feedback or ask questions in the href="https://plus.google.com/communities/105153134372062985968/stream/755bb91d-c101-4e32-9277-1e560c4e26d2">developer community.



As href="http://android-developers.blogspot.com/2016/08/taking-final-wrapper-off-of-nougat.html">mentioned
back in August, we've moved Android Nougat into a regular maintenance cycle
and we're already started work on refinements and bug fixes for the next
incremental update. If you have an eligible device that's currently enrolled in
the Android Beta Program, your
device will automatically receive preview updates of upcoming Android Nougat
releases as soon as they are available. If you don't want to receive those
updates, just visit the Beta
site
and unenroll the device.



Thanks for being part of the developer preview. Let us know how this year's
preview met your needs by taking a short
survey
. Your feedback helps to shape our future releases.