Jul 21

Your next growth market: Realizing the potential of MENA

Posted by Mohammad El-Saadi, BD, Google Play

We know that many developers want to take advantage of growth opportunities in
new regions, but are held back by not knowing the most important areas to focus
on. That’s why we wanted to share stories from our partners in the Middle East
and North Africa (MENA). It’s a fast growing region for Google Play, and one
that already represents a sizable revenue opportunity. They’ve shared their
experiences, and some key things to focus on if you’re thinking of launching in
the region.

Middle East and North Africa overview

MENA is a diverse region in terms of disposable income, access to connectivity,
and smartphone penetration. However, it is possible to broadly group MENA into
two types of market:

Growth markets

  • Examples: Saudi Arabia, United Arab Emirates (UAE), Kuwait and the rest of
    the Gulf Cooperation Council (GCC).

  • Very high smartphone penetration (on par with top western european markets),
  • Large disposable income
  • Robust growth in spend on mobile apps and games

Emerging markets

  • Examples: Morocco, Egypt and Iraq.
  • Large populations
  • Significant growth in smartphone (primarily Android) adoption.

Opportunities

Localization

If you want to be successful in MENA, localization is key. In Saudi Arabia 19 of
the top 20 grossing apps & games have their Google Play Store listing localized
and the majority of those have their actual app/game localized as well. By
localizing to Arabic, mobile app and game developers have found great success in
the region.

When Singapore-based Wego.com
localized to Arabic, they achieved over 200% YoY growth in
MENA
, grew their app rating from 3.5 to over 4.5 among Arab travelers
and increased Arab users’ retention rates by 200%. Today, MENA represents over
65% of their users.

To do localization well, here are a few things to consider:

  • Localize your store listing into Arabic including your video, screenshots
    and text. If you are targeting specific countries within MENA consider using
    local dialects, otherwise use formal Arabic. Consider using Store Listing
    Experiments to optimize your listing for local audiences.

  • If applicable, flip your app/game UI to be right-to-left.
  • Beware of common issues when localizing to Arabic: Arabic letters appearing
    disjointed or showing up in reverse order and the ordering of words getting
    mixed up when sentences contain both Latin and Arabic words

  • Localize pricing by showing appropriate local currency and rounding. Note
    that different countries in MENA have different currencies and
    affordability/willingness to pay.

  • Plan around major local events such as the holy month of Ramadan, when after
    fasting from dawn to sunset, families and loved ones gather for meals, laughs
    and stories. We’ve found that during this month usage of apps and games
    increases significantly in MENA.

  • Provide local customer support
  • Be culturally sensitive in your communication and content – avoid
    stereotypes and keep in mind the relatively conservative nature of users in the
    region

  • Leverage the power of YouTube to reach your audiences in MENA. Saudi Arabia
    for instance is the second largest market for YouTube globally in terms of views
    per capita.

Refer to our Localization
Checklist for some best practices when localizing for any language.

Gaming

Gaming is a high growth and revenue opportunity in MENA. Most countries in the
region have a median age of 30 or lower, smartphone growth will continue to grow
at double digits, which makes gaming a key segment for users in the region.
Today’s local top grossing charts and dominated by Midcore strategy games.
Interestingly, GCC countries have some of the highest Average Revenue Per Paying
User rates globally.

International titles, including Clash of Clans, Clash Royale, Mobile Strike and
Clash of Kings, have performed incredibly well in the region. In addition,
titles specifically targeting MENA have also seen tremendous success. Revenge of
the Sultans, by ONEMT, from China, has been the top grossing title across
several MENA countries for many months. Similarly, when IGG.com launched the
Arabic version of Castle Clash, they grew revenue from MENA by
58%
within 4 months.

As the market evolves, there is also a huge opportunity for other genres (such
as RPG, FPS, and sports) which are not present at scale in the region yet.

Google Play in MENA

We continue to invest in making sure that users are able to pay for their
favorite apps and games by launching locally relevant payment methods in MENA.
Today, we have carrier billing available with the major networks in Saudi
Arabia, UAE and Kuwait. We plan to expand coverage in more countries, including
Qatar and Bahrain, in the future.

We are also committed to increasing the quality and availability of Arabic apps
and games for MENA users, which is why we launched our Now
in Arabic collection
featuring apps and games that have recently localized to Arabic. This
collection will be regularly updated. If you’re interested in being included, submit
your localized app/game.


Android Developers Blog

Jul 20

Updating your games for modern Android


Posted by Tom Greenaway, Senior Partner Developer Advocate

Last year we announced that starting from August 2018 Google Play will require all new apps and games to target a recent Android API level – set to API level 26 (Android 8.0 Oreo), or higher. Additionally, this requirement will extend to updates for existing apps and games starting from November 2018.

Every new Android version introduces changes that bring significant security and performance improvements – and enhance the user experience of Android overall. Updating your games to target the latest API level ensures that your users can benefit from these improvements, while still allowing your games to run on older Android versions.

Simple next steps:

  • Install the Android 8.0 Oreo SDK (API level 26) via Android Studio by navigating to (Tools > Android > SDK Manager > Android SDK > SDK Platforms).
  • Update your game to target API level 26 and see whether your game has any incompatibilities or issues as soon as possible. Update any external dependencies as necessary. Learn more about the incremental changes between versions of Android here.
  • If you are using an advertising network, SDK or plugin which is incompatible with API level 26, reach out to your contacts and find out their timeline for supporting target API level 26. The sooner they’re aware of these changes the better.
  • If you build your game with Unity, support for target API 26 is built into Unity 5.6.5 and beyond. Simply ensure the latest target API level is selected in your Android build settings for Unity (Build Settings > Android > Player Settings). For versions of Unity 5.6.4 and prior, consult this documentation which includes a workaround for versions dating back to 4.3.
  • For games built with Unreal, check your Android platform settings has the “Target SDK Version” set to 26.
  • If you use Cocos2D-X, check the target API level in the gradle.properties file that is generated.

Significant changes to be aware of:

  • Since API 23, we have required permissions be requested at runtime which helps streamline the app install process.
  • Since API 24, apps can no longer dynamically link against non-NDK libraries. If your app (including third-party static libraries) contains native code, you should only be using public NDK APIs.
  • If your game uses Android push notifications, the Google Play Services SDK in your game will need to be updated to version 10.2.1 or above for your game to support API level 26.
  • If your game uses opaque binary blobs (OBB), then your game must check if it can access the directory before attempting to access the OBB files themselves. We recommend explicitly requesting permission for access using the Runtime Permissions API, and gracefully handling cases wherein the permission is not granted. Additionally, add an entry in the manifest for the external storage access:
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
    

Moving ahead

Remember, updating the target API level is just the first step – make sure your game is compatible with the behavior changes between your current target API level and API level 26. Check out further guidance on the changes in past versions of Android to help in your migration process. These policy changes are important for moving the Android ecosystem forward and keeping it healthy for our users – and yours.

How useful did you find this blog post?

★ ★ ★ ★ ★


Android Developers Blog

Jul 20

Calling European game developers, enter the Indie Games Contest by December 31

Originally posted on Google Developers blog

Posted by Matteo Vallone, Google Play Partner Development
Manager

To build awareness of the awesome innovation and art that indie game developers
are bringing to users on Google Play, we have invested heavily over the past
year in programs like Indie
Corner, as well as events like the Google Play Indie Games Festivals in
North
America and Korea.

As part of that sustained effort, we also want to celebrate the passion and
innovation of indie game developers with the introduction of the first-ever
Google Play
Indie Games Contest
in Europe. The contest will recognize the best
indie talent in several countries and offer prizes that will help you get your
game noticed by industry experts and gamers worldwide.

Prizes for the finalists and winners:

  • An open showcase held at the Saatchi Gallery in London
  • YouTube influencer campaigns worth up to 100,000 EUR
  • Premium placements on Google Play
  • Tickets to Google I/O 2017 and other top industry events
  • Promotions on our channels
  • Special prizes for the best Unity game
  • And more!

Entering the contest:

If you’re based in Czech Republic, Denmark, Finland, France (coming soon),
Germany, Iceland, Israel, Netherlands, Norway, Poland (coming soon), Romania,
Spain, Sweden, Turkey, or UK (excl. Northern Ireland), have 15 or less full time
employees, and published a new game on Google Play after 1 January 2016, you may
now be eligible to enter the
contest. If you’re planning on publishing a new game soon, you can also
enter by submitting a private beta. Check out all the details in the terms and
conditions. Submissions close on 31 December 2016.

The process:

Up to 20 finalists will get to showcase their games at an open event at the
Saatchi Gallery in London on the 16th February 2017. At the event, the top 10
will be selected by the event attendees and the Google Play team. The top 10
will then get the opportunity to pitch to a jury of industry experts, from which
the final winner and runners up will be selected.

Even if someone is NOT entering the contest:

Even if you’re not eligible to enter the contest, you can still register to
attend the final showcase event in London on 16 February 2017, check out some
great indie games, and have fun with various industry experts and indie
developers. We will also be hosting a workshop for all indie games developers
from across EMEA in the new Google office in Kings Cross the next day, so this
will be a packed week.

Get started:

Enter the Indie
Games Contest now
and visit the contest
site to find out more about the contest, the event, and the workshop.


Android Developers Blog

Jul 19

Final update to Android 7.1 Developer Preview

Posted by Dave Burke, VP of Engineering

Today we’re rolling out an update to the Android 7.1 Developer Preview — the
last before we release the final Android 7.1.1 platform to the ecosystem.
Android 7.1.1 includes the developer features already available on Pixel and
Pixel XL devices and adds optimizations and bug fixes on top of the base Android
7.1 platform. With Developer Preview 2, you can make sure your apps are ready
for Android 7.1.1 and the consumers that will soon be running it on their
devices.

As highlighted
in October, we’re also expanding the range of devices that can receive this
Developer Preview update to Nexus 5X, Nexus 6P, Nexus 9, and Pixel C.

If you have a supported device that’s enrolled in the Android Beta Program, you’ll receive an
update to Developer Preview 2 over the coming week. If you haven’t enrolled your
device yet, just visit the site to
enroll your device and get the update.

In early December, we’ll roll out Android 7.1.1 to the full lineup of supported
devices as well as Pixel and Pixel XL devices.

What’s in this update?

Developer Preview 2 is a release candidate for Android 7.1.1 that you can use to
complete your app development and testing in preparation for the upcoming final
release. In includes near-final system behaviors and UI, along with the latest
bug fixes and optimizations across the system and Google apps.

It also includes the developer features and APIs (API level 25) already
introduced in Developer Preview 1. If you haven’t explored the developer
features, you’ll want to take a look at app shortcuts,
round
icon resources, and image keyboard
support, among others — you can see the full list of
developer features here.

With Developer Preview 2, we’re also updating the SDK build and platform tools
in Android Studio, the Android 7.1.1 platform, and the API Level 25 emulator
system images. The latest version of the support library (25.0.1)
is also available for you to add
image keyboard support, bottom
navigation, and other features for devices running API Level 25 or earlier.

For details on API Level 25 check out the API
diffs and the updated API
reference on the developer preview
site.

Get your apps ready for Android 7.1

Now is the time to optimize your apps to look their best on Android 7.1.1. To
get started, update to Android
Studio 2.2.2 and then download the API Level 25 platform, emulator system
images, and tools through the SDK Manager in Android Studio.

After installing the API Level 25 SDK, you can update your project’s
compileSdkVersion to 25 to build and test against the new APIs. If you’re doing
compatibility testing, we recommend updating your app’s targetSdkVersion to 25
to test your app with compatibility behaviors disabled. For details on how to
set up your app with the API Level 25 SDK, see Set
up the Preview.

If you’re adding app shortcuts or circular launcher icons to your app, you can
use Android Studio’s built-in Image Asset Studio to quickly help you create
icons of different sizes that meet the material
design guidelines. You can test your round icons on the Google APIs emulator
for API Level 25, which includes support for round icons and the new Google
Pixel Launcher.


Android Studio and the Google APIs emulator let you quickly create and test
your round icon assets.

If you’re adding image keyboard support, you can use the Messenger and Google
Keyboard apps included in the preview system images for testing as they include
support for this new API.

Scale your tests using Firebase Test Lab for Android

To help scale your testing, make sure to take advantage of Firebase
Test Lab for Android and run your tests in the cloud at no charge during the
preview period on all virtual devices including the Developer Preview 2 (API
25). You can use the automated crawler (Robo Test) to
test your app without having to write any test scripts, or you can upload your
own instrumentation (e.g. Espresso) tests. You can upload your tests here.

Publish your apps to alpha, beta or production channels in Google
Play

After you’ve finished final testing, you can publish your updates compiled
against, and optionally targeting, API 25 to Google Play. You can publish to
your alpha, beta,
or even production channels in the Google Play Developer Console. In this way,
push your app updates to users whose devices are running Android 7.1, such as
Pixel and Android Beta devices.

Get Developer Preview 2 on Your Eligible Device

If you have an eligible device that’s already enrolled in the Android Beta Program, the device will get
the Developer Preview 2 update over the coming week. No action is needed on your
part. If you aren’t yet enrolled in program, the easiest way to get started is
by visiting android.com/beta and opt-in
your eligible Android phone or tablet — you’ll soon receive this preview update
over-the-air. As always, you can also download and flash
this update manually.

As mentioned above, this Developer Preview update is available for Nexus 5X,
Nexus 6P, Nexus 9, and Pixel C devices.

We’re expecting to launch the final release of the Android 7.1.1 in just a few
weeks Starting in December, we’ll roll out Android 7.1.1 to the full lineup of
supported preview devices, as well as the recently launched Pixel and Pixel XL
devices. At that time, we’ll also push the sources to AOSP, so our device
manufacturer partners can bring this new platform update to consumers on their
devices.

Meanwhile, we continue to welcome your feedback in the Developer
Preview issue tracker, N
Preview Developer community, or Android Beta
community as we work towards the final consumer release in December!


Android Developers Blog

Jul 18

Google Play services and Firebase for Android will support API level 14 at minimum

Posted by Doug Stevenson, Developer Advocate

Version 10.0.0 of the Google Play services client libraries, as well as the
Firebase client libraries for Android, will be the last version of these
libraries that support Android API
level 9 (Android 2.3, Gingerbread). The next scheduled release of these
libraries, version 10.2.0, will increase the minimum supported API level from 9
to 14 (Android 4.0.1, Ice Cream Sandwich). This change will happen in early
2017.

Why are we discontinuing support for Gingerbread and Honeycomb in Google
Play services?

The Gingerbread platform is almost six years old. Many Android developers have
already discontinued support for Gingerbread in their apps. This helps them
build better apps that make use of the newer capabilities of the Android
platform. For us, the situation is the same. By making this change, we will be
able to provide a more robust collection of tools for Android developers with
greater speed.

What this means for your Android app that uses Google Play services or
Firebase:

You may use version 10.0.0 of Google Play services and Firebase as you are
currently. It will continue to work with Gingerbread devices as it has in the
past.

When you choose to upgrade to the future version 10.2.0, and if your app
minimally supports API level 14 or greater (typically specified as
“minSdkVersion” in your build.gradle), you will not encounter any versioning
problems. However, if your app supports lower than API level 14, you will
encounter a problem at build time with an error that looks like this:

Error:Execution failed for task ':app:processDebugManifest'.
> Manifest merger failed : uses-sdk:minSdkVersion 9 cannot be smaller than version 14 declared in library [com.google.android.gms:play-services:10.2.0]
        Suggestion: use tools:overrideLibrary="com.google.android.gms:play_services" to force usage

Unfortunately, the stated suggestion will not help you successfully run your app
on older devices. In order to use Google Play services 10.2.0 and later, you
can choose one of the following options:

1. Target API level 14 as the minimum supported API level.

This is the recommended course of action. To discontinue support for API levels
that will no longer receive Google Play services updates, simply increase the
minSdkVersion value in your app’s build.gradle to at least 14. If you update
your app in this way and publish it to the Play Store, users of devices with
less than that level of support will not be able to see or download the update.
However, they will still be able to download and use the most recently published
version of the app that does target their device.

A very small percentage of all Android devices are using API levels less than
14. You can read more about
the current distribution of Android devices. We believe that many of these
old devices are not actively being used.

If your app still has a significant number of users on older devices, you can
use multiple APK support in Google Play to deliver an APK that uses Google Play
services 10.0.0. This is described below.

2. Build multiple APKs to support devices with an API level less than
14.

Along with some configuration and code management, you can build
multiple APKs that support different minimum API levels, with different
versions of Google Play services. You can accomplish this with build
variants in Gradle. First, define build flavors for legacy and newer
versions of your app. For example, in your build.gradle, define two different
product flavors, with two different compile dependencies for the components of
Play Services you’re using:

productFlavors {
    legacy {
        minSdkVersion 9
        versionCode 901  // Min API level 9, v01
    }
    current {
        minSdkVersion 14
        versionCode 1401  // Min API level 14, v01
    }
}

dependencies {
    legacyCompile 'com.google.android.gms:play-services:10.0.0'
    currentCompile 'com.google.android.gms:play-services:10.2.0'
}

In the above situation, there are two product flavors being built against two
different versions of the Google Play services client libraries. This will work
fine if only APIs are called that are available in the 10.0.0 library. If you
need to call newer APIs made available with 10.2.0, you will have to create a
compatibility library for the newer API calls so that they are only built into
the version of the application that can use them:

  • Declare a Java interface that exposes the higher-level functionality you
    want to perform that is only available in current versions of Play services.

  • Build two Android libraries that implement that interface. The “current”
    implementation should call the newer APIs as desired. The “legacy”
    implementation should no-op or otherwise act as desired with older versions of
    Play services. The interface should be added to both libraries.

  • Conditionally compile each library into the app using “legacyCompile” and
    “currentCompile” dependencies.

  • In the app’s code, call through to the compatibility library whenever newer
    Play APIs are required.

After building a release APK for each flavor, you then publish them both to the
Play Store, and the device will update with the most appropriate version for
that device. Read more about multiple
APK support in the Play Store.


Android Developers Blog

Jul 15

Low-overhead rendering with Vulkan

Posted by Shannon Woods, Technical Program Manager

Developers of games and 3D graphics applications have one key challenge to meet: How complex a scene can they draw in a small fraction of a second? Much of the work in graphics development goes into organizing data so it can be efficiently consumed by the GPU for rendering. But even the most careful developers can hit unforeseen bottlenecks, in part because the drivers for some graphics processors may reorganize all of that data before it can actually be processed. The APIs used to control these drivers are also not designed for multi-threaded use, requiring synchronization with locks around calls that could be more efficiently done in parallel. All of this results in CPU overhead, which consumes time and power that you’d probably prefer to spend drawing your scene.

Lowering overhead and handing control to developers

In order to address some of the sources of CPU overhead and provide developers with more explicit control over rendering, we’ve been working to bring a new 3D rendering API, Vulkan™, to Android. Like OpenGL™ ES, Vulkan is an open standard for 3D graphics and rendering maintained by Khronos. Vulkan is being designed from the ground up to minimize CPU overhead in the driver, and allow your application to control GPU operation more directly. Vulkan also enables better parallelization by allowing multiple threads to perform work such as command buffer construction at once.

An API is only useful if it does what you expect

To make it easier to write an application once that works across a variety of devices, Android 5.0 Lollipop significantly expanded the Android Compatibility Test Suite (CTS) with over fifty thousand new tests for OpenGL ES, and many more have been added since. This provides an extensive open source test suite for identifying problems in drivers so that they can be fixed, creating a more robust and reliable experience for both developers and end users. For Vulkan, we’ll not only develop similar tests for use in the Android CTS, but we’ll also contribute them to Khronos for use in Vulkan’s own open source Conformance Test Suite. This will enable Khronos to test Vulkan drivers across platforms and hardware, and improve the 3D graphics ecosystem as a whole.

It’s all about developer choice

We’ll be working hard to help create, test, and ship Vulkan, but at the same time, we’re also going to contribute to and support OpenGL ES. As a developer, you’ll be able to choose which API is right for you: the simplicity of OpenGL ES, or the explicit control of Vulkan. We’re committed to providing an excellent developer experience, no matter which API you choose.

Vulkan is still under development, but you’ll be able to find specifications, tests, and tools once they are released at http://www.khronos.org/vulkan.


Android Developers Blog

Jul 14

Pixel Security: Better, Faster, Stronger

Posted by Paul Crowley, Senior Software Engineer and Paul Lawrence, Senior Software Engineer

Encryption protects your data if your phone falls into someone else’s hands. The
new Google Pixel and Pixel XL are encrypted by default to offer strong data
protection, while maintaining a great user experience with high I/O performance
and long battery life. In addition to encryption, the Pixel phones debuted
running the Android Nougat release, which has even more security
improvements.

This blog post covers the encryption implementation on Google Pixel devices and
how it improves the user experience, performance, and security of the device.

File-Based Encryption Direct Boot experience

One of the security features introduced in Android Nougat was file-based
encryption. File-based encryption (FBE) means different files are encrypted
with different keys that can be unlocked independently. FBE also separates data
into device encrypted (DE) data and credential encrypted (CE) data.

Direct
boot uses file-based encryption to allow a seamless user experience when a
device reboots by combining the unlock and decrypt screen. For users, this means
that applications like alarm clocks, accessibility settings, and phone calls are
available immediately after boot.

Enhanced with TrustZone® security

Modern processors provide a means to execute code in a mode that remains secure
even if the kernel is compromised. On ARM®-based processors this mode is known
as TrustZone. Starting in Android Nougat, all disk encryption keys are stored
encrypted with keys held by TrustZone software. This secures encrypted data in
two ways:

  • TrustZone enforces the Verified Boot
    process. If TrustZone detects that the operating system has been modified, it
    won’t decrypt disk encryption keys; this helps to secure device encrypted (DE)
    data.

  • TrustZone enforces a waiting period between guesses at the user credential,
    which gets longer after a sequence of wrong guesses. With 1624 valid four-point
    patterns and TrustZone’s ever-growing waiting period, trying all patterns would
    take more than four years. This improves security for all users, especially
    those who have a shorter and more easily guessed pattern, PIN, or
    password.

Encryption on Pixel phones

Protecting different folders with different keys required a distinct approach
from full-disk
encryption (FDE). The natural choice for Linux-based systems is the
industry-standard eCryptFS. However, eCryptFS didn’t meet our performance
requirements. Fortunately one of the eCryptFS creators, Michael Halcrow, worked
with the ext4 maintainer, Ted Ts’o, to add encryption natively to ext4, and
Android became the first consumer of this technology. ext4 encryption
performance is similar to full-disk encryption, which is as performant as a
software-only solution can be.

Additionally, Pixel phones have an inline hardware encryption engine, which
gives them the ability to write encrypted data at line speed to the flash
memory. To take advantage of this, we modified ext4 encryption to use this
hardware by adding a key reference to the bio structure, within the ext4 driver
before passing it to the block layer. (The bio structure is the basic container
for block I/O in the Linux kernel.) We then modified the inline encryption block
driver to pass this to the hardware. As with ext4 encryption, keys are managed
by the Linux keyring. To see our implementation, take a look at the source
code for the Pixel kernel.

While this specific implementation of file-based encryption using ext4 with
inline encryption benefits Pixel users, FBE is available in AOSP and ready to
use, along with the other features mentioned in this post.


Android Developers Blog

Jul 11

How creating an Action can complement your Android app


Posted by Neto Marin – Actions on Google Developer Advocate

There are millions of apps in the Android ecosystem, so helping yours get discovered can require some investment. Your app needs to offer something that differentiates it from other similar apps to stand out to users.

Building a companion Action is a fast and simple way to increase your Android app’s potential reach by creating a new entrypoint from devices covered by the Google Assistant. This lets you bring your services to users without needing to install anything through voice, and can bring people into your app when it can provide more value.

Your companion Action complements your Android app’s experience by offering some of your services through the Google Assistant, which is available on more than 500 million devices including speakers, phones, cars, headphones, and more. Creating an Action provides a frictionless way for users to start engaging with your services wherever the Google Assistant is available.

Creating an Action for the Assistant will extend your brand presence, bringing your services to new devices and contexts as users interact with the Google Assistant.

Feature what your app does better

It is probably a mistake to try to rewrite all of your Android app as a conversational Action, since voice is a different modality with different constraints and usage patterns. Instead, you should start by selecting the most important or popular features in your app that translate well into a voice context and can be more easily accomplished there. Then, you can create your conversational experience to offer these features on Google Assistant devices. Check out the Conversation design site, which has several articles and guides about how to create a great voice UI.

Let’s take a look at a hypothetical example. Imagine you have a mobile commerce app. Some features include searching for products, navigating to different categories, adding payment information, and checking out. You could build an Action for the Assistant with most of the same functionality, but we encourage you to look for what makes the most sense in a conversational experience.

In this case, your Action could focus on everything that a user would want to know after they’ve purchased a product through your Android app or web page. You could offer a quick way to get updates about a purchase’s status (if you provide different states for payment/purchase process) and shipment information, or provide an interface for re-ordering a user’s favorite products. Then, your users would be able to ask something like, “Hey Google, ask Voice Store about my last purchase.”

Or, to reach users who have never made a purchase before, you could create an Action to offer exciting deals for common products. For example, you could create an Action that is invoked with, “Hey Google, ask Voice Store what are the deals on TVs today”.

As you can see, starting with a “hero” use case for your Action is an exciting way to introduce conversational features that complement your Android app, and it will take less time than you think.

At Google I/O 2018, we presented a talk, “Integrating your Android apps with the Google Assistant” which contains more details and examples for developers.

Delivering user’s purchases across surfaces

In-app purchases, subscriptions, and one-time products have proven successful for Android developers when it comes to monetization, allowing developers to offer different kinds of digital goods and additional value for paying users. These types of monetization are proven to drive user conversion and make the app more profitable.

Google Play Billing offers a series of tools, APIs, and documentation to help developers manage the subscription life-cycle, build server-side validation, and much more. If you are new to in-app billing, check out the Google Play Billing Overview page.

Now, Android developers can expand where users can access these goods or upgraded experiences by offering them through Actions, as well. This expansion is accomplished by honoring the user’s entitlements on Google Play across different surfaces and devices, reaching users when they can’t (or don’t want to) use an app, like while cooking or driving.

For non-Android platforms, you’ll need to ask your users to link their accounts. You can then use your user’s account history to identify what purchases they’ve made on other surfaces.

Check the Accessing Digital Purchases page for a step-by-step guide on how to enable access to the user’s purchases and request and parse the purchase data.

What’s next?

If you are not familiar with Actions on Google yet, start by checking out our overview page, which describes the platform in detail and tells you all you need to know to create your Actions for the Google Assistant.

Stay tuned for more posts about how to improve your Android app experience with Actions on Google.

Thanks for reading!


Android Developers Blog

Jul 10

Android Emulator – AMD Processor & Hyper-V Support


Posted by Jamal Eason, Product Manager, Android

Since the major revamp of the Android Emulator two years ago, we have focused on delivering a fast and feature-rich emulator to help you build great app experiences for users. Today, the Android Emulator is the top device deployed to from Android Studio — more than 2x over physical Android devices. We are humbled to hear from many of you that the Android Emulator has come a long way, but we are not done yet.

Making the Android Emulator faster is one of the top priorities for the Android Studio team. Over the last few releases, we have launched quick boot & emulator snapshots for quickly starting and resuming emulator sessions in under 2 seconds. Up until now, our emulator experience has almost universally worked on macOS® and Linux computers. But for users of Microsoft® Windows® or the Microsoft® Hyper-V platform, our hardware accelerated speed enhancements for the Android Emulator only worked with computers with Intel® processors. Support for AMD® processors and Microsoft Hyper-V hypervisor are two long-standing user requests from the Android developer community that we are happy to address with this Android Emulator update.

Today, you can download the latest Android Emulator release, which is enabled to run x86 based Android Virtual Devices (AVD) on computers that use AMD processors. This exciting update makes the Android Emulator more accessible to a new set of Android app developers that were previously limited to software emulation, but can now have hardware accelerated performance. Moreover, for those of you who use Hyper-V to run your local app backend, the Android Emulator can now also coexist with other Hyper-V-backed applications on Windows® 10.

Thanks to a new Microsoft Windows Hypervisor Platform (WHPX) API and recent open-source contributions from Microsoft, even more Android app developers can take advantage of all the speed improvements and features in the Android Emulator.

Android Emulator running on Windows 10 with AMD Processor
Screenshot Configuration: Asus ROG Strix GL 702ZC, Processor: AMD® Ryzen 7 1700 Processor, Chipset: AMD 5350, Graphics: AMD® Radeon RX580

Support for these technologies was initially available in the v27.3.8 Android Emulator canary release and today we are releasing this set of preview features (AMD processor & Hyper-V support) on the stable channel for more feedback. Alongside this update, we have added additional speed improvements in loading emulator snapshots for those developers using the Intel® Hardware Accelerated Execution Manager (HAXM).

How to use

Linux

If you use Linux for Android app development, the Android Emulator will continue to use the native Kernel-based Virtual Machine (KVM) hypervisor for both Intel and AMD based computers for a fast and performant virtualization solution. An update to the v27.3.8 Android Emulator will offer you the new snapshots UI along with improvements to performance, reliability and resource usage.

macOS

For OS X v10.10 Yosemite and higher, the Android Emulator uses the built-in Hypervisor.Framework by default, and falls back to using the Intel Hardware Accelerated Execution Manager (HAXM) if Hypervisor.Framework fails to initialize (such as when running on OS X v10.9 or earlier). Once you update to the latest Android Emulator on macOS, you will also have access to the new snapshots UI along with under the hood performance and reliability improvements.

Android Emulator – Snapshots Extended Controls

Microsoft Windows

On Intel x86-based computers, the Android Emulator will continue to use Intel HAXM by default. Intel HAXM is a mature and open-sourced hypervisor solution developed by Intel. Thanks to on-going development by Intel, the fastest emulator performance on Windows is still with Intel HAXM. To download the latest Intel HAXM v7.2.0, check for updates in the Android SDK Manager.

If you have an AMD processor in your computer you need the following setup requirements to be in place:

  • AMD Processor – Recommended: AMD® Ryzen processors
  • Android Studio 3.2 Beta or higher – download via Android Studio Preview page
  • Android Emulator v27.3.8+ – download via Android Studio SDK Manager
  • x86 Android Virtual Device (AVD) – Create AVD
  • Windows 10 with April 2018 Update
  • Enable via Windows Features: “Windows Hypervisor Platform”

Windows Hypervisor Platform setting in Windows 10

If you want to use Hyper-V at the same time as the Android Emulator on your Intel processor-based computer, you will also need the same Android Studio and Android Emulator versions as listed above, but with the additional requirements:

  • Enable via Windows Features: “Hyper-V” – Only available for Windows 10 Professional/Education/Enterprise
  • Intel Processor : Intel® Core processor that supports Virtualization Technology (VT-x), Extended Page Tables (EPT), and Unrestricted Guest (UG) features. Additionally VT-x needs to be enabled in the BIOS.

For more setup tips and troubleshooting details, check out the documentation page.

Again, for existing Windows users who have an Intel-based processor, the Android Emulator will continue to use the faster and recommended Intel HAXM configuration. For those using AMD processors, and those who use Hyper-V hypervisors, this should be an exciting step forward to start using the Android Emulator.

Next Steps & Feedback

Download the latest Android Emulator from the Android Studio 3.2 Beta SDK Manager for the latest performance updates across all supported platforms that you are using. We are going to continue to invest in performance improvements for each of the platforms and we look forward to your feedback and feature requests.

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.


Android Developers Blog

Jul 07

Understanding APK packaging in Android Studio 2.2

Posted by Wojtek Kaliciński, Android Developer Advocate

Android Studio 2.2 launched recently with many
new and improved features. Some of the changes are easy to miss because they
happened under the hood in the Android Gradle plugin, such as the newly
rewritten integrated APK packaging and signing step.

APK Signature Scheme v2

With the introduction of the new APK Signature
Scheme v2 in Android 7.0 Nougat, we decided to rewrite how assembling APKs
works in the Android Gradle plugin. You can read all about the low-level
technical details of v2 signatures in the documentation,
but here’s a quick tl;dr summary of the info you need as an Android app
developer:

  • The cryptographic signature of the APK that is used to verify its integrity
    is now located immediately before the ZIP Central Directory.

  • The signature is computed and verified over the binary contents of the whole
    APK file, as opposed to decompressed file contents of each file in the archive
    in v1.

  • An APK can be signed by both v1 and v2 signatures at the same time, so it
    remains backwards compatible with previous Android releases.

Why introduce this change to how Android verifies APKs? Firstly, for enhanced
security and extensibility of this new signing format, and secondly for
performance – the new signatures take significantly less time to verify on the
device (no need for costly decompression), resulting in faster app installation
times.

The consequence of this new signing scheme, however, is that there are new
constraints on the APK creation process. Since only uncompressed file contents
were verified in v1, that allowed for quite a lot of modifications to be made
after APK signing – files could be moved around or even recompressed. In fact,
the zipalign tool which was part of the build process did exactly
that – it was used to align ZIP entries on correct byte boundaries for improved
runtime performance.

Because v2 signatures verify all bytes in the archive and not individual ZIP
entries, running zipalign is no longer possible after
signing
. That’s why compression, aligning and signing now happens in a
single, integrated step of the build process.

If you have any custom tasks in your build process that involve tampering with
or post-processing the APK file in any way, please make sure you disable them or
you risk invalidating the v2 signature and thus making your APKs incompatible
with Android 7.0 and above.

Should you choose to do signing and aligning manually (such as from the command
line), we offer a new tool in the Android SDK, called apksigner,
that provides both v1 and v2 APK signing and verification. Note that you need to
run zipalign before running apksigner
if you are using v2 signatures. Also remember the jarsigner tool
from the JDK is not compatible with Android v2 signatures, so you can’t use it
to re-sign your APKs if you want to retain the v2 signature.

In case you want to disable adding v1 or v2 signatures when building with the
Android Gradle plugin, you can add these lines to your signingConfig
section in build.gradle:

v1SigningEnabled false
v2SigningEnabled false

Note: both signing schemes are enabled by default in Android Gradle plugin 2.2.

Release builds for smaller APKs

We took this opportunity when rewriting the packager to make some optimizations
to the size of release APKs, resulting in faster downloads, smaller
delta updates on the Play Store, and less wasted space on the device. Here
are some of the changes we made:

  • Files in the archive are now sorted to minimize differences between APK
    builds.

  • All file timestamps and metadata are zeroed out.
  • Level 6 and level 9 compression is checked for all files in parallel and the
    optimal one is used, i.e. if L9 provides little benefit in terms of size, then
    L6 may be chosen for better performance

  • Native libraries are stored uncompressed and page aligned in the APK. This
    brings support for the android:extractNativeLibs="false" option
    from Android 6.0 Marshmallow and lets applications use less space on the device
    as well as generate smaller updates on the Play Store

  • Zopfli compression is not used to better support Play Store update
    algorithms. It is not recommended to recompress your APKs with Zopfli.
    Pre-optimizing individual resources such as PNG files in your projects is still
    fine and recommended.

These changes help make your releases as small as possible so that users can
download and update your app even on a slower connection or on less capable
devices. But what about debug builds?

Debug builds for installation speed

When developing apps you want to keep the iteration cycle fast – change code,
build, and deploy on a connected device or emulator. Since Android Studio 2.0
we’ve been working to make all the steps as fast as possible. With Instant Run
we’re now able to update only the changed code and resources during runtime,
while the new Emulator brings multi-processor support and faster ADB speeds for
quicker APK transfer and installation. Build improvements can cut that time even
further and in Android Studio 2.2 we’re introducing incremental packaging and
parallel compression for debug builds. Together with other features like
selectively packaging resources for the target device density and ABI this will
make your development even faster.

A word of caution: the APK files created for Instant Run or by invoking a debug
build are not meant for distribution on the Play Store! They contain additional
instrumentation code for Instant Run and are missing resources for device
configurations other than the one that was connected when you started the build.
Make sure you only distribute release versions of the APK which you can create
using the Android Studio Generate
Signed APK command or the assembleRelease Gradle task.


Android Developers Blog