Android Developers Blog

Developing for 3D is complicated. Whether you're using a native graphics API or
enlisting the help of your favorite game engine, there are thousands of graphics
commands that have to come together perfectly to produce beautiful 3D images on
your phone, desktop or VR headsets.

GAPID (Graphics API
Debugger) is a new tool that helps developers diagnose rendering and
performance issues with their applications. With GAPID, you can capture a trace
of your application and step through each graphics command one-by-one. This lets
you visualize how your final image is built and isolate problematic calls, so
you spend less time debugging through trial-and-error.

GAPID supports OpenGL ES on Android, and Vulkan on Android, Windows and Linux.

Debugging in action, one draw call at a time

GAPID not only enables you to diagnose issues with your rendering commands, but
also acts as a tool to run quick experiments and see immediately how these
changes would affect the presented frame.

Here are a few examples where GAPID can help you isolate and fix issues with
your application:

What's the GPU doing?

Why isn't my text appearing?!

Working with a graphics API can be frustrating when you get an unexpected
result, whether it's a blank screen, an upside-down triangle, or a missing mesh.
As an offline debugger, GAPID lets you take a trace of these applications, and
then inspect the calls afterwards. You can track down exactly which command
produced the incorrect result by looking at the framebuffer, and inspect the
state at that point to help you diagnose the issue.

What happens if I do X?

Using GAPID to edit shader code

Even when a program is working as expected, sometimes you want to experiment.
GAPID allows you to modify API calls and shaders at will, so you can test things
like:

What if I used a different texture on this object?

What if I changed the calculation of bloom in this shader?

With GAPID, you can now iterate on the look and feel of your app without having
to recompile your application or rebuild your assets.

Whether you're building a stunning new desktop game with Vulkan or a beautifully
immersive VR experience on Android, we hope that GAPID will save you both time
and frustration and help you get the most out of your GPU. To get started with
GAPID and see just how powerful it is, download it, take your
favorite application, and capture a
trace!

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 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 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 IOT_LAUNCHER
Activity is present.

Graphics acceleration defaults

Android Things uses the open-source 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 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 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 latest
features.

Command-line flashing tool

We heard from developers that flashing and configuring a board using fastboot
can be tedious, so the 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
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 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 configuration
of the local device and device updates. UpdateManager
gives developers control over when updates and reboots can be performed,
ensuring the device is available for the user when needed. DeviceManager
controls factory reset, reboot, and device locales. APIs are also provided for
settings such as ScreenManager
to control the screen, and TimeManager
to control the clock and time zone.

Peripheral command-line tool

We now provide a command-line tool 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.

If you know the basics of building Android apps and want to delve deeper, take a
look at our new 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 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.

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 Android Beta Program, you'll receive the
update over the next few days. If you haven't enrolled yet, just visit the 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 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
Neural
Networks API and others.

Also, for Pixel 2 users, the Android 8.1 update on these devices enables 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 release
notes for details.

Get your apps ready

With the consumer launch coming 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 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.

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 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 staged
rollout in your production channel. We're looking forward to seeing your app
updates!

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 GoogleApi
based APIs to replace the GoogleApiClient access pattern.

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

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:

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.