Based in Seattle, Big Fish Games was founded in 2002. Starting as a game studio, they quickly turned into a major publisher and distributor of casual games. Leading up to the launch of their hit time management game, Cooking Craze, the team ran an open beta on Google Play.

Big Fish Games found that using open beta provided more than 10x the amount of user feedback from around the world, and also gave them access to key metrics and Android Vitals in the Play Console. The ability to monitor game performance metrics pre-launch allowed the team to focus on areas of improvement, which lead to a 21% reduction in crash rate. The larger sample size of beta testers also provided more insights on player behavior and helped achieve a +7% improvement in day 1, day 7, and day 30 retention rates.

You can also learn more pre-launch best practices and strategies to improve performance post-launch at our Google Developer Day on Monday, March 19th at GDC. Sign up to stay informed.

Kicking off the new year, we're excited to welcome our latest group of Android Excellence apps and games. These awardees represent some of the best experiences and top performing apps and games on the Play Store and can be found with other great selections on the Editors' Choice page.

If you're looking for some new apps, below are a few highlights.

EyeEm: A great photo editor app with a full suite of filters and tools to make your pictures shine. Learn style tips from their community and even sell your images through the EyeEm marketplace.

Musixmatch: Check out Musixmatch's updated app while learning the lyrics to all your favorite songs. The app is compatible with many of the top music streaming services and you can even follow along with your Android Wear device or on the big screen with Chromecast support.

ViewRanger: Plan your next hiking adventure by discovering new routes and trail guides with ViewRanger. Check out the Skyline feature using your phone's camera to identify over 9 million sites across the world through augmented reality.

At Google I/O 2017, we announced
a redesign of the Android TV's home screen. We expanded the recommendation row
concept so that each app can have its own row (or multiple rows) of content on
the home screen. Since the release of the new home screen, we have seen
increased adoption of the new recommendation channels for Android Oreo in a wide
variety of apps.

With more and more apps surfacing high-quality recommendations using the new
channels, the legacy
recommendation row in the new home screen on Android O will be phased out
over the next year.

Currently, when an app creates recommendations with the legacy
notification based API the content is added to a channel for that app. The
channel may already exist if there was recommended content for it when you
upgraded from Android N (or below). If the there is no channel for the app, it
will be automatically generated for you. In either case, the user can't add or
remove programs from the channel, but they can move, hide, and show the channel.
When an app starts to use the new API to add its own channels, the system
removes the auto-generated channel and the app takes over control of the display
of their content.

Over the next year, we will phase out the automatic generation of channels.
Instead of generating multiple channels, one for each app's legacy
recommendations, we will insert one channel for all legacy
recommendations. This channel will appear at the bottom of the channel list.
Users can move or remove it. When a user upgrades to Android O, the previous
recommendation row from Android N (and below) becomes a channel at the bottom of
the home screen.

If you have not updated your app to post content to the new channels on the home
screen, take a look at our documentation,
codelab,
and sample
to get started.

We look forward to more and more apps taking advantage of the new changes in the
home screen. We love to hear your feedback, so please visit the Android TV
Developer Community on G+ to share your thoughts and ideas.

Expanding support for hardware security

Android already supports Verified Boot,
which is designed to prevent devices from booting up with software that has been
tampered with. In Android Oreo, we added a reference implementation for Verified
Boot running with Project
Treble, called Android Verified Boot 2.0 (AVB). AVB has a couple of cool
features to make updates easier and more secure, such as a common footer format
and rollback protection. Rollback protection is designed to prevent a device to
boot if downgraded to an older OS version, which could be vulnerable to an
exploit. To do this, the devices save the OS version using either special
hardware or by having the Trusted Execution Environment (TEE) sign the data.
Pixel 2 and Pixel 2 XL come with this protection and we recommend all device
manufacturers add this feature to their new devices.

Oreo also includes the new OEM
Lock Hardware Abstraction Layer (HAL) that gives device manufacturers more
flexibility for how they protect whether a device is locked, unlocked, or
unlockable. For example, the new Pixel phones use this HAL to pass commands to
the bootloader. The bootloader analyzes these commands the next time the device
boots and determines if changes to the locks, which are securely stored in
Replay Protected Memory Block (RPMB), should happen. If your device is stolen,
these safeguards are designed to prevent your device from being reset and to
keep your data secure. This new HAL even supports moving the lock state to
dedicated hardware.

Speaking of hardware, we've invested support in tamper-resistant hardware, such
as the security
module found in every Pixel 2 and Pixel 2 XL. This physical chip prevents
many software and hardware attacks and is also resistant to physical penetration
attacks. The security module prevents deriving the encryption key without the
device's passcode and limits the rate of unlock attempts, which makes many
attacks infeasible due to time restrictions.

While the new Pixel devices have the special security module, all new GMS devices shipping with Android Oreo
are required to implement key
attestation. This provides a mechanism for strongly attesting
IDs such as hardware identifiers.

We added new features for enterprise-managed devices as well. In work profiles,
encryption keys are now ejected from RAM when the profile is off or when your
company's admin remotely locks the profile. This helps secure enterprise data at
rest.

Platform hardening and process isolation

As part of Project
Treble, the Android framework was re-architected to make updates easier and
less costly for device manufacturers. This separation of platform and
vendor-code was also designed to improve security. Following the principle of
least privilege, these HALs run in their own
sandbox and only have access to the drivers and permissions that are
absolutely necessary.

Continuing with the media
stack hardening in Android Nougat, most direct hardware access has been
removed from the media frameworks in Oreo resulting in better isolation.
Furthermore, we've enabled Control Flow Integrity (CFI) across all media
components. Most vulnerabilities today are exploited by subverting the normal
control flow of an application, instead changing them to perform arbitrary
malicious activities with all the privileges of the exploited application. CFI
is a robust security mechanism that disallows arbitrary changes to the original
control flow graph of a compiled binary, making it significantly harder to
perform such attacks.

In addition to these architecture changes and CFI, Android Oreo comes with a
feast of other tasty platform security enhancements:

Seccomp
filtering: makes some unused syscalls unavailable to apps so that
they can't be exploited by potentially harmful apps.

Hardened
usercopy: A recent survey
of security bugs on Android
revealed that invalid or missing bounds checking was seen in approximately 45%
of kernel vulnerabilities. We've backported a bounds checking feature to Android
kernels 3.18 and above, which makes exploitation harder while also helping
developers spot issues and fix bugs in their code.

Privileged Access Never (PAN) emulation: Also backported to
3.18 kernels and above, this feature prohibits the kernel from accessing user
space directly and ensures developers utilize the hardened functions to access
user space.

Kernel Address Space Layout Randomization (KASLR):
Although Android has supported userspace Address Space Layout Randomization
(ASLR) for years, we've backported KASLR to help mitigate vulnerabilities on
Android kernels 4.4 and newer. KASLR works by randomizing the location where
kernel code is loaded on each boot, making code reuse attacks probabilistic and
therefore more difficult to carry out, especially remotely.

App security and device identifier changes

Android
Instant Apps run in a restricted sandbox which limits permissions and
capabilities such as reading the on-device app list or transmitting cleartext
traffic. Although introduced during the Android Oreo release, Instant Apps
supports devices running Android Lollipop and
later.

In order to handle untrusted content more safely, we've isolated
WebView by splitting the rendering engine into a separate process and
running it within an isolated sandbox that restricts its resources. WebView also
supports Safe Browsing to protect
against potentially dangerous sites.

[Edit: Updated post on Dec 21 to clarify that when the
64-bit requirement is introduced in August 2019, 32-bit support is not going
away. Apps that include a 32-bit library just need to have a 64-bit version
too.]

Google Play powers billions of app installs and updates annually. We
relentlessly focus on security and performance to ensure everyone has a positive
experience discovering and installing apps and games they love. Today we're
giving Android developers a heads-up about three changes designed to support
these goals, as well as explaining the reasons for each change, and how they
will help make Android devices even more secure and performant for the long
term.

In the second half of 2018, Play will require that new apps and app updates
target a recent Android API level. This will be required for new apps in
August 2018, and for updates to existing apps in
November 2018. This is to ensure apps are built on the latest
APIs optimized for security and performance.

In August 2019, Play will require that new apps and app
updates with native libraries provide 64-bit versions in addition to their
32-bit versions.

Additionally, in early 2018, Play will start adding a small amount of
security metadata on top of each APK to further verify app authenticity. You do
not need to take any action for this change.

We deeply appreciate our developer ecosystem, and so hope this long advance
notice is helpful in planning your app releases. We will continue to provide
reminders and share developer resources as key dates approach to help you
prepare.

Target API level requirement from late 2018

API behavior changes advance the security and privacy protections of Android –
helping developers secure their apps and protecting people from malware. Here
are a few such changes from recent platform versions:

Many of these changes only apply to apps that explicitly declare their support
for new API behaviors, through the targetSdkVersion
manifest attribute. For example, only apps with a targetSdkVersion of 23
(the API level of Android 6.0) or higher give the user full control over what
private data – such as contacts or location – the app can access via runtime
permissions. Similarly, recent releases include user experience improvements
that prevent apps from accidentally overusing resources like battery and memory;
background
execution limits is a good example of this type of improvement.

In order to provide users with the best Android experience possible, the Google
Play Console will require that apps target a recent API level:

2019 onwards: Each year the targetSdkVersion requirement
will advance. Within one year following each Android dessert release, new apps
and app updates will need to target the corresponding API level or
higher.

Existing apps that are not receiving updates are unaffected. Developers remain
free to use a minSdkVersion
of their choice, so there is no change to your ability to build apps for older
Android versions. We encourage developers to provide backwards compatibility as
far as reasonably possible. Future Android versions will also restrict apps that
don't target a recent API level and adversely impact performance or security. We
want to proactively reduce fragmentation in the app ecosystem and ensure apps
are secure and performant while providing developers with a long window and
plenty of notice in order to plan ahead.

This year we released Android Oreo, the most secure and best performing version
of Android yet, and we introduced Project
Treble to help the latest releases reach devices faster. Get started
building apps that target Android 8.1 Oreo
today.

64-bit support requirement in 2019

Platform support for 64-bit architectures was introduced in Android 5.0. Today,
over 40% of Android devices coming online have 64-bit support, while still
maintaining 32-bit compatibility. For apps that use native libraries, 64-bit
code typically offers significantly better performance, with additional
registers and new instructions.

In anticipation of future Android devices that support 64-bit code only, the
Play Console will require that new apps and app updates with native libraries
provide 64-bit versions in addition to their 32-bit versions. This can be within
a single APK or as one of the multiple APKs published.

We are not removing 32-bit support. Google Play will continue to support 32-bit
apps and devices. Apps that do not include native code are unaffected.

This change will come into effect in August 2019. We're providing advance notice
today to allow plenty of time for developers who don't yet support 64-bit to
plan the transition. Stay tuned for a future post in which we'll take an
in-depth look at the performance benefits of 64-bit native libraries on Android,
and check out the CPUs and
Architectures guide of the NDK for more info.

Security metadata in early 2018

Next year we'll begin adding a small amount of security metadata on top of each
APK to verify that it was officially distributed by Google Play. Often when you
buy a physical product, you'll find an official label or a badge which signifies
the product's authenticity. The metadata we're adding to APKs is like a Play
badge of authenticity for your Android app.

No action is needed by developers or users. We'll adjust Play's maximum APK size
to take into account the small metadata addition, which is inserted into the APK Signing Block
and does not alter the functionality of your app. In addition to enhancing the
integrity of Play's mobile app ecosystem, this metadata will enable new
distribution opportunities for developers in the future and help more people
keep their apps up to date.

Looking ahead

2017 has been a fantastic year for developers who have seen growth and success
on Google Play. We've been hard at work on features (including those announced
at I/O
2017 and at Playtime)
to help you improve your app quality and business performance. With these
features and the upcoming updates, we hope to see the Android and Play ecosystem
continue to thrive in 2018 and beyond.

At Google
for India this Monday, we announced the final release of Android 8.1 Oreo.
Android 8.1 Oreo is another exciting step toward bringing to life our vision of
an AI-first mobile platform, for everyone, everywhere.

Android 8.1 introduces support for our new Android Oreo (Go edition) software experience for entry-level
devices. Android Oreo (Go edition) brings the best of Android to the rapidly
growing market for low-memory devices around the world, including your apps and
games.

Android 8.1 also introduces the Neural
Networks API, a hardware accelerated machine learning runtime to
support ML capabilities in your apps. On supported devices, the Neural Networks
API enables fast and efficient inference for a range of key use cases, starting
with vision-based object classification.

You can get started with Android 8.1 Oreo (API level 27) today. We're pushing
sources to Android Open Source Project
now, and rolling out the update to supported Pixel and Nexus devices over the
next week. We're also working with our device maker partners to bring Android
8.1 to more devices, including Android Oreo (Go edition) devices, in the months
ahead.

Android Oreo (Go edition)

As announced at
Google I/O 2017, the "Android Go" project is our initiative to optimize the
Android experience for billions of people coming online around the world.
Starting with Android 8.1, we're making Android a great platform for entry-level
devices in the Android Oreo (Go edition) configuration:

Memory optimizations -- Improved memory usage across the
platform to ensure that apps can run efficiently on devices with 1GB or less
RAM.

Flexible targeting options -- New hardware
feature constants to let you target the distribution of your apps to normal
or low-RAM devices through Google Play.

Google Play: While all apps will be available on Android
Oreo (Go edition) devices, Google Play will give visibility to apps specifically
optimized by developers to provide a great experience for billions of people
with the building
for billions guidelines.

As always, we're providing downloadable factory and OTA images on the Nexus
Images page to help you do final testing on your Pixel and Nexus devices.

Publish your updates to Google Play

When you're ready, you can publish your APK updates targeting API level 27 in
your alpha, beta, or production channels. Make sure that your updated app runs
well on Android Oreo as well as older versions. We recommend using beta
testing to get early feedback from a small group of users and a pre-launch
report to help you identify any issues, then do a staged
rollout. Head over to the Android Developers site to find more info on launch
best practices. We're looking forward to seeing your app updates!

What's next for Android Oreo?

We'll soon be closing the Developer Preview issue tracker, but please keep the
feedback coming! If you still see an issue that you filed in the preview
tracker, just file
a new issue against Android 8.1 in the AOSP issue tracker. You can also
continue to give us feedback or ask questions in the developer
community.

In recent months, there's a growing trend for handset makers to ship new devices
with long screen aspect ratio (stretching beyond 16:9), many of which also sport
rounded corners. This attests to the Android ecosystem's breadth and choice.
Pixel 2 XL and Huawei Mate 10 Pro are just two of many examples. These screen
characteristics could bring a very immersive experience to users and they take
notice of apps and games that don't take advantage of the long aspect ratio
screen on these new devices. Therefore it is important for developers to
optimize for these screen designs. Let's have a look at related support
provided by the Android OS.

Optimize for long aspect ratio screens

Most apps using standard UI widgets will likely work out-of-the-box on these devices. Android
documentation details techniques for flexibly working on multiple screen
sizes. However, some games and apps with custom UIs may run into issues due to
incorrect assumptions on certain aspect ratios. We're sharing a few typical
issues faced by developers, so you can pay attention to those relevant to you:

Certain sides of the screen are cropped. This makes any
graphic or UI elements in the affected regions look incomplete.

Touch targets are offset from UI elements (e.g. buttons).
Users may be confused on UI elements that are seemingly interactive.

For full screen mode on rounded corners devices, any UI elements
very close to the corners may be outside of the curved corner viewable
area. Imagine if a commerce app's "Purchase" button was partially
obstructed? We recommend referencing Material
Design guidelines by leaving 16dp side margins in layouts.

If responsive UI is really not suitable for your situation, as a last
resort declare an explicit maximum supported aspect ratio as follows. On
devices with a wider aspect ratio, the app will be shown in a compatibility mode
padded with letterbox. Keep in mind that certain device models provide an
override for users to force the app into full-screen compatibility mode, so be
sure to test under these scenarios too!

Targets API level 25 or lower: Use android.max_aspect meta-data.
Note that maximum aspect ratio values will be respected only if your
activities don't support resizableActivity. See documentation
for detail.

System letterboxes an app when the declared maximum aspect ratio is smaller
than the device's screen.

Consider using side-by-side activities

Long aspect ratio devices enable even more multi-window use cases that could
increase user productivity. Beginning in Android 7.0, the platform offers a
standard way for developers to implement multi-window on supported devices as
well as perform data drag and drop between activities. Refer to documentation
for details.

Testing is crucial. If you don't have access to one of these long screen
devices, be sure to test on the emulator with adequate screen size and
resolution hardware properties, which are explained in the emulator
documentation.

We know you want to delight your users with long screen devices. With a few
steps, you can ensure your apps and games taking full advantage of these
devices!

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, 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 SafetyNetClient
instead of 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 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).

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 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 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 distributed as part of a beta or developer
preview program (including the 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, 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.

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 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 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. 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

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 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

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. 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 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 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 your feedback and made improvements. We also recently launched a new Architecture Component, 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, get started today.

Today we're giving you an early look at Android 8.1. This update to Android Oreo includes a set of targeted enhancements including optimizations for Android Go (for devices with 1GB or less of memory) and a new 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.

We're bringing you this Developer Preview so you can get your apps ready; we've already been helping device makers prepare for this new version. We recommend starting soon -- we're expecting the final public version in December.

It's easy to get Android 8.1 Developer Preview on your Pixel or Nexus device. Just enroll in the Android Beta Program -- you'll soon receive an over-the-air update to Android 8.1 beta. If you enrolled previously, you're all set, there's no need to re-enroll. The Developer Preview will be available for Pixel 2 and Pixel 2 XL devices, as well as for Pixel, Pixel XL, Pixel C, Nexus 5X, Nexus 6P, and the Android emulator.

What's in Android 8.1?

Android 8.1 includes select new features and developer APIs (API level 27), along with the latest optimizations, bug fixes, and security patches. Some of the new APIs include:

Android Go memory optimizations and targeting -- Android 8.1 includes a set of memory optimizations for Android Go configurations (1GB or less of memory). We've added new hardware feature constants so you can now target the distribution of your apps and APK splits to normal or low-RAM devices running Android 8.1 and later.

Neural Networks API -- as part of our efforts to bring machine intelligence to Android, we've added a Neural Networks API via the NDK. It enables hardware-accelerated inference operations on supported devices. We designed the Neural Networks API as a foundational layer for ML frameworks like TensorFlow Lite -- Google's upcoming cross-platform ML framework for mobile -- as well as Caffe2 and others. Stay tuned for TensorFlow Lite announcements.

Autofill enhancements -- we've made it easier for password managers and other Autofill services to use the Autofill framework. For example, we've added support for more UI customization of the Save dialog, as well as setAutofillOptions() for users to set credit card expiration using a spinner.

Shared memory API -- this new API lets apps allocate shared memory for faster access to common data. Apps can map anonymous shared memory and manage protection controls using the SharedMemory API. The API is parcelable, AIDL friendly, and exposes useful features like removing write permissions.

Test your apps on Android 8.1

With the consumer launch coming in December, it's important to test your current app now. This gives users a seamless transition to Android 8.1 when it arrives on their devices.

Just enroll your eligible device in 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.

Build with new features and APIs

When you're ready, take advantage of the new features and APIs in Android 8.1, which we've already finalized as API Level 27. For an overview of what's new, take a look at Android 8.1 for Developers. You can also extend your apps with established Android Oreo features as well, see the Android Oreo site for details.

If your app uses forms, make sure to test them with autofill so that users can take advantage of this convenient feature. Enable "Autofill with Google" or a similar service in Settings and test the form fills to make sure they work as expected. We strongly recommend providing explicit hints about your fields, and also associating your website and mobile app, so that logins can be shared between them.

You can update your project's compileSdkVersion to API 27 to compile against the official Android 8.1 APIs. We also recommend updating your app's targetSdkVersion to API 27 to test with compatibility behaviors disabled. See the this guide for details on how to set up your environment to build with Android 8.1.

Publish your updates to Google Play

The Android 8.1 APIs are already final, so we've opened Google Play for apps compiled against or targeting API level 27. When you're ready, you can publish your APK updates in your alpha, beta, or production channels. Make sure that your updated app runs well on Android 8.1 as well as older versions. We recommend using Google Play's beta testing feature to run an alpha test on small group of users, then run a much larger open beta test. When you're ready to launch your update, you can use a staged rollout. We're looking forward to seeing your app updates!

Android Studio 3.0 is ready to download today. Announced at Google I/O 2017,
Android Studio 3.0 is a large update focused on accelerating your app
development on Android.

This release of Android Studio is packed with many new updates, but there are
three major feature areas you do not want to miss, including: a new suite of app
profiling tools to quickly diagnose performance issues, support for the Kotlin
programming language, and a new set of tools and wizards to accelerate your
development on the latest Android Oreo APIs.

We also invested time in improving stability and performance across many areas
of Android Studio. Thanks to your feedback during the preview versions of
Android Studio 3.0! If you are looking for high stability, want to build high
quality apps for Android Oreo, develop with the Kotlin language, or use the
latest in Android app performance tools, then you should download Android Studio
3.0 today.

Check out the the list of new features in Android Studio 3.0 below, organized by
key developer flows.

What’s new in Android Studio 3.0

Develop

Kotlin Programming Language -As announced
at Google I/O 2017, the Kotlin
programming language is now officially supported for Android development. Kotlin
is an expressive and concise language that is interoperable with existing
Android languages and runtimes, which means you can use as little or as much of
the language in your app as you want. Kotlin is a production-ready language
used by many popular Android apps on Google Play today.

This release of Android Studio is the first milestone of bundles the Kotlin
language support inside the IDE. Many of your favorite features such as code
completion and syntax highlighting work well this release and we will continue
to improve the remaining editor features in upcoming release. You can choose to
add Kotlin to your project using the built-in conversion tool found under
Code → Convert Java File to Kotlin File, or
create a Kotlin enabled project with the New Project Wizard. Lean more about
Kotlin language support
in Android Studio.

Kotlin Language Conversion in Android Studio

Java 8 Language features -In Android
Studio 3.0, we are continuing to improve the support for Java 8 language
features. With the migration
to a javac based toolchain, using Java 8 language features in your project
is even easier. To update your project to support the new Java 8 Language
toolchain, simply update your Source and Target compatibility
levels to 1.8 in the Project Structure dialog. Learn
more.

Adaptive Icon Wizard -The new wizard
creates a set of launcher icon assets and provides previews of how your
adaptive icon will look with different launcher screen icon masks. Support for
VectorDrawable layers is new for this release. Learn
more.

Build Speed Improvements -To further
improve the speed of Gradle for larger scale projects with many modules, we
introduced a rare breaking API change in the Android Gradle Plugin to
improve scalability and build times. This change is one of reasons we jumped
version numbers from Android Studio 2.4 to 3.0. If you depend on APIs provided
by the previous Gradle plugin you should validate compatibility with the new
plugin and migrate to the new APIs. To test, update the plugin version in your
build.gradle file. Learn
more.

Test & Debug

Google Play System Images -We also
updated the emulator system images for Android Oreo to now include the Google
Play Store. Bundling in the Google Play store allows you to do end-to-end
testing of apps with Google Play, and provides a convenient way to keep Google
Play services up-to-date in your Android Virtual Device (AVD). Just as Google
Play services updates on physical devices, you can trigger the same updates on
your AVDs.

Google Play Store in Android Emulator

To ensure app security and a consistent experience with physical devices, the
emulator system images with the Google Play store included are signed with a
release key. This means you will not be able to get elevated privileges. If you
require elevated privileges (root) to aid with your app troubleshooting, you can
use the Android Open Source Project (AOSP) emulator system images that do not
include Google apps or services. Learn more.

OpenGL ES 3.0 Support in Android Emulator -The latest version of the Android Emulator has OpenGL ES 3.0 support
for Android Oreo system images along with significant improvements in OpenGL ES
2.0 graphics performance for older emulator system images. Learn
more.

App Bug Reporter in Android Emulator -To
help in documenting bugs in your app, we have added an easier way to generate a
bug report with the Android Emulator with all the necessary configuration
settings and space to capture your repro steps. Learn
more.

Proxy Support in Android -If you use a
proxy to access the Internet, we have added a user interface to manage the HTTP
proxy settings used by the emulator. Lean
more.

Android Emulator Quick Boot (Canary) -One
of the most common pain points we hear is that the emulator takes too long to
boot. To address this concern, we are excited to preview a new feature to solve
this called Quick Boot, which significantly speeds up your emulator start time.
Once enabled, the first time you start an AVD a cold boot will occur (just like
powering on a device), but all subsequent starts are fast and the system is
restored to the state at which you closed the emulator (similar to waking a
device). If you want to try it out, ensure you are on the canary update release
channel and then you will find v26.2.0 of the Android Emulator in the SDK
Manager. Learn
more.

APK Debugging -Android Studio 3.0 allows
you to debug an arbitrary APK. This functionally is especially helpful for those
who develop your Android C++ code in another IDE, but want to debug and analyze
the APK in the context of Android Studio. As long as you have a debuggable
version of your APK, you can use the new APK Debugging features to analyze,
profile & debug the APK. Moreover, if you have access to the sources of your
APK, you can link the source to the APK debugging flow for a higher fidelity
debugging process. Get started by simply selecting Profile or debug
APK from the Android Studio Welcome Screen or File → Profile or
debug APK. Learn
More.

APK Debugging

Layout Inspector -In this release we have
added a few additional enhancements for the Layout Inspector including better
grouping of properties into common categories, as well as search functionality
in both the View Tree and Properties Panels. Learn
more.

Device File Explorer -The new Device File
Explorer in Android Studio 3.0 allows you to view the file and directory
structure of your Android device or emulator. As you are testing your app, you
can now quickly preview and modify app data files directly in Android Studio.
Learn
more.

Android Test Orchestrator Support - When used with
AndroidJUnitRunner 1.0 or higher, the Android Gradle plugin 3.0 supports the use
of the Android Test Orchestrator. The Android Test Orchestrator allows each of
your app's tests to run within its own Instrumentation.
Learn
more.

Optimize

Android Profiler -Android Studio 3.0
includes a brand new suite of tools to help debug performance problems in your
app. We completely rewrote the previous set of Android Monitor tools, and
replaced them with the Android Profiler. Once you deploy your app to a running
device or emulator, click on the Android Profiler tab and you
will now have access to a real-time & unified view of the CPU, Memory, & Network
activity for your app. Each of the performance events are mapped to the UI event
timeline which highlights touch events, key presses, and activity changes so
that you have more context on when and why a certain event happened. Click on
each timeline to dig into each performance aspect of your app. Learn
more.

Android Profiler - Combined timeline view.

CPU Profiler

Memory Profiler

Network Profiler

APK Analyzer Improvements -We also
updated APK Analyzer with additional enhancements to help you further optimize
the size of your APK. Learn
more.

If you are using a previous version of Android Studio, you can upgrade to
Android Studio 3.0 today or you can download the update from the official
Android Studio Preview download
page. As mentioned in this blog, there are some breaking Gradle Plugin API
changes to support new features in the IDE. Therefore, you should also update
your Android Gradle plugin version to 3.0.0 in your current project to test and
validate your app project setup.

We appreciate any feedback on things you like, issues or features you would like
to see. If you find a bug or issue, feel free to file an
issue. Connect with us -- the Android Studio development team ‐ on our Google+ page or on Twitter