Android Things Developer Preview 6

Posted by Wayne Piekarski,
Developer Advocate for IoT

The next release of Android Things Developer Preview 6 (DP6) is here with lots
of new features and bug fixes. Android Things is Google's platform that enables
Android Developers to create Internet of Things (IoT) devices with support for
powerful applications such as video and audio processing and on-board machine
learning with TensorFlow. For the specifics on what is new, visit the href="https://developer.android.com/things/preview/releases.html">release
notes. Here are a few of the highlights of what is in DP6.

IoT launcher

DP6 includes a new IoT launcher that allows the user to see the current state of
the device and change settings using a touch screen or USB input devices.
Settings such as configuring the WiFi, finding the build ID, and checking for
updates is now something that can be done interactively, making it even easier
to get started. This launcher is visible when no other developer-provided href="https://developer.android.com/things/sdk/index.html#home_activity_support">IOT_LAUNCHER
Activity is present.

Graphics acceleration defaults

Android Things uses the open-source href="https://github.com/google/swiftshader">SwiftShader library, a
CPU-based implementation of the OpenGL ES APIs. This enables common OpenGL
support across all platforms, even those with no GPU hardware. However, many
simple 2D UIs render faster if the drawing is done directly to the framebuffer
and OpenGL emulation is not used. In DP6, OpenGL rendering is disabled by
default to ensure that most apps run with the fastest UI possible. If you need
OpenGL support for 3D rendering, WebView, or TextureView, then explicitly enable
it in your AndroidManifest.xml according to the href="https://developer.android.com/guide/topics/graphics/hardware-accel.html">documentation:

<activity

    ...
    android:hardwareAccelerated="true">

API 27 and Google Play Services

DP6 is now based on the latest Android 8.1 developer preview, with API level 27.
Most of the standard Android samples now work on DP6. For example, the href="https://github.com/googlesamples/android-Camera2Basic">Camera2Basic
sample using the Camera2 API and TextureView now works on both NXP and Raspberry
Pi based devices (with the hardwareAccelerated flag set to true). Google Play
Services has been updated to support SDK version 11.6, supporting all the href="https://developers.google.com/android/guides/releases">latest
features.

Command-line flashing tool

We heard from developers that flashing and configuring a board using fastboot
can be tedious, so the href="https://partner.android.com/things/console/#/tools">Android Things
Console now brings a new and simpler way of flashing device images. Instead
of using fastboot and adb commands manually, a new interactive command-line
href="https://partner.android.com/things/console/#/tools">android-things-setup-utility
is now provided. This tool makes it much easier to get started with Android
Things, and automates the download and flashing process.

Android Things Console updates

DP6 introduces the new partition scheme that will be used for the upcoming
production release. Due to the new partition layout, the over-the-air update
(OTA) system cannot update existing DP5.1 or earlier devices. Developers will
need to go to the Android
Things Console, and download and flash a new DP6 build. The Console UI has
also been changed for DP6 features, and will only allow you to create new builds
based on DP6. If you have any older existing builds, they are still available
for download but will not support OTA updates. Developers are encouraged to move
all work to DP6.

GPIO pin naming

The interactive IoT launcher shown at boot now includes an I/O pinout section
where you can discover the labels of all the pins. The pin naming used by the
i.MX7 has been changed, and you should update your code to use this new naming
convention. See the href="https://developer.android.com/things/hardware/imx7d-pico-io.html">i.MX7
documentation for the complete list of pin names.

Settings and Device Update APIs

New APIs have been added to Android Things that control the href="https://developer.android.com/things/sdk/apis/settings.html">configuration
of the local device and device href="https://developer.android.com/things/sdk/apis/update.html">updates. href="https://developer.android.com/things/reference/com/google/android/things/update/UpdateManager.html">UpdateManager
gives developers control over when updates and reboots can be performed,
ensuring the device is available for the user when needed. href="https://developer.android.com/things/reference/com/google/android/things/device/DeviceManager.html">DeviceManager
controls factory reset, reboot, and device locales. APIs are also provided for
settings such as href="https://developer.android.com/things/reference/com/google/android/things/device/ScreenManager.html">ScreenManager
to control the screen, and href="https://developer.android.com/things/reference/com/google/android/things/device/TimeManager.html">TimeManager
to control the clock and time zone.

Peripheral command-line tool

We now provide a command-line tool href="https://developer.android.com/things/sdk/pio/pio-cli.html">pio
that gives developers access to the Peripheral API via the adb shell. Developers
can interactively test GPIO, PWM, UART, I2C, SPI, and future interfaces from an
adb shell, which is useful for debugging and automated testing.

Feedback

DP6 includes significant changes and improvements to the platform. Please send
us your feedback by filing href="https://code.google.com/p/android/issues/entry?template=Android%20Things%20bug%20report">bug
reports and href="https://code.google.com/p/android/issues/entry?template=Android%20Things%20feature%20request">feature
requests, as well as asking any questions on href="http://stackoverflow.com/questions/tagged/android-things">Stack
Overflow. To start using DP6, use the href="https://partner.android.com/things/console">Android Things Console to
download system images and flash existing devices, or use the href="https://partner.android.com/things/console/#/tools">android-things-setup-utility.
More information about the changes are available in the href="https://developer.android.com/things/preview/releases.html">release
notes. You can also join Google's IoT
Developers Community on Google+, a great resource to get updates and discuss
ideas. Also, we have our new hackster.io
community, where everyone can share the amazing projects they have built. We
look forward to seeing what you build with Android Things!

Read more

Delve deeper into Android development with our new course!

Posted by Jocelyn Becker, Senior Program Manager, Google Developer Training

If you know the basics of building Android apps and want to delve deeper, take a
look at our new href="http://developers.google.com/training/courses/android-advanced">Advanced
Android Development course built by the Google Developers Training team.

Do you want to learn how to use fragments, add widgets for your app, and fine
tune your app's performance? Make your app available to a diverse user base
through localization and accessibility features? Use sensors in your app? How
about creating custom views, drawing directly to the screen and running
animations?

Each lesson in our new course takes you through building an app that illustrates
an advanced concept, from incorporating maps into your app to using a
SurfaceView to draw outside the main UI thread.

This course is intended for experienced Java programmers who already know the
fundamentals of building Android apps. It is a follow-on course to our href="https://developers.google.com/training/courses/android-fundamentals">Android
Developer Fundamentals course. The course is intended to be taught as
instructor-led training. However, all the materials are published online and are
available to anyone who wants to learn more advanced concepts of Android
development.

We have published detailed written href="https://google-developer-training.gitbooks.io/android-developer-advanced-course-practicals/content/">tutorials,
href="https://google-developer-training.gitbooks.io/android-developer-advanced-course-concepts/content/">concept
guides, slide decks, and most importantly, a treasure trove of href="https://github.com/google-developer-training/android-advanced">apps in
GitHub. You can find links to everything at href="https://developers.google.com/training/courses/android-advanced">developers.google.com/training/android-advanced.

Educational institutions worldwide are invited to use this course to teach your
students. Individual developers are welcome (and encouraged) to work through the
tutorials to learn on their own.

Each lesson presents a different, advanced topic, and you can teach or learn
each topic independently of the others.

Build apps as you learn how to use sensors, add places to your app, and draw
directly to a canvas. And much more!

The new course covers:

• using fragments
  
• building widgets
  
• using sensors
  
• measuring and improving application performance
  
• localizing your app
  
• making your app accessible
  
• adding location, places and maps to your apps
  
• creating custom views
  
• drawing to the canvas
  
• drawing to a SurfaceView off the main thread
  
• running animations

Learn more at href="https://developers.google.com/training/courses/android-advanced">developers.google.com/training/android-advanced.

Read more

Final preview of Android 8.1 now available

Posted by Dave Burke, VP of Engineering

Starting today we're rolling out an update to the Android 8.1 developer preview,
the last before the official launch to consumers in December. Android 8.1 adds
targeted enhancements to the Oreo platform, including optimizations for
Android Go (for devices with 1GB or less of memory) and a
Neural Networks API to accelerate on-device machine
intelligence. We've also included a few smaller enhancements to Oreo in response
to user and developer feedback.

If you have a device enrolled in the href="http://www.android.com/beta">Android Beta Program, you'll receive the
update over the next few days. If you haven't enrolled yet, just visit the href="http://www.android.com/beta">Android Beta site to enroll and get the
update.

At the official release in December we'll bring Android 8.1 to all supported
Pixel and Nexus devices worldwide -- including href="https://www.blog.google/products/pixel/new-pixel-2/">Pixel 2 and Pixel 2
XL, Pixel, Pixel XL, Pixel C, Nexus 5X, and Nexus 6P. Watch for
announcements soon.

What's in this update?

This preview update includes near-final Android 8.1 system images for Pixel and
Nexus devices, with official APIs (API level 27), the latest optimizations and
bug fixes, and the November 2017 security patch updates. You can use the images
for compatibility testing or to develop using new Android 8.1 features like the
href="https://developer.android.com/ndk/guides/neuralnetworks/index.html">Neural
Networks API and href="https://android-developers.googleblog.com/2017/10/android-81-developer-preview.html">others.

The Neural Networks API provides accelerated computation and inference for
on-device machine learning frameworks like href="https://www.tensorflow.org/mobile/tflite/">TensorFlow Lite -- Google's
cross-platform ML library for mobile -- as well as Caffe2 and others. TensorFlow
Lite is href="https://developers.googleblog.com/2017/11/announcing-tensorflow-lite.html">now
available to developers, so visit the href="https://github.com/tensorflow/tensorflow/tree/master/tensorflow/contrib/lite">TensorFlow
Lite open source repo for downloads and docs. TensorFlow Lite works with the
Neural Networks API to run models like href="https://research.googleblog.com/2017/06/mobilenets-open-source-models-for.html">MobileNets,
Inception v3, and href="https://research.googleblog.com/2017/11/on-device-conversational-modeling-with.html">Smart
Reply efficiently on your mobile device.

Also, for Pixel 2 users, the Android 8.1 update on these devices enables href="https://www.blog.google/products/pixel/pixel-visual-core-image-processing-and-machine-learning-pixel-2/">Pixel
Visual Core -- Google's first custom-designed co-processor for image
processing and ML -- through a new developer option. Once enabled, apps using
Android Camera API can capture HDR+ shots through Pixel Visual Core. See the href="https://developer.android.com/preview/release-notes.html#test-pixel">release
notes for details.

Get your apps ready

With the consumer launch coming href="https://developer.android.com/preview/overview.html">in December, it's
important to test your current app now. This ensures that users transition
seamlessly to Android 8.1 when it arrives on their devices.

Just enroll your eligible device in href="http://www.android.com/beta">Android Beta to get the latest update,
then install your app from Google Play and test. If you don't have a Pixel or
Nexus device, you can set up an Android 8.1 emulator for testing instead. If you
notice any issues, fix them and update your app in Google Play right away --
without changing the app's platform targeting.

When you're ready, take advantage of new features and APIs in Android 8.1. See
the developer
preview site, the href="https://developer.android.com/sdk/api_diff/27/changes.html">API 27 diff
report, and the updated
API reference for details.

Speed your development with Android Studio

To build with Android 8.1, we recommend updating to href="https://android-developers.googleblog.com/2017/10/android-studio-30.html">Android
Studio 3.0, which is now href="https://developer.android.com/studio/index.html">available from the stable
channel. On top of the new app href="https://developer.android.com/studio/profile/android-profiler.html">performance
profiling tools, support for the href="http://android-developers.googleblog.com/2017/05/android-announces-support-for-kotlin.html">Kotlin
programming language, and Gradle build optimizations, Android Studio 3.0
makes it easier to develop with Android Oreo features like href="https://android-developers.googleblog.com/2017/05/android-instant-apps-is-open-to-all.html">Instant
Apps, href="https://developer.android.com/guide/topics/ui/look-and-feel/downloadable-fonts.html">XML
Fonts, href="https://developer.android.com/guide/topics/ui/look-and-feel/downloadable-fonts.html">downloadable
fonts, and href="https://developer.android.com/guide/practices/ui_guidelines/icon_design_adaptive.html">adaptive
icons.

We also recommend updating to the href="https://developer.android.com/topic/libraries/support-library/revisions.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">Android
Support Library 27.0.0, which is available from href="https://developer.android.com/studio/build/dependencies.html#google-maven">Google's
Maven repository. See the href="https://developer.android.com/topic/libraries/support-library/revisions.html#27-0-0">version
notes for details on what's new.

Publish your updates to Google Play

Google Play is open for apps compiled against or targeting API 27. When you're
ready, you can publish your APK updates in your alpha, beta, or production
channels.

To make sure your app runs well on Android 8.1 as well as older versions, we
recommend using Google Play's href="https://developer.android.com/distribute/engage/beta.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">beta
testing feature to run an alpha test on small group of users. Then run a
much open beta test on a much larger group of users. When you're ready to launch
your update, you can use a href="https://developer.android.com/distribute/best-practices/launch/progressive-updates.html">staged
rollout in your production channel. We're looking forward to seeing your app
updates!

Give us your feedback

As always, your feedback is crucial, so please href="https://developer.android.com/preview/feedback.html">keep it coming!.
We've set up different hotlists where you can report href="https://issuetracker.google.com/issues/new?component=190602&template=1024208">Android
platform issues, href="https://issuetracker.google.com/issues/new?component=190602&template=808305">app
compatibility issues, and href="https://issuetracker.google.com/issues/new?component=190602&template=809305">third-party
SDKs and tools issues. We also have a dedicated hotlist for href="https://issuetracker.google.com/issues/new?component=190602&template=1024216">Neural
Networks API issues.

You can also give us feedback through the href="https://plus.google.com/communities/105153134372062985968/stream/755bb91d-c101-4e32-9277-1e560c4e26d2">Android
Developer community or href="https://plus.google.com/communities/106765800802768335079">Android Beta
community as we work towards the consumer release in December.

Read more

Moving Past GoogleApiClient

Posted by Sam Stern, Developer Programs Engineer

The release of version 11.6.0 of the Google Play services SDK moves a number of popular APIs to a new paradigm for accessing Google APIs on Android. We have reworked the APIs to reduce boilerplate, improve UX, and simplify authentication and authorization.

The primary change in this release is the introduction of new Task
and href="https://developers.google.com/android/reference/com/google/android/gms/common/api/GoogleApi">GoogleApi
based APIs to replace the GoogleApiClient access pattern.

The following APIs are newly updated to eliminate the use of
GoogleApiClient:

• Auth - updated the Google Sign In and Credentials APIs.
  
• Drive - updated the Drive and Drive Resource APIs.
  
• Fitness - updated the Ble, Config, Goals, History,
  Recording, Sensors, and Sessions APIs.
  
• Games - updated the Achievements, Events, Games, Games
  Metadata, Invitations, Leaderboards, Notifications, Player Stats, Players,
  Realtime Multiplayer, Snapshots, Turn Based Multiplayer, and Videos APIs.
  
• Nearby - updated the Connections and Messages
  APIs.

These APIs join others that made the switch in previous releases, such as the
Awareness, Cast, Places, Location, and Wallet APIs.

The Past: Using GoogleApiClient

Here is a simple Activity that demonstrates how one would access the Google
Drive API using GoogleApiClient using a previous version of the
Play services SDK:

class="prettyprint">public class MyActivity extends AppCompatActivity implements
GoogleApiClient.OnConnectionFailedListener,
GoogleApiClient.ConnectionCallbacks {

private static final int RC_SIGN_IN = 9001;

private GoogleApiClient mGoogleApiClient;

@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);

GoogleSignInOptions options =
new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
.requestScopes(Drive.SCOPE_FILE)
.build();

mGoogleApiClient = new GoogleApiClient.Builder(this)
.enableAutoManage(this, this)
.addConnectionCallbacks(this)
.addApi(Auth.GOOGLE_SIGN_IN_API, options)
.addApi(Drive.API)
.build();
}

// ...
// Not shown: code to handle sign in flow
// ...

@Override
public void onConnectionFailed(@NonNull ConnectionResult connectionResult) {
// GoogleApiClient connection failed, most API calls will not work...
}

@Override
public void onConnected(@Nullable Bundle bundle) {
// GoogleApiClient is connected, API calls should succeed...
}

@Override
public void onConnectionSuspended(int i) {
// ...
}

private void createDriveFile() {
// If this method is called before "onConnected" then the app will crash,
// so the developer has to manage multiple callbacks to make this simple
// Drive API call.
Drive.DriveApi.newDriveContents(mGoogleApiClient)
.setResultCallback(new ResultCallback<DriveApi.DriveContentsResult>() {
// ...
});
}
}

The code is dominated by the concept of a connection, despite using the
simplified "automanage" feature. A GoogleApiClient is only
connected when all APIs are available and the user has signed in (when APIs
require it).

This model has a number of pitfalls:

• Any connection failure prevents use of any of the requested APIs, but using
  multiple GoogleApiClient objects is unwieldy.
  
• The concept of a "connection" is inappropriately overloaded. Connection
  failures can be result from Google Play services being missing or from
  authentication issues.
  
• The developer has to track the connection state, because making some calls
  before onConnected is called will result in a crash.
  
• Making a simple API call can mean waiting for two callbacks. One to wait
  until the GoogleApiClient is connected and another for the API call
  itself.

The Future: Using GoogleApi

Over the years the need to replace GoogleApiClient became apparent,
so we set out to completely abstract the "connection" process and make it easier
to access individual Google APIs without boilerplate.

Rather than tacking multiple APIs onto a single API client, each API now has a
purpose-built client object class that extends GoogleApi. Unlike
with GoogleApiClient there is no performance cost to creating many
client objects. Each of these client objects abstracts the connection logic,
connections are automatically managed by the SDK in a way that maximizes both
speed and efficiency.

Authenticating with GoogleSignInClient

When using GoogleApiClient, authentication was part of the
"connection" flow. Now that you no longer need to manage connections, you
should use the new GoogleSignInClient class to initiate
authentication:

class="prettyprint">public class MyNewActivity extends AppCompatActivity {

private static final int RC_SIGN_IN = 9001;

private GoogleSignInClient mSignInClient;

@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);

GoogleSignInOptions options =
new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
.requestScopes(Drive.SCOPE_FILE)
.build();

mSignInClient = GoogleSignIn.getClient(this, options);
}

private void signIn() {
// Launches the sign in flow, the result is returned in onActivityResult
Intent intent = mSignInClient.getSignInIntent();
startActivityForResult(intent, RC_SIGN_IN);
}

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
super.onActivityResult(requestCode, resultCode, data);

if (requestCode == RC_SIGN_IN) {
Task<GoogleSignInAccount> task =
GoogleSignIn.getSignedInAccountFromIntent(data);
if (task.isSuccessful()) {
// Sign in succeeded, proceed with account
GoogleSignInAccount acct = task.getResult();
} else {
// Sign in failed, handle failure and update UI
// ...
}
}
}
}

Making Authenticated API Calls

Making API calls to authenticated APIs is now much simpler and does not require
waiting for multiple callbacks.

class="prettyprint"> private void createDriveFile() {
// Get currently signed in account (or null)
GoogleSignInAccount account = GoogleSignIn.getLastSignedInAccount(this);

// Synchronously check for necessary permissions
if (!GoogleSignIn.hasPermissions(account, Drive.SCOPE_FILE)) {
// Note: this launches a sign-in flow, however the code to detect
// the result of the sign-in flow and retry the API call is not
// shown here.
GoogleSignIn.requestPermissions(this, RC_DRIVE_PERMS,
account, Drive.SCOPE_FILE);
return;
}

DriveResourceClient client = Drive.getDriveResourceClient(this, account);
client.createContents()
.addOnCompleteListener(new OnCompleteListener<DriveContents>() {
@Override
public void onComplete(@NonNull Task<DriveContents> task) {
// ...
}
});
}

Before making the API call we add an inline check to make sure that we have
signed in and that the sign in process granted the scopes we require.

The call to createContents() is simple, but it's actually taking
care of a lot of complex behavior. If the connection to Play services has not
yet been established, the call is queued until there is a connection. This is in
contrast to the old behavior where calls would fail or crash if made before
connecting.

In general, the new GoogleApi-based APIs have the following
benefits:

• No connection logic, calls that require a connection are queued until a
  connection is available. Connections are pooled when appropriate and torn down
  when not in use, saving battery and preventing memory leaks.
  
• Sign in is completely separated from APIs that consume
  GoogleSignInAccount which makes it easier to use authenticated APIs
  throughout your app.
  
• Asynchronous API calls use the new Task API rather than
  PendingResult, which allows for easier management and
  chaining.

These new APIs will improve your development process and enable you to make
better apps.

Next Steps

Ready to get started with the new Google Play services SDK?

• Use
  GoogleSignInClient to add sign in to your Android app
  
• Use the Tasks
  API to control asynchronous operations

Happy building!

Read more

Google Play Referrer API: Track and measure your app installs easily and securely

Posted by Neto Marin, Developer Advocate

Understanding how people find your app and what they do once they've installed
it is crucial to helping you make the right product and marketing decisions.
This is especially important when you're deciding your advertising strategy and
budget. Today many app measurement companies and ad networks offer ad
attribution solutions based on referral data. As such accurate install referral
data is vital for correctly attributing app installs, as well as discounting
fraudulent attempts for install credit.

To help you obtain more accurate and reliable data about your installs, we're
introducing the Google Play Install Referrer API, a reliable
way to securely retrieve install referral content. Using this API, your app will
get precise information straight from the Play Store, including:

• The referrer URL of the installed package.
  
• The timestamp, in seconds, of when the referrer click happened.
  
• The timestamp, in seconds, of when the installation began.

We've tested the API with our href="https://www.google.com/adwords/appcampaigns/attribution/">App Attribution
Program partners including Adjust,
AppsFlyer, Singular and TUNE.

"The new Play API provides us with the data we need to effectively detect
and prevent click injection; it's a monumental step in securing a crucial
information exchange on Android."

- Paul Müller, CTO & Co-Founder, Adjust

"The new Google Play API introduces fresh insights into both mobile ad fraud
and the mobile user journey, two key domains with impact across the ecosystem."

- Elad Mashiach, VP, AppsFlyer

"This additional data directly from the Play Store provides increased precision for the Kochava fraud suite to further minimize fraud for our customers."

- Charles Manning, CEO, Kochava

"Google's new API is a game changer that will help marketing analytics
platforms like Singular identify and prevent a significant portion of Ad Fraud,
and provide security and accuracy to mobile advertisers"

- Gadi Eliashiv, CEO &
Co-Founder, Singular

"This new data from Google Play is essential for marketers who demand
accountability out of their mobile app install advertising spend. At TUNE, this
data is allowing us to outright eliminate entire forms of mobile app install
fraud while providing new insight into how mobile app installs are driven."

– Dan Koch, Chief Technical Officer, TUNE

Starting today, the API works with the Play Store app from version
8.3.73 and later for all developers.

Play Install Referrer Library 1.0 now available

To make it easy to integrate the Install Referrer API, we've released the
Install Referrer Library 1.0 for Android. The library is available in our Maven
repository. To start using it, add the following dependency to your app module
build.gradle file:

dependencies {
          ...
          compile 'com.android.installreferrer:installreferrer:1.0'
      }

All communication with the Play Store app happens through a Service, so the
first step is to establish the connection between your app and the Play Store.
Also, to receive the connection result and updates it's necessary to implement a
listener, InstallReferrerStateListener. This listener could be your
current Activity or any other class you want to use:

class="prettyprint">public class MainActivity extends AppCompatActivity
implements InstallReferrerStateListener {
…
}

Now that you have an InstallReferrerStateListener, you can start
binding your app to the Play Store app service. To establish the connection, you
must build an InstallReferrerClient instance and call the
startConnection() method:

class="prettyprint">InstallReferrerClient mReferrerClient
...
mReferrerClient = newBuilder(this).build();
mReferrerClient.startConnection(this);

Then, handle the connection result in the
onInstallReferrerSetupFinished() method. If the connection is OK,
the app can retrieve install referrer information, by calling the
getInstallReferrer() method:

class="prettyprint">@Override
public void onInstallReferrerSetupFinished(int responseCode) {
switch (responseCode) {
case InstallReferrerResponse.OK:
try {
Log.v(TAG, "InstallReferrer conneceted");
ReferrerDetails response = mReferrerClient.getInstallReferrer();
handleReferrer(response);
mReferrerClient.endConnection();
} catch (RemoteException e) {
e.printStackTrace();
}
break;
case InstallReferrerResponse.FEATURE_NOT_SUPPORTED:
Log.w(TAG, "InstallReferrer not supported");
break;
case InstallReferrerResponse.SERVICE_UNAVAILABLE:
Log.w(TAG, "Unable to connect to the service");
break;
default:
Log.w(TAG, "responseCode not found.");
}
}

For more details about the new API and the client library, visit the href="https://developer.android.com/google/play/installreferrer/library.html">Install
Referrer Client Library page and the href="https://developer.android.com/reference/com/android/installreferrer/">reference
documentation.

Other Implementations

If you are not able to use our client library, you can use the AIDL interface
and establish the connection with Google Play Store on your own. Check out the
href="https://developer.android.com/google/play/installreferrer/igetinstallreferrerservice.html">IGetInstallReferrerService
AIDL reference for details of the methods and the service
specification.

What's next?

Check out the href="https://developer.android.com/google/play/installreferrer/library.html">Play
Install Referrer API documentation for details about the new API, the href="https://developer.android.com/reference/com/android/installreferrer/">library's
reference docs, and our href="https://developer.android.com/google/play/installreferrer/library.html">Quick
Start guide.

Read more

Android Things Contest Winners

Posted by Dave Smith,
Developer Advocate for IoT

Back in September, we href="https://android-developers.googleblog.com/2017/09/android-things-hackster-contest.html">worked
with Hackster.io to encourage the developer community to build smart
connected devices using Android Things and post their projects to the href="https://www.hackster.io/contests/Google">Developer Challenge for Android
Things. The goal was to showcase the combination of turnkey hardware and a
powerful SDK for building and maintaining devices at scale.

Thank you to everyone who participated in the contest and submitted a project or
idea. We had over 1100 participants register for the contest, resulting in over
350 submissions. Out of that group, we've chosen three winners. Each winner will
receive support and tools from href="https://www.dragoninnovation.com/">Dragon Innovation to develop their
concepts into commercial products. Join us in congratulating the following
makers!

Best Enterprise Project: href="https://www.hackster.io/james-puderer/distributed-air-quality-monitoring-using-taxis-69647e">Distributed
Air Quality Monitoring

Maker: James
Puderer

Monitor air quality on a street-by-street level using Android Things, Google
Cloud IoT Core, and taxis!

This project showcases how Android Things makes it easy to build devices that
integrate with the various services provided by the Google Cloud Platform for
robust data collection and analysis. It's a clever end-to-end solution that
shows understanding of both the problem domain as well as the technology.

Best Start Up Project: href="https://www.hackster.io/iot-design-shop/brewcentral-great-tasting-all-grain-brewing-for-everyone-d7660a">BrewCentral

Maker: Trent Shumay and href="https://www.hackster.io/spridie">Steven Pridie

Brewing amazing beer is a balance of art, science, and ritual. The
BrewCentral system makes it possible for anyone to do an all-grain brew!

BrewCentral pairs a real-time PID controller with the touch-enabled UI and
decision-making compute power of Android Things. The result is a system that
accurately controls the time, temperature, and flow rates necessary to achieve
repeatable results during a brew cycle. The planned enhancements for cloud-based
brewing recipes will make this a connected experience for the entire brewing
community.

Best IoT Project: href="https://www.hackster.io/hitherejoe/braillebox-braille-news-reader-e86060">BrailleBox
- Braille News Reader

Maker: Joe Birch

BrailleBox is a small piece of hardware that empowers users who are
hard-of-sight to read the latest news articles in Braille.

This project is a great use case of using IoT to have a social impact. The
current proof of concept streams articles from a news feed to the Braille pad,
but this project has the potential to leverage machine learning on the device to
translate additional input from the physical world into a Braille result.

Honorable Mentions

The community submitted some amazing projects for the contest, which made the
choice of picking only three winners extremely difficult. Here are a few of our
favorite projects that weren't selected for a prize:

• Andro
  Cart: A shopping cart device powered by Android Things. Designed to help
  decentralize point of sale (POS) billing.
  
• SIGHT:
  For the Blind: A pair of smart glasses for the blind, powered by Android
  Things and TensorFlow.
  
• href="https://www.hackster.io/mhanuel/industrial-iot-gateway-based-on-android-things-c680d1">Industrial
  IoT Gateway: A smart industrial gateway for the IoT world based on Android
  Things.
  
• href="https://www.hackster.io/oscarsalguero/sentinel-8234b3">Sentinel: The
  first semi-autonomous home security robot based on Android Things.
  
• href="https://www.hackster.io/daniele-bonaldo/android-things-word-clock-46cc14">Word
  Clock: A creative take on reading the time, powered by Android Things.
  Control it via the Nearby API or the Google Assistant.

We encourage everyone to check out all the new projects in the href="https://www.hackster.io/google/products/android-things?sort=trending">Google
Hackster community, and submit your own as well! You can also join href="https://g.co/iotdev">Google's IoT Developers Community on Google+, a
great resource to get updates, ask questions, and discuss ideas. We look forward
to seeing what exciting projects you build!

Read more

Getting your Android app ready for Autofill

Posted by Wojtek Kalicinski, Android Developer Advocate, Akshay Kannan,
Product Manager for Android Authentication, and Felipe Leme, Software Engineer on Android Frameworks

Starting in Oreo, Autofill makes it easy for users to provide credit cards,
logins, addresses, and other information to apps. Forms in your apps can now be
filled automatically, and your users no longer have to remember complicated
passwords or type the same bits of information more than once.

Users can choose from multiple Autofill services (similar to keyboards today).
By default, we include Autofill with Google, but users can also select any third
party Autofill app of their choice. Users can manage this from
Settings->System->Languages>Advanced->Autofill service.

What's available today

Today, Autofill with Google supports filing credit cards, addresses, logins,
names, and phone numbers. When logging in or creating an account for the first
time, Autofill also allows users to save the new credentials to their account.
If you use WebViews in your app, which many apps do for logins and other
screens, your users can now also benefit from Autofill support, as long as they
have Chrome 61 or later installed.

The Autofill API is open for any developer to implement a service. We are actively
working with href="https://support.1password.com/android-autofill/#set-up-autofill">1Password,
href="https://blog.dashlane.com/introducing-dashlane-support-for-android-o-autofill-api/">Dashlane,
href="https://blog.keepersecurity.com/2017/09/06/android-o-customers-now-have-the-support-they-need-to-autofill-apps-with-keeperfill/">Keeper,
and href="https://blog.lastpass.com/2017/08/lastpass-public-beta-android-oreo.html/">LastPass
to help them with their implementations and will be working with other password managers shortly.
We are also creating a new curated collection on the Play Store, which the "Add service" button in Settings will link to. If you
are a password manager developer and would like us to review your app, please href="https://docs.google.com/forms/d/e/1FAIpQLScem3Xhk4991YKhX3YtPUZ7_YSuFZGacdH5r5yFO8lrSMQNqA/viewform?usp=sf_link">get
in touch.

What you need to do as a developer

As an app developer, there are a few simple things you can do to take advantage
of this new functionality and make sure that it works in your apps:

Test your app and annotate your views if needed

In many cases, Autofill may work in your app without any effort. But to ensure
consistent behavior, we recommend providing explicit hints to tell the framework
about the contents of your field. You can do this using either the href="https://developer.android.com/guide/topics/text/autofill.html#providing_hints_for_autofill">android:autofillHints
attribute or the href="https://developer.android.com/guide/topics/text/autofill.html#providing_hints_for_autofill">setAutofillHints()
method.

Similarly, with WebViews in your apps, you can use HTML href="https://developers.google.com/web/updates/2015/06/checkout-faster-with-autofill">Autocomplete
Attributes to provide hints about fields. Autofill will work in WebViews as
long as you have Chrome 61 or later installed on your device. Even if your app
is using custom views, you can also href="https://developer.android.com/guide/topics/text/autofill.html#custom_views_with_standard_view_structure">define
the metadata that allows autofill to work.

For views where Autofill does not make sense, such as a Captcha or a message
compose box, you can explicitly mark the view as href="https://developer.android.com/guide/topics/text/autofill.html#mark_fields_as_important_for_autofill">IMPORTANT_FOR_AUTOFILL_NO
(or href="https://developer.android.com/guide/topics/text/autofill.html#mark_fields_as_important_for_autofill">IMPORTANT_FOR_AUTOFILL_NO_EXCLUDE_DESCENDANTS
in the root of a view hierarchy). Use this field responsibly, and remember that
users can always bypass this by long pressing an EditText and selecting
"Autofill" in the overflow menu.

Affiliate your website and mobile app

Autofill with Google can seamlessly share logins across websites and mobile apps
‒ passwords saved through Chrome can also be provided to native apps. But in
order for this to work, as an app developer, you must explicitly declare the
association between your website with your mobile app. This involves 2 steps:

Step 1: Host a JSON file at
yourdomain.com/.well-known/assetlinks.json

If you've used technologies like App Links or Google Smart Lock before, you
might have heard about the Digital Asset Links (DAL) file. It's a JSON file
placed under a well known location in your website that lets you make public,
verifiable statements about other apps or websites.

You should follow the href="https://developers.google.com/identity/smartlock-passwords/android/associate-apps-and-sites">Smart
Lock for Passwords guide for information about how to create and host the
DAL file correctly on your server. Even though Smart Lock is a more advanced way
of signing users into your app, our Autofill service uses the same
infrastructure to verify app-website associations. What's more, because DAL
files are public, third-party Autofill service developers can also use the
association information to secure their implementations.

Step 2: Update your App's Manifest with the same
information

Once again, follow the href="https://developers.google.com/identity/smartlock-passwords/android/associate-apps-and-sites">Smart
Lock for Passwords guide to do this, under "Declare the association in the
Android app."

You'll need to update your app's manifest file with an asset_statements
resource, which links to the URL where your assetlinks.json file is hosted. Once
that's done, you'll need to submit your updated app to the Play Store, and fill
out the href="https://docs.google.com/forms/d/e/1FAIpQLSc3FCn8ccGpgXd1jtLBVRlNJ6EhWQK50hNO5jT_9nuqHI79pg/viewform">Affiliation
Submission Form for the association to go live.

When using Android Studio 3.0, the App Links Assistant can generate all of this
for you. When you open the DAL generator tool (Tools -> App Links Assistant ->
Open Digital Asset Links File Generator), simply make sure you enable the new
checkbox labeled "Support sharing credentials between the app and website".

Then, click on "Generate Digital Asset Links file", and copy the preview content
to the DAL file hosted on your server and in your app. Please remember to verify
that the selected domain names and certificates are correct.

Future work

It's still very early days for Autofill in Android. We are continuing to make
some major investments going forward to improve the experience, whether you use
Autofill with Google or a third party password manager.

Some of our key areas of investment include:

1. Autofill with Google: We want to provide a great experience
   out of the box, so we include Autofill with Google with all Oreo devices. We're
   constantly improving our field detection and data quality, as well as expanding
   our support for saving more types of data.
   
2. WebView support: We introduced initial support for filling
   WebViews in Chrome 61, and we'll be continuing to test, harden, and make
   improvements to this integration over time, so if your app uses WebViews you'll
   still be able to benefit from this functionality.
   
3. Third party app support: We are working with the ecosystem
   to make sure that apps work as intended with the Autofill framework. We urge you
   as developers to give your app a spin on Android Oreo and make sure that things
   work as expected with Autofill enabled. For more info, see our full
   documentation on the href="https://developer.android.com/guide/topics/text/autofill.html">Autofill
   Framework.

If you encounter any issues or have any suggestions for how we can make this
better for you, please href="https://docs.google.com/forms/d/e/1FAIpQLScem3Xhk4991YKhX3YtPUZ7_YSuFZGacdH5r5yFO8lrSMQNqA/viewform?usp=sf_link">send
us feedback.

Read more

How the Pixel 2’s security module delivers enterprise-grade security

Posted by Xiaowen Xin, Android Security Team

The new Google Pixel 2 ships with a dedicated hardware security module designed to be robust against physical attacks. This hardware module performs lockscreen passcode verification and protects your lock screen better than software alone.

To learn more about the new protections, let's first review the role of the lock screen. Enabling a lock screen protects your data, not just against casual thieves, but also against sophisticated attacks. Many Android devices, including all Pixel phones, use your lockscreen passcode to derive the key that is then used to encrypt your data. Before you unlock your phone for the first time after a reboot, an attacker cannot recover the key (and hence your data) without knowing your passcode first. To protect against brute-force guessing your passcode, devices running Android 7.0+ verify your attempts in a secure environment that limits how often you can repeatedly guess. Only when the secure environment has successfully verified your passcode does it reveal a device and user-specific secret used to derive the disk encryption key.

Benefits of tamper-resistant hardware

The goal of these protections is to prevent attackers from decrypting your data without knowing your passcode, but the protections are only as strong as the secure environment that verifies the passcode. Performing these types of security-critical operations in tamper-resistant hardware significantly increases the difficulty of attacking it.

Tamper-resistant hardware comes in the form of a discrete chip separate from the System on a Chip (SoC). It includes its own flash, RAM, and other resources inside a single package, so it can fully control its own execution. It can also detect and defend against outside attempts to physically tamper with it. In particular:

• Because it has its own dedicated RAM, it's robust against many side-channel information leakage attacks, such as those described in the TruSpy cache side-channel paper.
  
• Because it has its own dedicated flash, it's harder to interfere with its ability to store state persistently.
  
• It loads its operating system and software directly from internal ROM and flash, and it controls all updates to it, so attackers can't directly tamper with its software to inject malicious code.
  
• Tamper-resistant hardware is resilient against many physical fault injection techniques including attempts to run outside normal operating conditions, such as wrong voltage, wrong clock speed, or wrong temperature. This is standardized in specifications such as the SmartCard IC Platform Protection Profile, and tamper-resistant hardware is often certified to these standards.
  
• Tamper-resistant hardware is usually housed in a package that is resistant to physical penetration and designed to resist side channel attacks, including power analysis, timing analysis, and electromagnetic sniffing, such as described in the SoC it to EM paper.

Security module in Pixel 2

The new Google Pixel 2 ships with a security module built using tamper-resistant hardware that protects your lock screen and your data against many sophisticated hardware attacks.

In addition to all the benefits already mentioned, the security module in Pixel 2 also helps protect you against software-only attacks:

1. Because it performs very few functions, it has a super small attack surface.
   
2. With passcode verification happening in the security module, even in the event of a full compromise elsewhere, the attacker cannot derive your disk encryption key without compromising the security module first.
   
3. The security module is designed so that nobody, including Google, can update the passcode verification logic to a weakened version without knowing your passcode first.

Summary

Just like many other Google products, such as Chromebooks and Cloud, Android and Pixel are investing in additional hardware protections to make your device more secure. With the new Google Pixel 2, your data is safer against an entire class of sophisticated hardware attacks.

Read more

10 things you might be doing wrong when using the SafetyNet Attestation API

Posted by Oscar Rodriguez, Developer Advocate

The
SafetyNet Attestation API helps you assess the security and compatibility of
the Android environments in which your apps run. Since it was introduced in
March 2015, many developers have successfully integrated it into their Android
apps to make more informed decisions based on the integrity and compatibility of
the devices running their apps.

Throughout the years, the SafetyNet Attestation API has evolved, and its
adoption has steadily increased. However, as with any security/anti-abuse
related API, there are many common pitfalls that may lead developers into
developing unstable systems, or worse, into a false sense of security.

In this post, we provide a list of the most common mistakes we have seen
developers make when integrating the SafetyNet Attestation API.

1. Not getting an API key

Just like many other Google APIs, the SafetyNet Attestation API requires an API
key in order to run. Furthermore, the SafetyNet Attestation API has a per-key
usage quota. Although you can get this quota increased, you need to provide your
API key to do so.

Getting an API key is easy and free of charge. There is no reason not to get an
API key, so if you haven't already, href="https://developer.android.com/training/safetynet/attestation.html#add-api-key">get
an API key now.

2. Not using the latest version of the API

The SafetyNet Attestation API has evolved throughout its history, and with it,
there have been some interface changes. Most recently, with the release of
Google Play services 11.0.0, we revamped the entire SafetyNet API to offer an
interface that is easier and more streamlined to use: the new API uses href="https://developers.google.com/android/reference/com/google/android/gms/safetynet/SafetyNetClient">SafetyNetClient
instead of href="https://developers.google.com/android/reference/com/google/android/gms/safetynet/SafetyNetApi">SafetyNetApi,
which is now deprecated, so make sure you update your implementation to use the
latest version of the API.

Most devices should have the latest version of Google Play services installed,
but if a device doesn't have Google Play services installed, or doesn't have it
up to date, using the SafetyNet Attestation API may lead to the app becoming
unresponsive or crashing. You can prevent this by href="https://developer.android.com/training/safetynet/attestation.html#check-gps-version">checking
the installed version of Google Play services before using the API.

3. Using nonces incorrectly

The SafetyNet Attestation API lets you set a nonce to uniquely and globally
identify each call to the API. Use this feature to prevent a malicious user from
reusing a successful attestation result in place of an unsuccessful result (also
known as a Replay
Attack).

href="https://developer.android.com/training/safetynet/attestation.html#single-use-token">One
good way to create a nonce is to create a large (16 bytes or longer) random
number on your server using a cryptographically-secure random function. The
SafetyNet attestation response includes the nonce you set, so make sure you
verify that the returned nonce matches the one you included in the request you
made.

4. Not checking the results on your server

SafetyNet can provide useful signals about the state of the device in which your
app is running. However, if the logic that acts on these signals is only
implemented and enforced directly on the device, an attacker could be able to
modify your app and bypass any checks you perform.

To prevent this situation, you should run any logic that verifies the
attestation result and enforces any actions based on them on a server that you
control and trust.

5. Using the test attestation verification service for production

In order to simplify development and testing of the SafetyNet Attestation API,
Google offers an href="https://developer.android.com/training/safetynet/attestation.html#verify-compat-check">online
verification service that checks the digital signature of a SafetyNet
Attestation result using a simple HTTPS request.

As useful as this service may seem, it is designed for test purposes only, and
it has very strict usage quotas that will not be increased upon request.
Instead, you should implement the digital signature verification logic on your
server in a way that it doesn't depend on Google's servers. Most JWT libraries
offer signature verification functionality, and we have href="https://github.com/googlesamples/android-play-safetynet">code samples
that show how to perform this verification in Java and C#. We plan to provide
samples for more languages in the future.

6. Not checking the nonce, timestamp, APK name, and hashes

The SafetyNet Attestation API is most widely known for its integrity and
compatibility checks, whose results are returned in ctsProfileMatch
and basicIntegrity. Although these two values are indeed very
useful, you should check the other values in the response, as they contain
important information as well.

Use nonce to match a response to its request,
as explained above, and use timestampMs to check how much time has passed since you made the
request and you got the response. A delayed response that arrives several hours
or days after the request may suggest suspicious activity.

Use apkPackageName to check the name of the APK that made the
attestation request, and match apkDigestSha256 and
apkCertificateDigestSha256 to those from your app's signed APK in
Google Play, to get a signal about the integrity of the installed app.

Remember that the trustworthiness of the response as a whole is tied to the
results of ctsProfileMatch and basicIntegrity. It is
not unthinkable for a compromised device that fails basicIntegrity
to have forged the rest of the values in the response.

7. Not understanding the differences between ctsProfileMatch
and basicIntegrity

The SafetyNet Attestation API initially provided a single value called
basicIntegrity to help developers determine the integrity of a
device. As the API evolved, we introduced a new, stricter check whose results
appear in a value called ctsProfileMatch, which allows developers
to more finely evaluate the devices on which their app is running.

In broad terms, basicIntegrity gives you a signal about the general
integrity of the device and its API. Rooted devices fail
basicIntegrity, as do emulators, virtual devices, and devices with
signs of tampering, such as API hooks.

On the other hand, ctsProfileMatch gives you a much stricter signal
about the compatibility of the device. Only unmodified devices that
have been certified by Google can pass ctsProfileMatch. Devices
that will fail ctsProfileMatch include the following:

• Devices that fail basicIntegrity
  
• Devices with an unlocked bootloader
  
• Devices with a custom system image (custom ROM)
  
• Devices for which the manufactured didn't apply for, or pass, Google
  certification
  
• Devices with a system image built directly from the href="https://source.android.com/">Android Open Source Program source files
  
• Devices with a system image distributed as part of a beta or developer
  preview program (including the href="https://www.google.com/android/beta">Android Beta Program)

8. Not having a strategy for timing attestation checks

The SafetyNet Attestation API gives you a snapshot of the state of a device at
the moment when the attestation request was made. A successful attestation
doesn't necessarily mean that the device would have passed attestation in the
past, or that it will in the future.

Because an attestation is just a spot check, you should plan a sensible strategy
for choosing when to make attestation requests. You may choose to require
successful attestations before users make in-app purchases, after a certain
number of days have passed since the last successful attestation, each time your
app is launched, after every reboot, or any other strategy that makes sense for
your app.

Keep in mind that an attestation request is computationally expensive, consumes
battery and bandwidth, and uses your quota. We recommend you plan a strategy to
use the least amount of attestations required to satisfy your use case.

9. Using the SafetyNet Attestation API results as the only signal
to attack abuse

It may be tempting to think that the SafetyNet Attestation API provides all the
necessary signals for protecting an app against abusers, and use it as the only
signal for building an anti-abuse system.

The SafetyNet Attestation API can only give signals about the state of
a device, not the intent of a user, which is what an anti-abuse system
should be designed to detect. Therefore, you might want to consider including
other signals, such as access logs and behavioral patterns, to more accurately
detect abusive users, and consider not blocking users solely on a failed
attestation. Furthermore, there are many other conditions that cause an
attestation to fail, such as network connection problems, quota issues, and
other transient problems.

In other words, not all users who fail attestation are necessarily abusers, and
not all abusers will necessarily fail attestation. By blocking users solely on
their attestation results, you might be missing abusive users that don't fail
attestations. Furthermore, you might also be blocking legitimate, loyal
customers who fail attestations for reasons other than abuse.

10. Not monitoring and managing your usage quota

As mentioned before, href="https://developer.android.com/training/safetynet/attestation.html#add-api-key">the
SafetyNet Attestation API is rate limited, and there is a default quota of
10,000 requests per day for each API key. Although this quota might be enough
for most development, testing, and initial app launches, your app might reach
the default limit as it increases in popularity.

To prevent inadvertently reaching your quota and getting attestation errors, you
should build a system that monitors your usage of the API and warns you well
before you reach your quota so you can get it increased. You should also be
prepared to handle attestation failures because of an exceeded quota and avoid
blocking all your users in this situation.

If you are close to reaching your quota, or expect a short-term spike that may
lead you to exceed your quota, you can submit
this form to request short or long-term increases to the quota for your API
key. This process, as well as the additional quota, is free of charge.

Read more

Making Pixel better for Drivers

Posted by Marc Stogaitis and Tajinder Gadh, Software Engineers

Driving is an essential part of our daily activities. So at Google we spend a
lot of time thinking how we can make Android devices better and safer for our
users. How we can prevent distracted driving and together build an open
ecosystem to enable safety first smartphone experiences.


Recently we launched Driving Do-Not-Disturb on the newly announced Pixel 2
generation of devices. Once enabled, Driving Do-Not-Disturb automatically puts
your device into a do not disturb mode while driving. During this mode any
incoming messages and notifications are silenced while you can still receive
incoming calls, navigation directions and voice interactions using a connected
Car bluetooth. The product is designed to limit distractions during driving
while at the same time not getting in the way so users can continue to use
navigation or other similar apps with minimal friction.


Behind the scenes, it uses AI powered on-device Activity
Recognition that detects when a person is driving using low power signals
from multiple sensors, bluetooth and WiFi. Activity Recognition uses the Android
Sensor Hub to ensure low latency, low power and accurate driving detection.


This is a next step in our journey, but we are far from done. Early next year
we are introducing the Activity Recognition Transition API, which is the same
API used by Driving Do Not Disturb to build distraction-free driving
experiences.


We appreciate the feedback, and will continue to listen to your feedback as the
product evolves.


If you have questions about setting up the Driving Do-Not-Disturb, check out our
Help Center.

Read more

Google and Ideas United announce Infinite Deviation: Games winners

Posted by Kate Brennan and Mathilde Cohen Solal, Google Play and Daraiha Greene, CS in Media

Google Play is committed to empowering new and existing voices in gaming. Earlier this year, we hosted the Indie Games Festival and sponsored the Girls Make Games href="https://plus.google.com/u/0/+GoogleDevelopers/posts/fH3NMC6gSRT">summer camp. We also href="https://android-developers.googleblog.com/2017/09/google-and-ideas-united-launch-program.html">announced a collaboration between Infinite Deviation and Google Play.

Infinite Deviation is an initiative created by Google Computer Science (CS) in Media and href="http://ideasunited.com/">Ideas United in order to tackle issues of representation in computer science. The collaboration between Google Play and Ideas United brought the Infinite Deviation program to gaming, called Infinite Deviation: Games. The program invited game designers from all backgrounds to pitch an original mobile game concept that resonates with underrepresented audiences.

Today we are excited to announce the three teams selected for the Infinite Deviation: Games development program.

A select panel of industry experts reviewed applications and chose the top three ideas. The judging panel included Colleen Macklin (Founder and Co-Director, PETLab), Jeremy Vanhoozer (Senior Creative Director, Plants vs Zombies), Molly Proffitt (CEO, Ker-Chunk Games), Shirin Laor-Raz Salemnia (Founder and CEO, PlayWerks), and Sarah Thomson (Global BD Lead, Indies, Google). These judges scored and delivered personal feedback for each submission, with the three highest scoring games moving into further development.

Here's a closer look at the three games we'll be funding and supporting development over the next six months:

Historic Gay Bar Tycoon

Mo Cohen & Maria Del Castillo Infantas - Queermo Games

Historic Gay Bar Tycoon (name pending) starts you off with a brand new queer bar in the 1920s. This game explores the role bars played in LGBT history. Will your bar survive revolutions, epidemics, and the rise of dating apps?

Queermo Games is pretty much what it sounds like: a scrappy and small indie game developing team just trying to make more LGBT games. Conveniently, they are also next door neighbors. Maria is a queer Latina who handles the art and the music, and Mo is a non-binary Jewish queer who tackles the programming and writing. Together, they also work on another longer-term project called Queer Quest with their buddy Hagen.

Burn Ban

Harrison Barton & Morgan Rowe - Pride Interactive

Burn Ban is an interactive visual novel in which you assume the role of Twig, a mentally ill queer girl. After showing destructive tendencies to cope with the death of a close friend, she is sent to Camp Sisquoc, a summer retreat for misguided students. After attending the camp for a few days, her dead friend's online social media page mysteriously starts posting again, and Twig and friends are set with determining the mystery behind the posts.

Pride Interactive is currently made up of two developers, Harrison Barton and Morgan Rowe. Pride Interactive was started as a student game team, and is now continuing on to develop independent projects. Pride Interactive endeavors to further their mission of creating a more diverse environment in the industry through games that deal with serious themes, and diverse character driven narratives.

Ghost in the Graveyard

Adnan Agha, Vivian Allum, and Armand Silvani - Ghost Stories

Ghost in the Graveyard is a story-driven mobile mystery game where you snoop through your missing brother's old phone to try and find him. "Can you find a missing person when all you have is their phone?"

Ghost Stories is a three member team from NYC with a mission to create genuine and unique experiences that connect with players. The team consists of Vivian, the lead designer and programmer, Armand, the artist and writer, and Adnan, the programmer and resident ghost. They've previously published a school project to the Xbox One and are thrilled to be able to work with Infinite Deviation to publish to Google Play.

You can find more information about the program at InfiniteDeviation.com/Games. Congratulations to the three winners and thanks to all the people who have entered the competition for their continuous work to push the boundaries of gaming design and providing a unique voice to the industry.

Read more

Announcing Architecture Components 1.0 Stable

Posted by Lukas Bergstrom, Product Manager, Android Developer Frameworks Team

Android runs on billions of devices, from high-end phones to airplane seatbacks. The Android OS manages resources aggressively to perform well on this huge range of devices, and sometimes that can make building robust apps complicated. To make it easier, we launched a preview of Architecture Components at Google I/O to provide guidance on app architecture, with libraries for common tasks like lifecycle management and data persistence. Together, these foundational components make it possible to write modular apps with less boilerplate code, so developers can focus on innovating instead of reinventing the wheel - and we hope to keep building on this foundation in the future.

Today we're happy to announce that the Room and Lifecycle href="http://developer.android.com/arch">Architecture Components libraries have reached 1.0 stable. These APIs are ready for production apps and libraries, and are our recommendation for developers looking for help with app architecture and local storage (although they're only recommended, not required.) Lifecycles are now also integrated with the href="https://developer.android.com/topic/libraries/support-library/index.html">Support Library, so you can use them with standard classes like AppCompatActivity.

Although we're declaring them stable today, the beta components are already used in apps that together, have billions of installs. Top developers, like Zappos, have been able to spend more time on what's important thanks to Architecture Components:

Prior to the release of Android Architecture Components we had our own ViewModel implementation. We used Loaders and Dependency Injection to persist our ViewModel through config changes. We recently switched to the Architecture Components ViewModel implementation and all that boilerplate went away. We found that we were able to spend more time on design, business logic and testing, and less on writing boilerplate or worrying about Android lifecycle issues.

We've also started to use LiveData which hooks directly into the Activity lifecycle. We use it to retrieve and display network data and no longer have to concern ourselves with ​network call subscription management.

- David Henry, Android Software Engineer, Zappos

Architecture Components provide a simple, flexible and practical approach that frees developers from some common problems so they can focus on building great experiences. This is based on core building blocks tied together by guidance on app architecture.

Lifecycles

Every Android developer has to deal with the operating system starting, stopping and destroying their Activities. That means managing the state of components - such as observables used to update UI - as you move through the lifecycle. href="https://developer.android.com/topic/libraries/architecture/lifecycle.html">Lifecycles enables the creation of lifecycle-aware components that manage their own lifecycles, reducing the possibility of leaks or crashes. The Lifecycle library is the foundation for other Architecture Components like LiveData.

LiveData

href="https://developer.android.com/topic/libraries/architecture/livedata.html">LiveData is a lifecycle-aware observable that holds data and provides updates. Your UI code subscribes to changes and provides LiveData a reference to its href="https://developer.android.com/reference/android/arch/lifecycle/Lifecycle.html">Lifecycle. Because LiveData is lifecycle-aware, it provides updates when its Lifecycle is started or resumed, but stops providing updates when the LifecycleOwner is destroyed. LiveData is a simple way to build reactive UIs that are safer and more performant.

ViewModel

href="https://developer.android.com/topic/libraries/architecture/viewmodel.html">ViewModel separates ownership of view data and logic from lifecycle-bound entities like Activities and Fragments. A ViewModel is retained until its associated Activity or Fragment is disposed of forever - that means view data survives events like a Fragment being recreated due to rotation. ViewModels not only eliminate common lifecycle issues, they help build UIs that are more modular and easier to test.

Room

Nearly all apps need to store data locally. While Android has bundled SQLite with the platform since version 1, using it directly can be painful. href="https://developer.android.com/topic/libraries/architecture/room.html">Room is a simple object-mapping layer that provides the full power of SQlite with less boilerplate. Features like compile-time query verification and built-in migration make it easier to build a robust persistence layer, while integration with LiveData lets Room provide database-backed, lifecycle-aware observables. Room blends of simplicity, power and robustness for managing local storage, and we hope you give it a try.

Guide to App Architecture and more

Last but not least, we created a href="https://developer.android.com/topic/libraries/architecture/guide.html">Guide to App Architecture that provides core principles applicable to all developers, and specific guidance on using Architecture Components together. Because we've heard from you that clear and consistent guidance is important, today we're updating developer documentation to point to Architecture Components where appropriate. We also have a rich set of videos, codelabs and sample apps available at the href="http://developer.android.com/arch">Architecture Components site, with more to come.

Watch this space

Although the first set of Architecture Components is now stable, we know there's more work to do. Over the last few months, we've listened to href="https://developer.android.com/topic/libraries/architecture/feedback.html">your feedback and made improvements. We also recently launched a new Architecture Component, href="https://developer.android.com/topic/libraries/architecture/paging.html">PagedList, to alpha, in response to your feedback that handling large datasets with RecyclerView is too difficult. This is just the beginning - we have more major components under development that we're looking to announce in the upcoming months.

Our hope with Architecture Components is to free developers to focus on providing unique new experiences for mobile devices. We're glad we can finally announce them as stable for production use. We'd like to thank the community, which has given such great feedback along the way, and we look forward to continuing the discussion in the comments of this post. Finally, for those of you who've been waiting for this stable launch, href="http://developer.android.com/arch">get started today.

Read more