Updates to Google Play policy promote standalone Android Wear apps

Posted by Hoi Lam, Lead Developer
Advocate, Android Wear

Strava – a standalone wear app available to both Android and iOS users

Android Wear 2.0 represents the the latest evolution of the Android Wear
platform. It introduced the concept of standalone
that can connect to the network directly and work independently of a
smartphone. This is critical to providing apps not only to our Android users,
but also iOS users – which is increasingly important as we continue to expand
our diverse ecosystem of watches and users. In addition, Wear 2.0 brought
multi-APK support to Wear apps, which reduces the APK size of your phone apps,
and makes it possible for iOS users to experience your Wear apps.

Today, we are announcing that multi-APKs will also work for Android Wear 1.0
watches, so you can now reach all of your users without needing to bundle your
Wear app within your phone app’s APK. Additionally, the Google Play Store policy
will change to promote the use of multi-APKs and standalone apps. This covers
all types of apps that are designed to run on the watch, including watch faces,
complication data providers as well as launchable apps.

Policy change

The policy change will be effective from the 18th of January, 2018. At this
time, the following apps will lose the “Enhanced for Android Wear” badge in the
Google Play Store and will not be eligible to be listed in the top charts in the
Play Store for Android Wear:

  • Mobile apps that support Wear notification enhancements but do not have a
    separate Wear app.
  • Wear apps that are bundled with mobile apps instead of using

Since multi-APK is now supported by devices running Wear 1.0 and 2.0, developers
embedding their Wear app APKs in phone APKs should unbundle their Wear APK
and upload
it to the Play Store as a multi-APK
. This will allow them to continue to
qualify for the “Enhanced for Android Wear” badge as well as be eligible to
appear in the Android Wear top charts. The two APKs can continue to share the
same package name.

In addition to providing top app charts, we periodically put together curated
featured collections. To be eligible for selection for these collections,
developers will need to make their Wear apps function independently from the
phone, as a standalone app. These apps will need to work on watches that are
paired with both iOS and Android phones.

What are standalone apps?

are Wear apps that do not require a phone app to run. The app either
does not require network access or can access the network directly without the
phone app – something that is supported by Android Wear 2.0.

To mark your app as standalone, put the following meta-data tag in the

    android:value="true" />

In some rare cases, the user experience may be enhanced by the syncing of data
between the phone and watch. For example, a cycling app can use the watch to
display the current pace, and measure the user’s heart rate, while displaying a
map on the phone. In this scenario, we recommend that developers ensure that
their Wear apps function without a phone and treat the phone experience as
optional as far as the Wear apps are concerned. In these cases, a Wear app is
still considered standalone and should be marked as such in its
AndroidManifest.xml file.

Wear what you want

From the beginning, Android Wear has been about wear what you want — the
styles, watches, and apps you want to wear. This latest policy change lets you
highlight your Android Wear apps, giving users even more choice about what apps
they want on their watches.

Speedo and Samsung Make Waves with Partnership to Bring Industry-Leading Swim Tracking Capabilities to Gear Fit2 Pro and Gear Sport

Samsung Electronics and Speedo International are helping swimmers across the globe track their activity with access to Speedo’s best-in-class swimming

Hardening the Kernel in Android Oreo

Posted by Sami Tolvanen, Senior Software Engineer, Android Security

The hardening of Android’s userspace has increasingly made the underlying Linux
kernel a more attractive target to attackers. As a result, more than a third of
Android security bugs were found in the kernel last year. In Android 8.0 (Oreo),
significant effort has gone into hardening the kernel to reduce the number and
impact of security bugs.

worked to protect the kernel by isolating it from userspace processes
with the addition of SELinux ioctl filtering and requiring seccomp-bpf support,
which allows apps to filter access to available system calls when processing
untrusted input. Android 8.0 focuses on kernel self-protection with four
security-hardening features backported from upstream Linux to all Android
kernels supported in devices that first ship with this release.

Hardened usercopy

Usercopy functions are used by the kernel to transfer data from user space to
kernel space memory and back again. Since 2014, missing or invalid bounds
checking has caused about 45% of Android’s kernel vulnerabilities. Hardened usercopy adds bounds
checking to usercopy functions, which helps developers spot misuse and fix bugs
in their code. Also, if obscure driver bugs slip through, hardening these
functions prevents the exploitation of such bugs.

This feature was
in the upstream kernel version 4.8, and we have backported it to
Android kernels 3.18 and above.

int buggy_driver_function(void __user *src, size_t size)
    /* potential size_t overflow (don’t do this) */
    u8 *buf = kmalloc(size * N, GPF_KERNEL);
    /* results in buf smaller than size, and a heap overflow */
    if (copy_from_user(buf, src, size))
    return -EFAULT;

    /* never reached with CONFIG_HARDENED_USERCOPY=y */

An example of a security issue that hardened usercopy prevents.

Privileged Access Never (PAN) emulation

While hardened usercopy functions help find and mitigate security issues, they
can only help if developers actually use them. Currently, all kernel code,
including drivers, can access user space memory directly, which can lead to
various security issues.

To mitigate this, CPU vendors have introduced features such as Supervisor Mode
Access Prevention (SMAP) in x86 and Privileged Access Never (PAN) in ARM v8.1.
These features prevent the kernel from accessing user space directly and ensure
developers go through usercopy functions. Unfortunately, these hardware features
are not yet widely available in devices that most Android users have today.

Upstream Linux introduced software emulation for PAN in kernel version 4.3
for ARM
and 4.10 in ARM64. We
have backported both features to Android kernels starting from 3.18.

Together with hardened usercopy, PAN emulation has helped find and fix bugs in
four kernel drivers in Pixel devices.

int buggy_driver_copy_data(struct mydata *src, void __user *ptr)
    /* failure to keep track of user space pointers */
    struct mydata *dst = (struct mydata *)ptr;
    /* read/write from/to an arbitrary user space memory location */
    dst->field = … ;    /* use copy_(from|to)_user instead! */
    /* never reached with PAN (emulation) or SMAP */

An example of a security issue that PAN emulation mitigates.

Kernel Address Space Layout Randomization (KASLR)

Android has included support for Address Space Layout Randomization (ASLR) for
years. Randomizing memory layout makes code reuse attacks probabilistic and
therefore more difficult for an attacker to exploit, especially remotely.
Android 8.0 brings this feature to the kernel. While Linux has supported KASLR on x86 since version 3.14, KASLR for ARM64 has only been
available upstream since Linux 4.6. Android 8.0 makes KASLR available in Android
kernels 4.4 and newer.

KASLR helps mitigate kernel vulnerabilities by randomizing the location where
kernel code is loaded on each boot. On ARM64, for example, it adds 13–25 bits of
entropy depending on the memory configuration of the device, which makes code
reuse attacks more difficult.

Post-init read-only memory

The final hardening feature extends existing memory protections in the kernel by
creating a memory region that’s marked read-only after the kernel has been
initialized. This makes it possible for developers to improve protection on data
that needs to be writable during initialization, but shouldn’t be modified after
that. Having less writable memory reduces the internal attack surface of the
kernel, making exploitation harder.

Post-init read-only memory was
introduced in upstream kernel version 4.6 and we have backported it to Android
kernels 3.18 and newer. While we have applied these protections to some data
structures in the core kernel, this feature is extremely useful for developers
working on kernel drivers.


Android Oreo includes mitigations for the most common source of security bugs in
the kernel. This is especially relevant because 85% of kernel security bugs in
Android have been in vendor drivers that tend to get much less scrutiny. These
updates make it easier for driver developers to discover common bugs during
development, stopping them before they can reach end user devices.

Hey Cortana, open Alexa: Microsoft and Amazon’s first-of-its-kind collaboration

I talk to Cortana every day — at home, work and on-the-go — to get information about my day, to set reminders so I don’t forget things, and to answer my questions. But I don’t just use one digital assistant. I also frequently talk to Alexa to listen to audio books or to add things…

The post Hey Cortana, open Alexa: Microsoft and Amazon’s first-of-its-kind collaboration appeared first on The Official Microsoft Blog.

An update on our response to Hurricane Harvey

Across the country, we watched as Hurricane Harvey hit Texas with devastating force last Friday night. As the crisis continues to unfold, our thoughts are with the millions of people in Houston and throughout the Gulf Coast who are impacted by this disaster, which has been described as unprecedented in scale and scope. Since the…

The post An update on our response to Hurricane Harvey appeared first on The Official Microsoft Blog.

ARCore: Augmented reality at Android scale

Posted by Dave Burke, VP, Android Engineering

With more than two billion active devices, Android is the largest mobile
platform in the world. And for the past nine years, we’ve worked to create a
rich set of tools, frameworks and APIs that deliver developers’ creations to
people everywhere. Today, we’re releasing a preview of a new
software development kit (SDK) called ARCore. It brings augmented reality
capabilities to existing and future Android phones. Developers can start
experimenting with it right now.

We’ve been developing the fundamental technologies that power mobile AR over the
last three years with Tango, and ARCore is built on that work. But, it works
without any additional hardware, which means it can scale across the Android
ecosystem. ARCore will run on millions of devices, starting today with the Pixel
and Samsung’s S8, running 7.0 Nougat and above. We’re targeting 100 million
devices at the end of the preview. We’re working with manufacturers like
Samsung, Huawei, LG, ASUS and others to make this possible with a consistent bar
for quality and high performance.

ARCore works with Java/OpenGL, Unity and Unreal and focuses on three things:

  • Motion tracking: Using the
    phone’s camera to observe feature points in the room and IMU sensor data, ARCore
    determines both the position and orientation (pose) of the phone as it moves.
    Virtual objects remain accurately placed.
  • Environmental understanding:
    It’s common for AR objects to be placed on a floor or a table. ARCore can detect
    horizontal surfaces using the same feature points it uses for motion tracking.
  • Light estimation: ARCore
    observes the ambient light in the environment and makes it possible for
    developers to light virtual objects in ways that match their surroundings,
    making their appearance even more realistic.

Alongside ARCore, we’ve been investing in apps and services which will further
support developers in creating great AR experiences. We built Blocks and Tilt Brush to make it easy for anyone to
quickly create great 3D content for use in AR apps. As we mentioned
at I/O
, we’re also working on Visual Positioning Service (VPS), a service
which will enable world scale AR experiences well beyond a tabletop. And we
think the Web will be a critical component of the future of AR, so we’re also
releasing prototype browsers for web developers so they can start experimenting
with AR, too. These custom browsers allow developers to create AR-enhanced
websites and run them on both Android/ARCore and iOS/ARKit.

ARCore is our next step in bringing AR to everyone, and we’ll have more to share
later this year. Let us know what you think through GitHub, and check out our new AR Experiments showcase
where you can find some fun examples of what’s possible. Show us what you build
on social media with #ARCore; we’ll be resharing some of our favorites.

Announcing the 20 finalists and open registration for the Indie Games Festival in San Francisco

Posted by Kacey Fahey, Developer Marketing, Google Play

With so many great mobile games launching this year, we saw a huge amount of
interest from indie developers to showcase their art at the Google
Play Indie Games Festival
in San Francisco next month. While it was a tough
selection process, we’re excited to announce the 20 finalists, as well as our
esteemed judging panel. Fans will be able to play the new and un-released indie
games in a fun festival atmosphere where they can also meet the creators
themselves. To attend and learn more about the event, register now for free at

So how did we choose the 20 finalists? We powered up our phones, put our
game-faces on, and looked for games that not only met the festival requirements,
but also stood out with their overall design, fun, and quality. These are the 20
finalists who will be joining us at the festival to demo their games.

Meet the finalists

Pin Pool


of Rivals

Roboto Games

Brave Hand
Heart Shaped Games
(game not yet released)
Raincrow Studios, LLC


Sense of Wonder

Hiding Spot

Happii Gamer Studio

Happy Square Studio Inc
Latin Bingo

Gorilla Bean Games
Maruta Escape

Busan Sanai Games

(game not yet released)

Black Vein Productions

Blue Wizard Digital

Spacewave Studios
Vikings Forever

Akupara Games

Tiny Bubbles

Pine Street Codeworks

(game not yet released)

Nico Prins

In addition to playing these games and meeting the developers who made them,
fans will have a chance to vote for their favorites throughout the festival. The
Top 10 will then move on to present a short pitch in pursuit of going home as
one of the three overall festival winners. The winners will be chosen by this
year’s panel of judges representing a diverse lineup of gaming expertise.

  • Alex the Gamerette, YouTube Creator
  • Lina Chen, Co-founder & CEO of Nix Hydra
  • Emily Greer, CEO of Kongregate
  • Jamil Moledina, Games Strategic Lead, Google
  • Dean Takahashi, Lead Writer for GamesBeat
  • Sarah Thomson, BD Lead, Indie Games, Google Play

Emceeing this year’s event is J.D. Witherspoon, aka runJDrun. No stranger to gaming,
YouTuber/actor/comedian, J.D. plays a wide array of games and frequently uploads
gaming, vlog, and comedy content to his channels.

If you want to try out these games and celebrate the indie community, learn more
about the event and register at g.co/play/sfindiegamesfest2017.

How useful did you find this blogpost?

How to improve app design for Wear 2.0

Posted by Steven Tepper, App Quality Consultant, Google Play

2.0 launched
back in February with added support for new hardware features
in addition to adopting new Material
Design themes
and a simpler vertical UI pattern. It also introduces a complications
, making it easier for apps to provide data to watch faces, and watch
faces to incorporate external data. The final big update was that, apps
targeting Wear 2.0 now have the ability to operate in a standalone
, without needing a connection to a companion app on the phone.

There are a few design considerations in relation to navigation, notifications,
the complications API, and the standalone functionality to help you better
optimize for Wear 2.0 devices:


  1. Use the WearableDrawerLayout navigation drawer for simple and infrequent
    Simple navigation includes tasks such as accessing app
    settings, switching users or logging out. You can implement
    this on Wear 2.0 to switch between different views or sections of the app via a
    swipe down from the top of the screen, or an action drawer can be set up for
    context-specific actions when swiping up from the bottom of the screen.
  2. Present a navigation drawer as a single-page drawer to enable users
    to navigate views quickly:
    A navigation drawer can be presented as
    either a multi-page or single-page drawer. The single-page layout is useful for
    when the user is expected to navigate quickly between 7 or less views of the
    app. Remember that if the app is using a single-page drawer, the iconography
    should be clear and understandable as there will not be any sort of text
    labeling in this layout. If there are more than 7 views to navigate to or the
    views are not easily represented by icons, you should instead use the multi-page
    drawer layout.

  3. Use multiple app launchers if your app has two or three discrete
    For example, if your app supports
    both activity tracking—with various options, actions,
    and views—and historical analysis and management of tracked activities, you can
    use multiple app launchers to handle these tasks. Alternatively, if your app has
    a simple home screen, these features could be placed in line, at the bottom of
    the screen.
  4. Use peeking at the top of the action drawer to provide quick access
    to the primary action:
    If there is no primary action associated with
    the view, override the default behavior and force an overflow button to peek
    instead, exposing all actions at the bottom of a view, when tapped.

Ensure that for devices using Wear 2.0, your app takes advantage of these new UI
patterns to provide a consistent user experience. Check out more training
resources for Wear
Navigation and Actions
and the Material Design specifications for Navigation
and Action


Wear 2.0 uses a simpler vertical navigation pattern, removing the horizontal
swiping gesture to present actions for a notification. Notification actions are
now presented as a single primary action (if applicable) at the bottom of a
notification. If there is no primary action, expanding the notification will
present options in a single, vertically scrollable view.

Notifications will work without needing many changes on both 1.x and 2.0
devices, but appear quite different:

When creating apps for Wear 2.0 devices, improve the user experience with
notifications by applying the following best practices:

  1. Support expandable notifications: Use BigTextStyle
    so that users can see more content on their watch.
  2. Use the collapsed view of the notification (if applicable):
    Add the primary action for your notification to the collapsed view of the
    notification using setContentIntent(), where appropriate.
  3. For messaging apps, use the MessagingStyle:
    Provide a rich chat app-like experience in the expanded notification using this
  4. Update user directions which are specific to Wear 1.0:
    Remove any text guiding users to act on a card by swiping horizontally
    (the Wear 1.x pattern).
  5. Enhancing notifications to use inline actions: This allows
    users to do things without needing tap to see the expanded notification details.
    Actions for messaging notifications can use several different input methods
    including Smart Reply presets, voice, and keyboard input. Take advantage of
    these features to provide added functionality and delight users.

To learn more about adding
wearable features to notifications


The complications API in Wear 2.0 makes it much easier for watch face developers
and third-party data providers to surface important information users want, at a
glance. Watch faces that support the API can be configured to use any of the
data providers that have been installed on the watch while maintaining complete
control over their appearance. Apps supporting the complication API allow the
app’s data to be accessible on any watch faces that support complications. These
complications can be displayed in a variety of forms (short text, icon, ranged
value, long text, small image, and large image) depending on what the data
provider has configured and how much space has been allocated on the watch face.

To ensure that complications fit the overall design of the watch face and
properly handle their data type, when adding complication support we recommend
watch face makers should:

  1. Use the TextRenderer
    class found in the Wear 2.0 SDK:
    This allows the text within
    complications to be adjusted to their bounds by shrinking the text, dynamically
    supporting line breaks or ellipsizing strings when they exceed the bounds of a
    text-based complication.
  2. Use the ComplicationDrawable
    class to set the background color, shape, border, and font options for the
    This gives complete control of how the complication is
    rendered to the watch face.
  3. Design the watch face to provide a way for users to configure or
    adjust complications on the watch face through a settings menu:
    learn how to construct these settings see the watch face sample
    on GitHub.
  4. Use the data provider test
    app to feed dummy data to the watch face complications:
    will enable you to verify that all of the complications render properly and have
    fonts formatted for their bounds.
  5. As a complication data provider, expose relevant data by using the

    Simply define and configure what types of ComplicationData
    the app can provide for complications.

Standalone functionality on Wear devices

  1. Make sure your app is able to handle itself if there is no companion
    app installed when using the android.hardware.type.watch hardware feature
    : Using this feature enables your app to become searchable and
    installable directly on Wear devices without needing to install a companion
    phone app, so ensure your app can handle itself to avoid a confusing or broken
    user experience.
  2. Ensure your wearable app doesn’t rely on the phone app for
    sign-in/authentication or primary functionality
    : When requiring
    complicated input for authentication (for example, password entry) your wearable
    app can point to the companion phone, but should rely on web UI for
    account/password entry rather than an app.
  3. Where a companion app must be present on a phone to support your app
    in some other way, the app should use the CapabilityApi:

    This should be used to properly direct users to the Play Store listing on their
    companion device to install the missing app. Otherwise, the app should function
    on its own, using the Wear built-in Wi-Fi, GPS, or other connectivity functions.

  4. Include wording about any companion app requirements or briefly
    mention how your Wear app should function within the Play Store listing
    : This will help set expectations and guide users to install
    the correct apps for the best possible experience.
  5. Incorporate the com.google.android.wearable.standalone
    flag in the manifest if your Wearable app can function without any phone
    companion interaction
    : This flag indicates that the wearable app can be
    installed and will fully function when not paired to an Android or iOS companion

Though a lot was covered here, there are additional resources you can use to
ensure that your apps or games are optimized and use the latest patterns and
functionality on Wear. Be sure to review
the quality guidelines
and check out the developer training documentation to
learn more best practices for wearable app
and wearable
app design
in order to build quality apps for Wear.

How useful did you find this blogpost?

Gamescom, Hot Chips, Hackathon and inclusivity – Weekend Reading: Aug. 25 edition

This week was awash in news out of gamescom 2017, a European trade fair for digital gaming culture that took place in Cologne, Germany. If your head is spinning from all the announcements, take a deep breath and devote the next three minutes to watching this video, with everything you need to know out of…

The post Gamescom, Hot Chips, Hackathon and inclusivity – Weekend Reading: Aug. 25 edition appeared first on The Official Microsoft Blog.

Understanding the performance benefits of ConstraintLayout

Posted by Takeshi Hagikura, Developer Programs Engineer

Since announcing ConstraintLayout
at Google I/O last year, we’ve continued to improve the layout’s stability and
layout editor support. We’ve also added new features specific to
ConstraintLayout that help you build various type of layouts, such
as introducing
and setting
size as a ratio
. In addition to these features, there is a notable
performance benefit by using ConstraintLayout. In this post, we’ll
walk through how you can benefit from these performance improvements.

How Android draws views?

To better understand the performance of ConstraintLayout, let’s
take a step back and see how Android draws views.

When a user brings an Android view into focus, the Android framework directs the
view to draw itself. This drawing process comprises 3 phases:

  1. Measure

    The system completes a top-down traversal of the view tree to determine how
    large each ViewGroup and View element should be. When a
    ViewGroup is measured, it also measures its children.

  2. Layout

    Another top-down traversal occurs, with each ViewGroup determining
    the positions of its children using the sizes determined in the measure phase.

  3. Draw

    The system performs yet another top-down traversal. For each object in the view
    tree, a Canvas object is created to send a list of drawing commands
    to the GPU. These commands include the ViewGroup and
    View objects’ sizes and positions, which the system determined
    during the previous 2 phases.

Figure 1. Example of how the measure phase traverses a view tree

Each phase within the drawing process requires a top-down traversal of the view
tree. Therefore, the more views you embed within each other (or nest) into the
view hierarchy, the more time and computation power it takes for the device to
draw the views. By keeping a flat hierarchy in your Android app layouts, you can
create a fast and responsive user interface for your app.

The expense of a traditional layout hierarchy

With that explanation in mind, let’s create a traditional layout hierarchy that
uses LinearLayout and RelativeLayout objects.

Figure 2. Example layout

Let’s say we want to build a layout like the image above. If you build it with
traditional layouts, the XML file contains an element hierarchy similar to the
following (for this example, we’ve omitted the attributes):

  <ImageView />
  <ImageView />
    <TextView />
      <TextView />
        <EditText />
      <TextView />
        <EditText />
    <TextView />
  <LinearLayout >
    <Button />
    <Button />

Although there’s usually room for improvement in this type of view hierarchy,
you’ll almost certainly still need to create a hierarchy with some nested views.

As discussed before, nested hierarchies can adversely affect performance. Let’s
take a look at how the nested views actually affect the UI performance using
Android Studio’s Systrace
tool. We called the measure and layout phases for each ViewGroup
(ConstraintLayout and RelativeLayout) programmatically
and triggered Systrace while the measure and layout calls are executing. The
following command generates an overview file that contains key events, such as
expensive measure/layout passes, that occur during a 20-second interval:

python $ANDROID_HOME/platform-tools/systrace/systrace.py --time=20 -o ~/trace.html gfx view res

For more details about how you can use Systrace, see the Analyzing UI
Performance with Systrace

Systrace automatically highlights the (numerous) performance problems with this
layout, as well as suggestions for fixing them. By clicking the “Alerts” tab,
you will find that drawing this view hierarchy requires 80 expensive passes
through the measure and layout phases!

Triggering that many expensive measure and layout phases is far from ideal; such
a large amount of drawing activity could result in skipped frames that users
notice. We can conclude that the layout has poor performance due to the nested
hierarchy as well as the characteristic of RelativeLayout, which
measures each of its children twice.

Figure 3. Looking at the alerts from Systrace for the
layout variant that uses RelativeLayout

You can check the entire code on how we performed these measurements in our GitHub

The benefits of a ConstraintLayout object

If you create the same layout using ConstraintLayout, the XML file
contains an element hierarchy similar to the following (attributes again

  <ImageView />
  <ImageView />
  <TextView />
  <EditText />
  <TextView />
  <TextView />
  <EditText />
  <Button />
  <Button />
  <TextView />

As this example shows, the layout now has a completely flat hierarchy. This is
because ConstraintLayout allows you to build complex layouts
without having to nest View and ViewGroup elements.

For example, let’s look at the TextView and EditText
in the middle of the layout:

When using a RelativeLayout, you need to create a new
ViewGroup to align the EditText vertically with the
    android:layout_below="@id/title" >

        android:layout_marginStart="16dp" />


            android:layout_marginEnd="8dp" />

By using ConstraintLayout instead, you can achieve the same effect
just by adding a constraint from the baseline of the TextView to
the baseline of the EditText without creating another

Figure 4. Constraint between EditText and TextView
      app:layout_constraintBaseline_toBaselineOf="@+id/cameraType" />

When running the Systrace tool for the version of our layout that uses
ConstraintLayout, you see far fewer expensive measure/layout passes
during the same 20-second interval. This improvement in performance makes sense,
now that we’re keeping the view hierarchy flat!

Figure 5. Looking at the alerts from Systrace for the
layout variant that uses ConstraintLayout

On a related note, we built the ConstraintLayout variant of our
layout using just the layout
instead of editing the XML by hand. To achieve the same visual effect
using RelativeLayout, we probably would have needed to edit the XML
by hand.

Measuring the performance difference

We analyzed how long every measure and layout pass took for two type of layouts,
ConstraintLayout and RelativeLayout, by using
which was introduced in Android 7.0 (API level 24). This class allows you to
collect frame-by-frame timing information about your app’s UI

By calling the following code, you can start recording per-frame UI actions:

        frameMetricsAvailableListener, frameMetricsHandler);

After timing information becomes available, the app triggers the
frameMetricsAvailableListener() callback. We are interested in the
measure/layout performance, so we call FrameMetrics.LAYOUT_MEASURE_DURATION
when retrieving the actual frame duration.

Window.OnFrameMetricsAvailableListener {
        _, frameMetrics, _ ->
        val frameMetricsCopy = FrameMetrics(frameMetrics);
        // Layout measure duration in nanoseconds
        val layoutMeasureDurationNs = 

To learn more about the other types of duration information that
FrameMetrics can receive, see the FrameMetrics
API reference.

Measurement results: ConstraintLayout is faster

Our performance comparison shows that ConstraintLayout performs
about 40% better in the measure/layout phase than RelativeLayout:

Figure 6. Measure / Layout (unit: ms, average of 100

As these results show, ConstraintLayout is likely to be more
performant than traditional layouts. Moreover, ConstraintLayout has
other features that help you build complex and performant layouts, as discussed
in the benefits of a ConstraintLayout
section. For details, see the Build
a Responsive UI with ConstraintLayout
guide. We recommend that you use
ConstraintLayout when designing your app’s layouts. In almost all
cases when you would have previously need a deeply-nested layout,
ConstraintLayout should be your go-to layout for optimal
performance and ease of use.

Appendix: Measurement environment

All the measurements above were performed in the following environment.

Device Nexus 5X
Android Version 8.0
ConstraintLayout version 1.0.2

What’s next

Check out the developer
, the API
reference documentation
, and the article
on Medium
to fully understand what ConstraintLayout can provide
for you. And once again, thank you to all who submitted feedback and issues over
the months since our alpha release of ConstraintLayout. We’re truly
grateful that we were able to release the production-ready 1.0
of ConstraintLayout earlier this year.
As we continue to improve ConstraintLayout, please continue to send
us feedback using the Android issue tracker.

Spotlight on Local News: Eclipse Edition

By Josh Mabry, Local News Partnerships and Amber Burgess, CrowdTangle If your News Feed was flooded with people talking about the eclipse this past week, you weren’t alone. 66 million people had 240 million interactions around the solar eclipse, making…

Start on Android and succeed on Google Play

Posted by Karolis Balciunas, VC & Startups Business Development, Google Play

Early Access was launched at Google I/O 2016 as a destination
on Google Play for beta app and game titles still in development, and to attract
early adopters willing to test those titles. The results speak for themselves.
The program has helped over 350 developers launch their titles and generated
over 40M beta installs for their apps and games during just the short window
before their public availability on the Play Store. More importantly, the
average rating for titles that have been through Early Access is 4.3☆ once in
production, putting them in a strong position to be favored in search and
discovery on Google Play.

Early Access also generates positive awareness for new titles. Alumni like Simple
and Digit
were chosen as finalists in the “Standout Startup” category at the Google
Play Awards
this year.
Omnidrone’s game Titan
became the first game to reach 1M testers. Hear more about their
experience in the video below.

Early Access and our work with the venture capital community has taught us a lot
about successful startups. We know you seek rapid iteration towards
product-market fit and are thirsty for the same kind of powerful testing,
analytics, and user feedback that Google’s own product teams depend on to launch
successful products. When we know about your startup’s plans
well in advance of your launch date, we can impact your trajectory by supporting
you through this understood process of iterative improvement.

Start on Android

Earlier this year we launched Start
on Android
to identify the highest potential Android startups
earlier in their lifecycle and provide tools, perks, and guidance for those who
qualify. We’ve developed five components that have proven to be most impactful:

  1. Early Access participation enabling developers to recruit beta testers and
    respond to their feedback before it impacts an app’s rating on the Play Store.
  2. Pre-launch user interface and user experience reviews from the Play
    editorial team to help optimize onboarding experiences, material design
    implementation, business model execution, and user engagement.
  3. Access to Google perks like the Google Cloud Platform’s Spark Package which
    includes $20K in Google Cloud and Firebase credits, free 12 months of G Suite
    for up to 10 employees, and other financial incentives.
  4. Opportunities to participate in Google Play and other Google teams’ programs
    and special events including Google Cloud Platform,
    Google for Entrepreneurs,
    and Launchpad.
  5. Guidance in the form of videos and content on startup best practices
    available to all at StartonAndroid.com.

We are just getting started

We’ve already seen a lot of developer interest and received hundreds of public
applications and referrals from venture capitalists and other startup
influencers. Below are a few accepted startups:

  • Socratic
    – A Spark Capital backed company that allows students to solve math problems by
    snapping a photo with their camera and using computer vision to return relevant
    answers and related concepts and video.
  • Astro
    A Redpoint
    portfolio company that layers AI on top of your email to help intelligently
    manage your inbox.

  • Peanut
    – A Tinder-like app for connecting moms, funded by NEA and Felix Capital.
  • Gyroscope
    – A startup working on an “operating system for the human body”.
  • Empower – An exciting new money management
    app backed by Sequoia Capital, coming soon to Android.

We are incredibly proud of every developer we work with and grateful to our
friends within VC firms and the wider community who bring exciting new startups
to our attention.

Get in touch with us

If you would like to be part of Start on Android, complete the form at StartonAndroid.com. We’re looking for
developers who are planning to launch on Android soon, or have done so in the
past 6 months.

How useful did you find this blogpost?

Making it safer to get apps on Android O

Posted by Edward Cunningham. Product Manager, Android Security

Eagle-eyed users of Android O will have noticed the absence of the ‘Allow
unknown sources’ setting, which has existed since the earliest days of Android
to facilitate the installation of apps from outside of Google Play and other
preloaded stores. In this post we’ll talk about the new Install unknown
permission and the security benefits it brings for both Android
users and developers.

Earlier this year we introduced Google Play
– comprehensive security services that are always at work to protect
your device from harm. Google Play continues to be one of the safest places for
Android users to download their apps, with the majority of Potentially Harmful
Apps (PHAs) originating from third-party sources.

A common strategy employed by PHA authors is to deliver their apps via a hostile
downloader. For example, a gaming app might not contain malicious code but
instead might notify the user to install a PHA that masquerades as an important
security update. (You can read more about hostile downloaders in the Android
Security 2016 Year in Review
). Users who have enabled the installation of
apps from unknown sources leave themselves vulnerable to this deceptive

Left (pre-Android O): The install screen for a PHA masquerading as a system
Right (Android O): Before the PHA is installed, the user must first grant
permission to the app that triggered the install.

In Android O, the Install unknown apps permission makes it
safer to install apps from unknown sources. This permission is tied to the app
that prompts the install— just like other runtime permissions—and ensures that
the user grants permission to use the install source before it can prompt the
user to install an app. When used on a device running Android O and higher,
hostile downloaders cannot trick the user into installing an app without having
first been given the go-ahead.

This new permission provides users with transparency, control, and a streamlined
process to enable installs from trusted sources. The Settings app shows the list
of apps that the user has approved for installing unknown apps. Users can
revoke the permission for a particular app at any time.

At any time, users can review the apps that they’ve allowed for installing
unknown apps. To make the permission-granting process easier, app developers can
choose to direct users to their permission screen as part of the setup

Developer changes

To take advantage of this new behavior, developers of apps that require the
ability to download and install other apps via the Package Installer may need to
make some changes. If an app uses a targetSdkLevel of 26 or above
and prompts the user to install other apps, the manifest file needs to include

<uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" />

Apps that haven’t declared this permission cannot install other apps, a handy
security protection for apps that have no intention of doing so. You can choose
to pre-emptively direct your users to the Install unknown apps
permission screen using the ACTION_MANAGE_UNKNOWN_APP_SOURCES
Intent action. You can also query the state of this permission using the
PackageManager canRequestPackageInstalls()

Remember that Play policies
still apply to apps distributed on Google Play if those apps can install and
update other apps. In the majority of cases, such behavior is inappropriate; you
should instead provide a deep
to the app’s listing on the Play Store.

Be sure to check out the updated publishing
that provides more information about installing unknown apps, and stay
tuned for more posts on security hardening in Android O.

Introducing Android 8.0 Oreo

Posted By: Dave Burke, VP of Engineering

After more than a year of development and months of testing by developers and early adopters (thank you!), we’re now ready to officially launch Android 8.0 Oreo to the world. Android 8.0 brings a ton of great features such as picture-in-picture, autofill, integrated Instant Apps, Google Play Protect, faster boot time, and much more.

We’re pushing the sources to Android Open Source Project (AOSP) for everyone to access today. Pixel and Nexus 5X/6P builds have entered carrier testing and we expect to start rolling out in phases over the next several weeks, alongside Pixel C and Nexus Player. Android Beta users will receive the update to the final version today and images are available to download and flash manually. We’ve been working closely with our partners over the last many months, and by the end of this year, hardware makers like Essential, General Mobile, HMD Global Home of Nokia Phones, Huawei, HTC, Kyocera, LG, Motorola, OnePlus, Samsung, Sharp and Sony are scheduled to be launching or upgrading new devices to Android 8.0 Oreo.

What’s in Android Oreo?

In Android 8.0 Oreo we focused on creating fluid experiences that make Android even more powerful and easy to use, such as:

  • Picture-in-picture lets users manage two tasks simultaneously on any size screen, and it’s easy for apps to support it. (Shown at right)
  • Notification dots extend the reach of notifications and offer a new way to surface activity in your apps. Dots work with zero effort for most apps — we even extract the color of the dot from your icon.
  • Autofill framework simplifies how users set up a new device and synchronize their passwords. Apps using form data can optimize their apps for Autofill, and password manager apps can use the new APIs to make their services available to users in their favorite apps. Autofill will roll out fully over the next few weeks as part of an update to Google Play Services.

We also invested in Android Vitals, a project focused on optimizing battery life, startup time, graphics rendering, and stability, while giving developers better visibility over the health of their apps:

  • System optimizations: We worked across the system to help apps run faster and smoother — for example, in the runtime we added a new concurrent compacting garbage collection, code locality, and more.
  • Background limits: We added new limits on background location and wi-fi scans and changes in the way apps run in the background. These boundaries prevent unintentional overuse of battery and memory and apply to all apps — make sure you understand and account for these in your apps.
  • Complementary Android Vitals dashboards and IDE profilers: In the Play Console you can now see aggregate data about your app to help you pinpoint common issues – excessive crash rate, ANR rate, frozen frames, slow rendering, excessive wakeups, and more. You’ll also find new performance profilers in Android Studio 3.0, and new instrumentation in the platform.
In Android 8.0 your app can directly pin a specific app shortcut in the launcher to drive engagement (left). Notification dots keep users active in your app and let them jump directly to the app’s core functions (right).

For developers, Android Oreo includes many new capabilities to help you build better, more efficient apps. Here are just a few:

  • Autosizing textview: Use autosizing TextView to automatically fill a TextView with text, regardless of the amount. You can create an array of preset text sizes, or set min and max sizes with a step granularity, and the text will grow and shrink to fill the available TextView space.
  • Fonts in XML: Fonts are now a fully supported resource type. You can now use fonts in XML layouts and define font families in XML.
  • Downloadable fonts and emoji: With downloadable fonts you can load fonts from a shared provider instead of including them in your APK. The provider and support library manage the download of fonts and shares them across apps. The same implementation also supports downloadable emoji, so you can get updated emoji without being limited to the emoji built into the device.
  • Adaptive icons: You can now create adaptive icons that the system displays in different shapes, based on a mask selected by a device manufacturer. The system also animates interactions with the icons, and uses them in the launcher, shortcuts, settings, sharing dialogs, and in the overview screen.
Adaptive icons display in a variety of shapes across different device models.
  • Shortcut pinning: App shortcuts and homescreen widgets are great for engaging users and now you can let users add and pin shortcuts and widgets to the launcher from within your app. There’s also a new option to add a specialized activity to help users create shortcuts. The activity is complete with custom options and confirmation.
  • Wide-gamut color for apps: Imaging apps can now take full advantage of new devices that have a wide-gamut color capable display. To display wide gamut images, apps enable a flag in their manifest files (per activity) and load bitmaps with an embedded wide color profile (AdobeRGB, Pro Photo RGB, DCI-P3, etc.).
  • WebView enhancements: In Android Oreo, we’ve enabled WebView multiprocess mode by default and added an API to let your app handle errors and crashes. You can also opt in your app’s WebView objects to verify URLs through Google Safe Browsing.
  • Java 8 Language APIs and runtime optimizations: Android now supports several new Java Language APIs, including the new java.time API. In addition, the Android Runtime is faster than ever before, with improvements of up to 2x on some application benchmarks.

Learn more about these and other new features by visiting the Android 8.0 Oreo site on developer.android.com. Also check out the What’s New in Android Oreo? video for an overview of new features for developers.

Make sure your apps are ready

If haven’t already, take a few moments today to test your apps and make sure they offer the experience you want for users upgrading to Android Oreo.

Just install your current app from Google Play onto a device or emulator running Android Oreo and test the user flows. The app should run and look great, and handle the Android Oreo behavior changes properly. In particular, pay attention to background location limits, notification channels, and changes in networking, security, and identifiers.

Once you’ve resolved any issues, publish your app updates to Google Play in your alpha, beta, or production channels so that they’re available as users start to receive Android 8.0 Oreo.

Speed your development with Android Studio

When you’re ready to build with new APIs in Android Oreo, we recommend updating to the latest version of Android Studio 3.0, available for download from the beta channel. Aside from improved app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 makes it easier to develop with Instant Apps, XML Fonts, downloadable fonts, and adaptive icons.

Android Studio 3.0 includes tools for developing with Android Oreo features, such as previewing XML font resources in your app.

We also recommend updating to the Android Support Library 26.0.2, available now from Google’s Maven repository, and to the latest SDK, tools, and emulator system images, available in the SDK Manager.

If you’re just getting started building for Android Oreo, read the migration guide first. It gives you an overview of the process and the configuration changes you’ll need to make.

To compile against the official Android 8.0 APIs, update your project’s compileSdkVersion to API 26. We also recommend updating your app’s targetSdkVersion to API 26 to opt-in and test your app with Android Oreo specific behavior changes. See the migration guide for details on how to set up your environment to build with Android Oreo.

Publish your updates to Google Play

Google Play is open for apps compiled against or targeting API 26. 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 Oreo as well as older versions. We recommend using Google Play’s beta testing feature to get early feedback from a small group of users, then do a staged rollout. 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! You can file a new issue against Android 8.0 in the AOSP issue tracker.

Thanks again to the many developers and early adopters who participated in the Android O Developer Preview and public beta. You gave us great feedback, and filed hundreds of issues that helped us to make the Android Oreo platform great for consumers and developers.

Google releases source for Google I/O 2017 for Android

Posted by Shailen Tuli

Today we’re releasing the source
for the official Google
I/O 2017
for Android app.

This year’s app substantially modifies existing functionality and adds several
new features. It also expands the tech stack to use Firebase.
In this post, we’ll highlight several notable changes to the app as well as
their design considerations.

The most prominent new feature for 2017 is the event
reservation system, designed to help save in-person attendees’
time and provide a streamlined conference experience. Registered attendees could
reserve sessions and join waitlists prior to and during the conference; a
reservation provided expedited entry to sessions without having to wait in long
lines. Reservation data was synced with attendees’ conference badges, allowing
event staff to verify reservations using NFC-enabled phones. Not only was the
reservation feature incredibly popular, but the reservation data helped event
staff change the size of session rooms both before and during I/O to adjust for
actual demand for seats.

The reservation feature was implemented using Firebase Realtime
(RTDB) and Cloud Functions for
. RTDB provided easy sync across user devices — we just had to
implement a listener in our code to receive database updates. RTDB also provided
out-of-the-box offline support, allowing conference data to be available even in
the face of intermittent network connectivity while traveling. A Cloud Function
processed reservation requests in the background for the user, using
transactions to ensure correctness of state (preventing mischievous users from
grabbing too many seats!) and communicating with the event badging system.

As in previous years, we used a ContentProvider as an abstraction layer over all
app data, which meant we had to figure out how to integrate RTDB data with the
ContentProvider. We needed to negotiate between having two local caches for
data: 1) the extant local SQLite database accessed via the ContentProvider, and
2) the local cache created by RTDB to facilitate offline access. We decided to
integrate all app data under the ContentProvider: whenever reservation data for
the user changed in RTDB, we updated the ContentProvider, making it the single
source of truth for app data at all times. This meant that we needed to keep
open connections to RTDB only on a single screen, the Session Detail Activity,
where users might be actively managing their reservations. Reservation data
displayed in other parts of the app was backed by the ContentProvider. In
offline mode, or in case of a flaky or delayed connection to RTDB, we could just
get the last known state of the user’s reservations from the ContentProvider.

We also had to figure out good patterns for integrating RTDB into the overall
sync logic of IOSched, especially since RTDB comes with a very different sync
model than the ping-and-fetch approach we were using in the app. We decided to
continue using Cloud Endpoints
to synchronize user data across devices and with the web and iOS clients (the
data itself was stored in Datastore).
While RTDB provides out-of-the-box data syncing, we wanted to make sure that a
user’s reservation data was current across all devices, even when the app
was not in the foreground.
We used a Cloud Function to integrate RTDB
reservation data into the sync flow: once reservation data for a user changed in
RTDB, the function updated the endpoint, which triggered a Firebase Cloud
downstream message to all the user’s devices, which then scheduled
data syncs.

This year’s app also featured a Feed to apprise users about
hour-by-hour developments at I/O (most of the app’s users were remote, and the
Feed was a window into the conference for them). The Feed was also powered by
RTDB, with data pushed to the server using a simple CMS. We used a Cloud
Function to monitor RTDB feed data; when feed data was updated on the server,
the Function sent a Cloud Messaging downstream message to clients, which
visually surfaced the presence of new feed items to the user.

In 2015 and 2016, we had adopted an MVP architecture for IOSched, and we
continued using that this year. This architecture provides us with good
separation of concerns, facilitates testing, and in general makes our code
cleaner and easier to maintain. For the Feed feature, we decided to experiment
with a more lightweight MVP implementation inspired by Android
Architecture Blueprints
, which provided the necessary modularity while being
very easy to conceptualize. The goal here was both pedagogical and practical: we
wanted to showcase an alternate MVP pattern for developers; we also wanted to
showcase an architecture that was an appropriate fit for our needs for this

For the first time, IOSched made heavy use of Firebase Remote
. In the past, we had found ourselves unable to inform users when
non-session data – wifi information, shuttle schedule, discount codes for
ridesharing, etc. – changed just before or during the conference. Forcing an app
update was not feasible; we just wanted in-app default values to be updatable.
Using remote config easily solved this problem for us.

In the end, we ended up with a three-tier system of informing users about

  1. Conference data and user data changes were communicated via Cloud Messaging
    and data syncs (ping and fetch model).
  2. Feed data changes were controlled via RTDB.
  3. Changes to in-app constants were controlled via Remote Config.

Future plans

Even though we’re releasing the 2017 code, we still have work ahead of us for
the coming months. We’ll be updating the code to follow modern patterns for
background processing (and making our app “O” compliant), and in the future
we’ll be adopting Android’s Architecture
to simplify the overall design of the app. Developers can follow
changes to the code on GitHub.

500 million devices now supported for Android Instant Apps

Posted by Jonathan Karmel

Since our public launch at Google I/O this year, we’ve been hard at work expanding the number of supported devices and the availability of instant apps, so that users can run your apps instantly, without installation. We’re excited to announce that 500 million Android users now have access to instant apps across countries where Google Play operates.

A number of Google Play apps and games businesses across a range of industries have already started building with instant apps. Following the launch of their instant apps, they have seen strong results in engagement, acquisition and retention.

Vimeo: WIth more than 50M creators and 240M viewers worldwide, Vimeo has built a platform whereby people can easily share videos with friends. The company wanted to implement Android Instant Apps to enable their audience to easily immerse themselves in content through a native app experience. Vimeo increased session duration by 130% with their instant app. Discover how Vimeo drove increased engagement with their instant app.
Jet: Based in the US, Jet provides a shopping platform, using a real-time savings engine to surface opportunities for customers to pay less. The company wanted to expand the reach of their existing app, and updated their app in order to support instant apps. Following the launch of their instant app, Jet found that their conversion rate increased by 27%. Learn about how Jet launched their instant app.
NYTimes Crosswords: The NYTimes Crosswords instant app provides users with crossword puzzles as printed in the New York Times daily newspaper. Their aim was to create a more native experience for their audience, increasing app engagement. Instant apps have 2x the number of sessions per user. Based on early results, they are also seeing more effective acquisition, conversion, and long term retention. Learn more about how NYTimes increased app sessions.
dotloop: dotloop is a real estate transaction platform which makes it easier for real estate professionals to interact with home buyers and sellers, and for them to be able to sign documents anytime, anywhere. Their aim for instant apps was to provide more users a native app experience for the signing process of documents. dotloop increased their key metric with a 62% increase in users who sign a document. Discover how dotloop supported Android Instant Apps and increased engagement.
Onefootball: Based in Berlin, the app provides news, live scores, fixtures, results, tables and stats for over 230 leagues and 15 languages. Onefootball built an instant app by reducing its APK size alongside other updates. The number of users who read news and share content increased 55% in their instant app. Find out more about how Onefootball increased engagement following their launch.
Realtor.com: A leading online real estate destination that attracts nearly 60 million unique visitors each month to its desktop and mobile platforms. Realtor.com enabled Android Instant Apps support by modularizing its 12 MB app into instant app modules. With Instant Apps, Realtor.com increased their key conversion metrics having doubled the number of leads per property listing details pageview. Find out how Realtor.com reduced its instant app APK size.

Learn more best practices for managing your download size with Android Instant Apps, and also visit g.co/instantapps for more information on building instant apps and get started today!

How useful did you find this blogpost?

Android Instant Apps: Best practices for managing download size

Posted by Dmitry Malykhanov, Developer Relations Partner, Google Play
Android Instant Apps provides rich, native experiences at the tap of a web link. People can experience your app without upfront installation, enabling a higher level and quality of engagement.
However, to provide comparable latency of loading a mobile webpage, an instant app needs to be lean and well structured, so it can be downloaded and run quickly in response to a URL tap. In light of that, we encourage that the binary loaded in response any entry-point URL is as small as possible, with a maximum of 4MB. The smaller the binaries, the faster the instant app will load and the smoother the user experience.
This document will propose best practices for managing the application structure and binary size to enable a smooth instant app experience. These practices will also benefit your installable app.

Refactoring your codebase

The biggest binary size benefit comes from refactoring your app into multiple feature modules. Even if your current size and feature set don’t require multiple features, we recommend designing for it, so you can quickly add more features in the future without affecting the binary size of existing features. We also highly recommend having a unified modular codebase to produce both installable and instant application binaries, as this will reduce the burden of maintaining separate projects and code and provide a cleaner project structure across both. Based on the experience of our early access partners, we believe this will have the largest impact to the binary size at download. However, it also requires the most investment.
To get to that end, you can start with a single (base) module and then refactor code by moving relevant portions to feature module(s). Note that you do not need to worry about the binary size while developing your instant app, as the size limit does not apply for locally built binaries. You can also publish your binary through the Play Developers Console to the Development track (special track for quick deployment of your instant app during development), where the size limit is 10MB. [1, 2] The 4MB restriction is applied once your binary graduate out of the Development track.
Each feature module can have one (or more) entry points – activities – that correspond to a given URL. When splitting a single code base into multiple modules, you will have different entry points for different features, and the platform will load the relevant feature as needed. Remember, the total binary to be downloaded for any given entry point should be under 4MB, so the combined size of any feature module and the base module must be below 4MB.

It is advised to define the feature–activity–entry point mappings first, and then structure the refactoring effort towards reducing the binary size for each entrypoint..
Also consider how your libraries are included. If a specific feature module requires certain libraries they should be included in the feature module only, instead of being added in the base APK. This will reduce the size of the base module. For example, let’s say you have an application that depends on libraries X, Y, and Z. Initially, you may pack all the libraries in the base module by placing all the dependencies in the base gradle.build file. But if only the code in the feature module requires library Z, it makes sense to move that dependency from the base module to the feature module.This works as long as no other feature modules depend on the same library. If multiple feature modules use the same library it definitely makes sense to keep it in the base module.

Lint checks

Many apps tend to acquire a lot of resources, and over a period of time, some of them are no longer used. Android Studio has useful built in lint check for unused resources. Press Alt+Ctrl+Shift+I (Cmd+Alt+Shift+I on Mac OS), type “unused resources” and start “Unused resources Android|Lint|Performance” inspection. It helps to reduce the size of the installable APK as well.

String resources

Similar to resources, pay attention to strings, not all of them may be in use, and typically the application size can be reduced significantly by removing unused string resources. If application supports multiple languages, you may want to reduce the number of localized resources, as it typically removes large chunks of the resources assets. This is especially important if the app supports only a few languages but uses AppCompat library, which includes messages in multiple languages. Use resConfig to select specific resources configurations only. Hint: typically you can use “auto” to restrict configurations pulled from third-party libraries to match the set of configurations defined in your project.

Switch to WebP

Significant reduction of the drawable resources size may be achieved by switching to WebP images instead of PNGs. Android Instant Apps supports all features of the WebP format (transparency, lossless, etc.) so there will be no loss in functionality. Keep in mind that application launcher icons must use PNG format, but it should not be a problem since projects normally keep those in mipmap- directories. If a backward compatible solution is required, you need to include the original PNG images in the APK module and it will override WebP resources automatically (main source set overrides all resources from AAR/feature module). [4]

Of course, going with vector drawables may let you save even more of the precious space, but using vector drawables will require a code change while the above mentioned trick with WebP images for the instant app and PNG images for the installable APK requires no code modifications.

Download assets at runtime

Finally, remember that technically there is no need to pack all the resources in the instant app APKs, as the application can download additional assets at run time. This approach also enables the app to download the required assets only. These modifications may require significant changes to the code base, but will also help you to reduce the size of the installable APK.
If shrinking resources does not bring your app feature modules size under the limit, it is time to look for the ways to reduce the code size.

Review native libraries

Some third-party libraries may include native code, which may not be used in the instant app at all. So the first step is to review the native libraries packaged within the APK and make sure the instant app has only those that are actually used. Remember to look into the compiled APK using APK Analyzer (Build -> APK Analyzer…) [5]

Review external libraries

Next review the list of all external libraries linked with the app’s code. You may find some unexpected surprises courtesy of transitive dependencies. Transitive dependencies occur when the library your project relies upon depends on another library, which in turn may depend on yet another library. Sometimes those transitive dependencies may contain unexpected surprises such as libraries you do not need at all (i.e. a JSON processing library you never use in your code.) Please see “Excluding transitive dependencies” section in the Gradle User Guide for further details.
Android Studio has several useful tools for analyzing the external dependencies for the project. It always helps to start with the Project view:

The “Project” view shows a section called “External libraries”, where you can see all the libraries used by the project including any transitive dependencies:

In order to further reduce the base feature size you may need to pay attention to the code dependencies and external libraries. Check the “Project” view and look for unused libraries that might be transitive dependencies the project does not need. Also look for libraries that provide the same functionality (e.g. multiple libraries for image loading/caching). [4]
You can also compare different builds with APK Analyzer tool, and it works with instant APKs, too.

Finally, review the list of transitive dependencies and exclude the ones you do not need. Use the following command to review the dependencies graph: gradle -q :MODULE:dependencies --configuration compile. Further details can be found in the Gradle documentation.

Other tips

Android Studio 3.0 includes the App Links Assistant tool, which can help to generate the necessary intent filters, and help in splitting the project into several modules. [3]

Once you got the instant app bundles under the size limit, it is the time to make sure the building process is up to date. Check that the application package and instant app APKs are signed using the “APK Signature Scheme v2“. If you sign the APKs using the latest version of the SDK tools, everything should be done automatically. However, if you manually sign the build artifacts you need to avoid using jarsigner and switch to apksigner instead.
And a few useful tips for adapting the app’s code to the instant runtime environment. Keep in mind that having a small branches of code for instant/installable applications, based on the InstantApps.isInstantApp(…), should be fine and typically does not make the source code unreadable (unless you abuse it, of course). Also, when using share intents make sure the code does not explicitly enumerate applications installed on the device, instant app security model does not allow that. Simply use regular Intent.createChooser() to present the list of all possible actions to the user.
The level of effort of developing an instant app for an existing Android application varies across developers and is heavily dependent on how your application is organized today. For some, it will be easy as your project is already organized as multiple modules. However, for some, the focus will be on reducing the code and resource assets size, and we have introduced tools and Android platform features above to help you with that.

Hear from other developers using Android Instant Apps

Finally, check out these great posts by developers that have already built an instant app:

Visit the Android Developers website to get started with Android Instant Apps and check out more instant apps success stories from other developers.

Playdemic drives user engagement and revenue with live game operations on Google Play

Posted by Adriana Puchianu, Developer Marketing, Google Play

Based in the UK, Playdemic is a free-to-play mobile games developer. Their leading game Golf Clash is designed to provide a short and fun, competitive experience. It uses a simple and accessible game mechanics based on one-thumb gaming which has generated substantial user engagement, with an average of 44 minutes played over three sessions a day. Golf Clash is now played by more than 1.5 million players every day whilst the average revenue per user is equal to other platforms.

Watch Paul Gouge, CEO & Co-founder, and Gareth Jones, Head of Production, discuss how Playdemic uses live game operations (“live ops”) to continuously engage players and grow their business on Google Play. Live ops are also referred to as “running games as a service”; they include the strategic distribution of content and interactions with players that are limited in time and are designed to increase engagement and monetization.

Watch more developer stories and learn about other features and best practices you can use to succeed on Google Play with the updated Playbook app.

How useful did you find this blogpost?