Google Mobile Ads SDK v17.0.0 for Android has just been released, and it comes with two important changes that you should be aware of:

1. A tag is now required in AndroidManifest.xml.
2. NativeAppInstallAd and NativeContentAd APIs are deprecated in favor of UnifiedNativeAd.

Required AndroidManifest.xml changes

Starting in version 17.0.0, if you are an AdMob publisher you are now required to add your AdMob app ID in your AndroidManifest.xml file. Once you find your AdMob app ID in the AdMob UI, add it to your manifest adding the following tag:

<manifest>
    <application>
        <!-- TODO: Replace with your real AdMob app ID -->
        <meta-data
            android:name="com.google.android.gms.ads.APPLICATION_ID"
            android:value="ca-app-pub-################/##########"/>
    </application>
</manifest>

Failure to add this tag will result in the app crashing at app launch with a message starting with "The Google Mobile Ads SDK was initialized incorrectly."

What if I'm using Google Ad Manager instead of AdMob?

Publishers using Google Ad Manager will need to declare themselves as an Ad Manager app with a different tag to avoid the same crash:

<manifest>
    <application>
        <meta-data
            android:name="com.google.android.gms.ads.AD_MANAGER_APP"
            android:value="true"/>
    </application>
</manifest>

See the getting started guide (AdMob | Ad Manager) for additional details on how to make this change.

NativeAppInstallAd and NativeContentAd APIs are deprecated

This release also officially deprecates the NativeAppInstallAd and NativeContentAd APIs in favor of the previously released UnifiedNativeAd API. The UnifiedNativeAd APIs offer a consolidated way to render any type of native ad, reducing the number of lines of code needed to integrate native ads by up to 50%.

The following example shows how to load both app install and content ads using the new unified API:

AdLoader adLoader = new AdLoader.Builder(context, "ca-app-pub-3940256099942544/2247696110")
    .forUnifiedNativeAd(new UnifiedNativeAd.OnUnifiedNativeAdLoadedListener() {
        @Override
        public void onUnifiedNativeAdLoaded(UnifiedNativeAd unifiedNativeAd) {
            // Show the ad.
        }
    })
    .build();
adLoader.loadAd(new AdRequest.Builder().build());

Check out the native ads guide to get started with the unified API.

What else changed?

See the release notes for a full list of changes. If you have any questions about the release, please reach out to us on the Google Mobile Ads SDK developer forum.

 - Eric Leichtenschlag, Mobile Ads Developer Relations

Posted by Paul Bankhead, Director, Product Management, Google Play

We focus relentlessly on security and privacy on the Google Play Store to ensure Android users have a positive experience discovering and installing apps and games they love. We regularly update our Google Play Developer policies and today have introduced stronger controls and new policies to keep user data safe. Here are a few updates:

Upgrading for security and performance

As previously announced, as of November 1, 2018, Google Play will require updates to existing apps to target API level 26 (Android 8.0) or higher (this is already required for all new apps). Our goal is to ensure all apps on Google Play are built using the latest APIs that are optimized for security and performance.

Protecting Users

Our Google Play Developer policies are designed to provide a safe and secure experience for our users while also giving developers the tools they need to succeed. For example, we have always required developers to limit permission requests to only what is needed for their app to function and to be clear with users about what data they access.

As part of today's Google Play Developer Policy update, we're announcing changes related to SMS and Call Log permissions. Some Android apps ask for permission to access a user's phone (including call logs) and SMS data. Going forward, Google Play will limit which apps are allowed to ask for these permissions. Only an app that has been selected as a user's default app for making calls or text messages will be able to access call logs and SMS, respectively.

Please visit our Google Play Developer Policy Center and this Help Center article for detailed information on product alternatives to SMS and call logs permissions. For example, the SMS Retriever API enables you to perform SMS-based user verification and SMS Intent enables you to initiate an SMS or MMS text message to share content or invitations. We'll be working with our developer partners to give them appropriate time to adjust and update their apps, and will begin enforcement 90 days from this policy update.

In the coming months, we'll be rolling out additional controls and policies across our various products and platforms, and will continue to work with you, our developers, to help with the transition.

The trust of our users is critical and together we'll continue to build a safe and secure Android ecosystem.

Posted by Sami Tolvanen, Staff Software Engineer, Android Security

Android's security model is enforced by the Linux kernel, which makes it a tempting target for attackers. We have put a lot of effort into hardening the kernel in previous Android releases and in Android 9, we continued this work by focusing on compiler-based security mitigations against code reuse attacks.

Google's Pixel 3 will be the first Android device to ship with LLVM's forward-edge Control Flow Integrity (CFI) enforcement in the kernel, and we have made CFI support available in Android kernel versions 4.9 and 4.14. This post describes how kernel CFI works and provides solutions to the most common issues developers might run into when enabling the feature.

Protecting against code reuse attacks

A common method of exploiting the kernel is using a bug to overwrite a function pointer stored in memory, such as a stored callback pointer or a return address that had been pushed to the stack. This allows an attacker to execute arbitrary parts of the kernel code to complete their exploit, even if they cannot inject executable code of their own. This method of gaining code execution is particularly popular with the kernel because of the huge number of function pointers it uses, and the existing memory protections that make code injection more challenging.

CFI attempts to mitigate these attacks by adding additional checks to confirm that the kernel's control flow stays within a precomputed graph. This doesn't prevent an attacker from changing a function pointer if a bug provides write access to one, but it significantly restricts the valid call targets, which makes exploiting such a bug more difficult in practice.

Figure 1. In an Android device kernel, LLVM's CFI limits 55% of indirect calls to at most 5 possible targets and 80% to at most 20 targets.

Gaining full program visibility with Link Time Optimization (LTO)

In order to determine all valid call targets for each indirect branch, the compiler needs to see all of the kernel code at once. Traditionally, compilers work on a single compilation unit (source file) at a time and leave merging the object files to the linker. LLVM's solution to CFI is to require the use of LTO, where the compiler produces LLVM-specific bitcode for all C compilation units, and an LTO-aware linker uses the LLVM back-end to combine the bitcode and compile it into native code.

Figure 2. A simplified overview of how LTO works in the kernel. All LLVM bitcode is combined, optimized, and generated into native code at link time.

Linux has used the GNU toolchain for assembling, compiling, and linking the kernel for decades. While we continue to use the GNU assembler for stand-alone assembly code, LTO requires us to switch to LLVM's integrated assembler for inline assembly, and either GNU gold or LLVM's own lld as the linker. Switching to a relatively untested toolchain on a huge software project will lead to compatibility issues, which we have addressed in our arm64 LTO patch sets for kernel versions 4.9 and 4.14.

In addition to making CFI possible, LTO also produces faster code due to global optimizations. However, additional optimizations often result in a larger binary size, which may be undesirable on devices with very limited resources. Disabling LTO-specific optimizations, such as global inlining and loop unrolling, can reduce binary size by sacrificing some of the performance gains. When using GNU gold, the aforementioned optimizations can be disabled with the following additions to LDFLAGS:

LDFLAGS += -plugin-opt=-inline-threshold=0 \
           -plugin-opt=-unroll-threshold=0

Note that flags to disable individual optimizations are not part of the stable LLVM interface and may change in future compiler versions.

Implementing CFI in the Linux kernel

LLVM's CFI implementation adds a check before each indirect branch to confirm that the target address points to a valid function with a correct signature. This prevents an indirect branch from jumping to an arbitrary code location and even limits the functions that can be called. As C compilers do not enforce similar restrictions on indirect branches, there were several CFI violations due to function type declaration mismatches even in the core kernel that we have addressed in our CFI patch sets for kernels 4.9 and 4.14.

Kernel modules add another complication to CFI, as they are loaded at runtime and can be compiled independently from the rest of the kernel. In order to support loadable modules, we have implemented LLVM's cross-DSO CFI support in the kernel, including a CFI shadow that speeds up cross-module look-ups. When compiled with cross-DSO support, each kernel module contains information about valid local branch targets, and the kernel looks up information from the correct module based on the target address and the modules' memory layout.

Figure 3. An example of a cross-DSO CFI check injected into an arm64 kernel. Type information is passed in X0 and the target address to validate in X1.

CFI checks naturally add some overhead to indirect branches, but due to more aggressive optimizations, our tests show that the impact is minimal, and overall system performance even improved 1-2% in many cases.

Enabling kernel CFI for an Android device

CFI for arm64 requires clang version >= 5.0 and binutils >= 2.27. The kernel build system also assumes that the LLVMgold.so plug-in is available in LD_LIBRARY_PATH. Pre-built toolchain binaries for clang and binutils are available in AOSP, but upstream binaries can also be used.

The following kernel configuration options are needed to enable kernel CFI:

CONFIG_LTO_CLANG=y
CONFIG_CFI_CLANG=y

Using CONFIG_CFI_PERMISSIVE=y may also prove helpful when debugging a CFI violation or during device bring-up. This option turns a violation into a warning instead of a kernel panic.

As mentioned in the previous section, the most common issue we ran into when enabling CFI on Pixel 3 were benign violations caused by function pointer type mismatches. When the kernel runs into such a violation, it prints out a runtime warning that contains the call stack at the time of the failure, and the call target that failed the CFI check. Changing the code to use a correct function pointer type fixes the issue. While we have fixed all known indirect branch type mismatches in the Android kernel, similar problems may be still found in device specific drivers, for example.

CFI failure (target: [<fffffff3e83d4d80>] my_target_function+0x0/0xd80):
------------[ cut here ]------------
kernel BUG at kernel/cfi.c:32!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
…
Call trace:
…
[<ffffff8752d00084>] handle_cfi_failure+0x20/0x28
[<ffffff8752d00268>] my_buggy_function+0x0/0x10
…

Figure 4. An example of a kernel panic caused by a CFI failure.

Another potential pitfall are address space conflicts, but this should be less common in driver code. LLVM's CFI checks only understand kernel virtual addresses and any code that runs at another exception level or makes an indirect call to a physical address will result in a CFI violation. These types of failures can be addressed by disabling CFI for a single function using the __nocfi attribute, or even disabling CFI for entire code files using the $(DISABLE_CFI) compiler flag in the Makefile.

static int __nocfi address_space_conflict()
{
      void (*fn)(void);
 …
/* branching to a physical address trips CFI w/o __nocfi */
 fn = (void *)__pa_symbol(function_name);
      cpu_install_idmap();
      fn();
      cpu_uninstall_idmap();
 …
}

Figure 5. An example of fixing a CFI failure caused by an address space conflict.

Finally, like many hardening features, CFI can also be tripped by memory corruption errors that might otherwise result in random kernel crashes at a later time. These may be more difficult to debug, but memory debugging tools such as KASAN can help here.

Conclusion

We have implemented support for LLVM's CFI in Android kernels 4.9 and 4.14. Google's Pixel 3 will be the first Android device to ship with these protections, and we have made the feature available to all device vendors through the Android common kernel. If you are shipping a new arm64 device running Android 9, we strongly recommend enabling kernel CFI to help protect against kernel vulnerabilities.

LLVM's CFI protects indirect branches against attackers who manage to gain access to a function pointer stored in kernel memory. This makes a common method of exploiting the kernel more difficult. Our future work involves also protecting function return addresses from similar attacks using LLVM's Shadow Call Stack, which will be available in an upcoming compiler release.

Posted by Don Turner, Developer Advocate, Android Audio Framework

This week we released the first production-ready version of Oboe - a C++ library for building real-time audio apps. Oboe provides the lowest possible audio latency across the widest range of Android devices, as well as several other benefits.

Single API

Oboe takes advantage of the improved performance and features of AAudio on Oreo MR1 (API 27+) whilst maintaining backward compatibility (using OpenSL ES) on API 16+. It's kind of like AndroidX for native audio.

Less code to write and maintain

Using Oboe you can create an audio stream in just 3 lines of code (vs 50+ lines in OpenSL ES):

AudioStreamBuilder builder;
AudioStream *stream = nullptr;
Result result = builder.openStream(&stream);

Other benefits

• Convenient C++ API (uses the C++11 standard)
• Fast release process: supplied as a source library, bug fixes can be rolled out in days, quite a bit faster than the Android platform release cycle
• Less guesswork: Provides workarounds for known audio bugs and has sensible default behaviour for stream properties, such as sample rate and audio data formats
• Open source and maintained by Google engineers (although we welcome outside contributions)

Getting started

Take a look at the short video introduction:

Check out the documentation, code samples and API reference. There's even a codelab which shows you how to build a rhythm-based game.

If you have any issues, please file them here, we'd love to hear how you get on.

In less than a month, we'll be kicking off Android Dev Summit 2018, broadcasting live from the Computer History Museum in Mountain View, CA on November 7 and 8. We'll have two days of deep technical sessions from the Android engineering team, with over 30 sessions livestreamed. The first wave of sessions were just posted to the website: check them out and start planning.

The summit kicks off on November 7 at 10AM PST with the keynote, where you'll hear directly from Dave Burke and others on the present and future of Android development. From there, we'll dive into two tracks (and two days!) of deep technical content from the Google engineering team, on topics such as Android Pie, Android Studio, Kotlin, Android Jetpack, Google Play and more. We'll also have demos and office hours for those attending in person; more on that in the coming weeks!

We received a ton of interest from developers looking to attend in person; if you were one of those who expressed interest but didn't receive a ticket, we've already reached out to you and shared this news, but we want to apologize again that we weren't able to find you a spot. Rest assured, though, that we're still doing all that we can to free up more tickets, and we'll be reaching out to folks we're able to accommodate in the lead-up to the show. And if you did receive a ticket but your plans have changed and you're no longer able to attend, please let us know by sending an email to android-dev-summit@google.com, and we'll free up your spot for others on the waitlist.

If you can't join in person, you can always join us online: we'll be livestreaming all of the sessions on the Android Dev Summit website and making them available on YouTube throughout the conference to watch at your own pace. Plus, we'll be sharing updates directly from the Computer History Museum to our social channels, so be sure to follow along!

Posted by Luiz Gustavo Martins, Partner Developer Advocate, Partner DevRel

This is the third in a series of blog posts in which outline strategies and guidance in Android with regard to power.

Over the years, executing background tasks on Android has evolved. To write modern apps, it's important to learn how to run your background tasks in modern fashion.

When is an app in the background?

Before understanding what background execution is, we need to have a clear view of when Android understands an app to be in the foreground. An app is considered to be in the foreground if any of the following is true:

• The app has a visible activity, whether the activity is started or paused.
• The app has a foreground service.
• Another foreground app is connected to the app, either by binding to one of its services, or using one of its content providers. For example, an app is in the foreground if another app or the system binds to its:
  • IME
  • Wallpaper service
  • Notification listener
  • Voice or text service
  • Music app when streaming music to your car. (Android Auto-specific case)

If none of those conditions is true, the app is considered to be in the background.

Background execution changes

Running tasks in the background consumes a device's limited resources, like RAM and battery. This might result in a bad user experience. For example, background tasks may degrade the battery life of the device or the user may experience poor device performance at times such as watching a video, playing a game, using the camera.

To improve battery life and give a better user experience, Android has evolved over several releases to establish limits on background execution. These limits include:

• Doze and App Standby, which restricts app behavior when the screen is off, and the device is idle and not charging.
• Background Location restrictions, limits how frequently background apps can retrieve the user's current location.
• Background Service Limits, that restrict background services from being run and consuming CPU/network in a hidden/non-visible way.
• Most recently, App Standby Buckets that can limit the device resources available to apps that aren't used by users, and App Restrictions where the system will prompt the user to restrict the app's access to system resources in the background if the app exhibits bad behaviors, and several Battery Saver improvements.

Use cases and solutions

Deciding which tools to use to implement background execution requires the developer to have a clear understanding of what they want to accomplish, and under which restrictions. This flowchart can help you make a decision:

• WorkManager is the recommended solution for background execution, taking into account all OS background execution limits. If you need to guarantee that a task will run even if it is deferred, you should use WorkManager. This API allows you to schedule jobs (one-off or repeating) and chain and combine jobs. You can also apply execution constraints to them such as triggering when the device is idle or charging, or executing when a content provider changes.

  One example is if you need to compress logs to upload them to your server. To do this you can create two work requests:

  • First: compress the file. On this step you may add the constraint that the device should be charging.
  • Second: upload it to the server. For this request you should add a network connectivity constraint so that the work only gets triggered when you have a valid connection.

  After enqueuing both tasks, WorkManager will take care of executing them when your app has access to the resources you need.

  Another nice feature of WorkManager is that it respects power-management features, so that if a job is scheduled to run at a defined time and the device is in Doze at that time, WorkManager will try to run the task during a maintenance window if the constraints are met or after Doze is lifted.

• If a long-running task is to be scheduled in response to an external event like syncing for new online content, use Firebase Cloud Messaging to notify your app and then create a work request with WorkManager to sync the content. You can learn more about this in "Notifying your users with FCM".
• If the app needs to complete a user-initiated task without deferring even if the user leaves the app or turns off the screen, such as in the case of music/video playback or navigation, you should use a Foreground service. (The next blog post in this series dives deeper into this use case.)

• If you need to run a task at an exact time that triggers actions, involves user interactions, and cannot be deferred, use AlarmManager (more specifically the method setExactAndAllowWhileIdle). Examples of time alarms include:
  • a reminder to take medicine
  • a notification that a TV show is about to start.

  When the alarm is triggered, you have very few seconds to finish the work and your app may not have access to the network (for example during Doze or due to App Standby buckets). If you really need network or to do a long task, use WorkManager. Every time a wakeup alarm is triggered, the device comes out of low-power mode and holds a partial wake lock which can significantly impact the battery life over time. This can be monitored via excessive wakeups stats highlighted on Android Vitals, provided via Google Play Console.

In Summary:

Use background execution judiciously so that you can build cool apps that delight users while saving their battery. If you need more information on executing background tasks on Android, there's great content at the Android developer site.

Note: WorkManager is still in public preview. If you need an alternative solution right now, you should use JobScheduler, although it has limitations that don't apply to WorkManager. JobScheduler is part of the Android Framework, and only available for Android API 21 and above; WorkManager works on API 14 and above.

Acknowledgements: This series of blog posts is produced in collaboration between the Android Framework and DevRel teams

Posted by Nagendra Modadugu and Bill Richardson, Google Device Security Group

At the Made by Google event last week, we talked about the combination of AI + Software + Hardware to help organize your information. To better protect that information at a hardware level, our new Pixel 3 and Pixel 3 XL devices include a Titan M chip.We briefly introduced Titan M and some of its benefits on our Keyword Blog, and with this post we dive into some of its technical details.

Titan M is a second-generation, low-power security module designed and manufactured by Google, and is a part of the Titan family. As described in the Keyword Blog post, Titan M performs several security sensitive functions, including:

• Storing and enforcing the locks and rollback counters used by Android Verified Boot.
• Securely storing secrets and rate-limiting invalid attempts at retrieving them using the Weaver API.
• Providing backing for the Android Strongbox Keymaster module, including Trusted User Presence and Protected Confirmation. Titan M has direct electrical connections to the Pixel's side buttons, so a remote attacker can't fake button presses. These features are available to third-party apps, such as FIDO U2F Authentication.
• Enforcing factory-reset policies, so that lost or stolen phones can only be restored to operation by the authorized owner.
• Ensuring that even Google can't unlock a phone or install firmware updates without the owner's cooperation with Insider Attack Resistance.

Including Titan M in Pixel 3 devices substantially reduces the attack surface. Because Titan M is a separate chip, the physical isolation mitigates against entire classes of hardware-level exploits such as Rowhammer, Spectre, and Meltdown. Titan M's processor, caches, memory, and persistent storage are not shared with the rest of the phone's system, so side channel attacks like these—which rely on subtle, unplanned interactions between internal circuits of a single component—are nearly impossible. In addition to its physical isolation, the Titan M chip contains many defenses to protect against external attacks.

But Titan M is not just a hardened security microcontroller, but rather a full-lifecycle approach to security with Pixel devices in mind. Titan M's security takes into consideration all the features visible to Android down to the lowest level physical and electrical circuit design and extends beyond each physical device to our supply chain and manufacturing processes. At the physical level, we incorporated essential features optimized for the mobile experience: low power usage, low-latency, hardware crypto acceleration, tamper detection, and secure, timely firmware updates. We improved and invested in the supply chain for Titan M by creating a custom provisioning process, which provides us with transparency and control starting from the earliest silicon stages.

Finally, in the interest of transparency, the Titan M firmware source code will be publicly available soon. While Google holds the root keys necessary to sign Titan M firmware, it will be possible to reproduce binary builds based on the public source for the purpose of binary transparency.

A closer look at Titan M

Titan (left) and Titan M (right)

Titan M's CPU is an ARM Cortex-M3 microprocessor specially hardened against side-channel attacks and augmented with defensive features to detect and respond to abnormal conditions. The Titan M CPU core also exposes several control registers, which can be used to taper access to chip configuration settings and peripherals. Once powered on, Titan M verifies the signature of its flash-based firmware using a public key built into the chip's silicon. If the signature is valid, the flash is locked so it can't be modified, and then the firmware begins executing.

Titan M also features several hardware accelerators: AES, SHA, and a programmable big number coprocessor for public key algorithms. These accelerators are flexible and can either be initialized with keys provided by firmware or with chip-specific and hardware-bound keys generated by the Key Manager module. Chip-specific keys are generated internally based on entropy derived from the True Random Number Generator (TRNG), and thus such keys are never externally available outside the chip over its entire lifetime.

While implementing Titan M firmware, we had to take many system constraints into consideration. For example, packing as many security features into Titan M's 64 Kbytes of RAM required all firmware to execute exclusively off the stack. And to reduce flash-wear, RAM contents can be preserved even during low-power mode when most hardware modules are turned off.

The diagram below provides a high-level view of the chip components described here.

Better security through transparency and innovation

At the heart of our implementation of Titan M are two broader trends: transparency and building a platform for future innovation.

Transparency around every step of the design process — from logic gates to boot code to the applications — gives us confidence in the defenses we're providing for our users. We know what's inside, how it got there, how it works, and who can make changes.

Custom hardware allows us to provide new features, capabilities, and performance not readily available in off-the-shelf components. These changes allow higher assurance use cases like two-factor authentication, medical device control, P2P payments, and others that we will help develop down the road.

As more of our lives are bound up in our phones, keeping those phones secure and trustworthy is increasingly important. Google takes that responsibility seriously. Titan M is just the latest step in our continuing efforts to improve the privacy and security of all our users.

Posted by Matt Henderson, Product Manager, Google Play

Today we are kicking off Playtime, our annual global event series, hosting over 800 attendees in Berlin and San Francisco to share insights from experts around the world and the latest updates on our products. This will be followed by events in Sao Paulo, Singapore, Taipei, Seoul, and Tokyo.

At Google Play, we continue to invest in tools that make it easier for you to develop and distribute your apps to a global audience. Below are some of the exciting updates we are announcing today:

Building smaller apps

The Android App Bundle is Android's new publishing format, with which you can more easily deliver a great experience in a smaller app size. Smaller apps have higher conversion rates and our user research shows that app size is a leading motivator in driving uninstalls. With the Android App Bundle's modularization, you can also deliver features on demand, instead of at install time, further reducing the size of your app.

Thousands of app bundles are already in production, with an average size reduction of 35%. Today, we are announcing updates that offer additional reasons for you to switch to the bundle.

• More size savings: app bundles will now be on average 8% smaller on download and 16% smaller on device on M+ devices with no additional developer work. These new savings come from supporting uncompressed native libraries, which eliminates the need to store multiple copies on the device.
• Easier to switch: you can now build app bundles in the Android Studio 3.2 stable release and in Unity 2018.3 beta.
• Improved support for large apps: you can now upload large app bundles with installed APK sizes of up to 500MB without needing to use expansion files. This feature is in early access and we will roll it out to all developers in the future.

To learn more about the Android App Bundle, dynamic features, and all the benefits you receive from building a smaller, modular app, read our Medium post.

Building a unified instant experience

We've been listening to your feedback to make it easier to build instant apps, and we recently increased the size limit to 10MB to enable TRY NOW on the Play Store and removed the URL requirement. For game developers, we've partnered with Unity on a Google Play Instant plug-in and have built instant directly into the new Cocos Creator.

We’re now using the Android App Bundle to solve one of the primary pain points of building instant apps. Previously, you needed to publish both an instant app and an installable app. With Android Studio 3.2, you could publish instant-enabled bundles but you were still required to publish a primary app bundle.

Now, you don't have to maintain separate code. With the Android Studio 3.3 beta release, a developer can publish a single app bundle and classify it or a particular module to be instant enabled. The unified app bundle is the future of instant app experiences and we hope you will try it out.

Extending instant trials

Google Play Instant is now available for premium titles and pre-registration campaigns, so people can try your game before it launches and generate additional buzz. New apps and games join Google Play Instant every day, and we're excited to welcome Umiro, by Devolver Digital, and Looney Tunes World of Mayhem, by Scopely, as some of the first to take advantage of these new features.

Reducing crash rates and improving quality

The Play Console offers two tools to help you monitor performance and improve the quality of your apps. The pre-launch report runs your apps on real devices situated in the Firebase Test Lab and generates useful metadata to help you identify and fix issues before pushing your apps to production. Android vitals helps you track the performance and quality of your app on users' devices in the real world.

Now, we're linking them together to provide more actionable insights. Whenever a real-world crash in Android vitals is also seen during a pre-launch report execution, you'll get all the extra metadata from the pre-launch report available to you in the Android vitals dashboard so you can debug more effectively. This is also linked in both directions, so that if a crash occurs in pre-launch reports that is already happening in the real world, you'll be able to see the current impact in Android vitals which will help you better prioritize the issues highlighted by pre-launch reports.

Optimizing your app and business

We've made several updates to make it easier to manage your app and business with Play.

• Tools for retaining subscribers: at I/O we introduced the cancellation survey, where you can get insights into why your subscribers are canceling. Now we're testing the ability for users to temporarily pause their subscriptions instead of outright canceling, and giving you the ability to deliver promotions to win back canceled subscribers.
• More flexible subscription pricing: you can now change the price of an existing subscription without needing to create a new SKU in Play Billing Library version 1.2. You can also offer a plan change and make the change effective at the existing renewal date.
• More powerful metrics: we've added new tools in the Play Console to help you evaluate your core metrics. Additions include cumulative data, 30-day rolling average metrics, and roll-ups for different time periods to better match the cadence of your business. You can also download any configured reports as a CSV file.
• Easier app updates: you can now prompt users to update without leaving your app with a new API called In-App Updates. Developers can either show a full screen experience that takes the user from download to restart, or help the user download and install in the background with graceful state monitoring. This program is currently in early access and will roll out in the next few months.

A new way to learn about Play

We're equally excited to launch the Academy for App Success with new interactive courses to help developers get the most out of the Play Console, understand Play policies, and utilize best practices to improve quality and increase business performance. This free new program allows you to track your learning progress with quizzes and achievements to demonstrate your expertise. Available in English today, new content and translated courses will be added soon.

Posted by Janis Danisevskis, Information Security Engineer, Android Security

In Android Pie, we introduced Android Protected Confirmation, the first major mobile OS API that leverages a hardware protected user interface (Trusted UI) to perform critical transactions completely outside the main mobile operating system. This Trusted UI protects the choices you make from fraudulent apps or a compromised operating system. When an app invokes Protected Confirmation, control is passed to the Trusted UI, where transaction data is displayed and user confirmation of that data's correctness is obtained.

Once confirmed, your intention is cryptographically authenticated and unforgeable when conveyed to the relying party, for example, your bank. Protected Confirmation increases the bank's confidence that it acts on your behalf, providing a higher level of protection for the transaction.

Protected Confirmation also adds additional security relative to other forms of secondary authentication, such as a One Time Password or Transaction Authentication Number. These mechanisms can be frustrating for mobile users and also fail to protect against a compromised device that can corrupt transaction data or intercept one-time confirmation text messages.

Once the user approves a transaction, Protected Confirmation digitally signs the confirmation message. Because the signing key never leaves the Trusted UI's hardware sandbox, neither app malware nor a compromised operating system can fool the user into authorizing anything. Protected Confirmation signing keys are created using Android's standard AndroidKeyStore API. Before it can start using Android Protected Confirmation for end-to-end secure transactions, the app must enroll the public KeyStore key and its Keystore Attestation certificate with the remote relying party. The attestation certificate certifies that the key can only be used to sign Protected Confirmations.

There are many possible use cases for Android Protected Confirmation. At Google I/O 2018, the What's new in Android security session showcased partners planning to leverage Android Protected Confirmation in a variety of ways, including Royal Bank of Canada person to person money transfers; Duo Security, Nok Nok Labs, and ProxToMe for user authentication; and Insulet Corporation and Bigfoot Biomedical, for medical device control.

Insulet, a global leading manufacturer of tubeless patch insulin pumps, has demonstrated how they can modify their FDA cleared Omnipod DASH TM Insulin management system in a test environment to leverage Protected Confirmation to confirm the amount of insulin to be injected. This technology holds the promise for improved quality of life and reduced cost by enabling a person with diabetes to leverage their convenient, familiar, and secure smartphone for control rather than having to rely on a secondary, obtrusive, and expensive remote control device. (Note: The Omnipod DASH System is not cleared for use with Pixel 3 mobile device or Protected Confirmation).

This work is fulfilling an important need in the industry. Since smartphones do not fit the mold of an FDA approved medical device, we've been working with FDA as part of DTMoSt, an industry-wide consortium, to define a standard for phones to safely control medical devices, such as insulin pumps. A technology like Protected Confirmation plays an important role in gaining higher assurance of user intent and medical safety.

To integrate Protected Confirmation into your app, check out the Android Protected Confirmation training article. Android Protected Confirmation is an optional feature in Android Pie. Because it has low-level hardware dependencies, Protected Confirmation may not be supported by all devices running Android Pie. Google Pixel 3 and 3XL devices are the first to support Protected Confirmation, and we are working closely with other manufacturers to adopt this market-leading security innovation on more devices.

Posted by James Bender, Product Manager, Google Play

In June we started adding security metadata to all apps and app updates to help verify product authenticity from Google Play. We're doing this is to help developers reach a wider audience, particularly in countries where peer-to-peer app sharing is common because of costly data plans and limited connectivity.

Now, when a user shares an app via Play-approved partner peer-to-peer apps, Play will be able to determine shared app authenticity while a device is offline, add those shared apps to a user's Play Library, and manage app updates when the device comes back online. This will give users more confidence when using Play-approved peer-to-peer app beta partners, starting today with SHAREIt. Additional integrations from Files Go by Google and Xender are planned in the coming weeks. Please visit the Play Store to make sure you have the latest versions of these apps.

This also benefits you as a developer as it provides a Play-authorized offline distribution channel and, since the peer-to-peer shared app is added to your user's Play library, your app will now be eligible for app updates from Play.

No action is needed by developers or your users. This is an important step that improves the integrity of Google Play's mobile app ecosystem. Offline Play peer-to-peer sharing presents a new distribution opportunity for developers while helping more people keep their apps up to date.

Dan Lavelle, Head of Learning Operations, Google Play

Having a great idea for an app or game is just the beginning. At Google Play, it's our goal to provide you with the tools and skills to build successful mobile app and games businesses. Training continues to be among the top requested features from Android developers, and we've heard your feedback.

That's why we're launching a brand new, free e-learning platform to help you realize the full potential of your business on Google Play.

Introducing Google Play's Academy for App Success

Whether you're looking to grow your audience, understand performance metrics, or increase revenue, Play Academy is here to help you understand the best practices and Play Console features to succeed on Google Play. We built Play Academy to fit into your busy schedule. Learn from your home or office computer, or take courses on-the-go with your mobile device.

Key features of Play Academy

Learning paths

Choose from 10 collections of bite-sized courses organized around features and best practices, including; Test your app before release, Evaluate your app's technical performance, and Monetize your app.

Interactive lessons

Learn through a rich multimedia and interactive e-learning experience.

Assessments

Test your new knowledge of key Play Console features and mobile app best practices.

Achievements

Get recognition for your new skills. Wear your achievement badges with pride on your Play Academy profile.

Start learning today

It's easy to get started with free e-learning content from Google Play. Head over to g.co/play/academy to sign up and start your developer journey. Also, make sure you keep an eye on upcoming Play Academy news - we'll regularly update our courses to keep pace with the newest features and programs so that you can stay up-to-date with the latest insights you'll need to grow your app or game business.

Posted by Ritesh Nayak M, Product Manager

Three years ago, we created Nearby Notifications as a way for Android users to discover apps and content based on what is nearby. Our goal was to bring relevant and engaging content to users - to provide useful information proactively. Developers have leveraged this technology to let users know about free wifi nearby, provide guides while in a museum, and list transit schedules at bus stops.

We've learned a lot building and launching Nearby Notifications. However, earlier this year, we noticed a significant increase in locally irrelevant and spammy notifications that were leading to a poor user experience. While filtering and tuning can help, in the end, we have a very high bar for the quality of content that we deliver to users, especially content that is delivered through notifications. Ultimately, we have determined these notifications did not meet that bar. As a result, we have decided to discontinue support for Nearby Notifications. We will stop serving Nearby Notifications on December 6th, 2018.

What does it mean for Android users

Android users will stop receiving Nearby Notifications.

What does it mean for developers

On December 6th we will stop delivering both Eddystone and Physical Web beacon notifications. You will still continue to have access to the beacon dashboard and can deliver proximity based experiences similar to Nearby Notifications via your own apps using our Proximity Beacons API.

We have two related APIs, Nearby Messages and Connections, that are available for developers to build device-to-device connectivity experiences, and also have Fast Pair, for device discovery and pairing. We will continue to invest in these APIs and support products using these technologies.

We sincerely appreciate the efforts of the Android developer community in supporting and evolving Nearby technology and the feedback that has helped us improve. We look forward to continuing to deliver engaging proximity experiences to users and seeing what developers create within their apps with our APIs.

Posted by Matt Pearring, Associate Product Marketing Manager, Developer Marketing

In just a week, we'll be kicking off Android Dev Summit 2018, broadcasting live from the Computer History Museum in Mountain View, CA on November 7 and 8. We'll have two days of deep technical sessions from the Android engineering team, with over 30 sessions livestreamed. The app just went live; download it on Google Play and start planning.

With the app you can explore the conference schedule with details on keynotes, sessions, and lightning talks. You can also plan your summit experience by saving events to your personalized schedule. This year's app is also an Instant app, so you can try it out first before installing it!

If you can't join in person, you can always join us online — we'll be livestreaming all of the sessions on the Android Dev Summit website or app and making them available on YouTube throughout the conference so you can watch at your own pace. Plus, we will share updates directly from the Computer History Museum to our social channels, so be sure to follow along!

Posted by Leo Sei, Product Manager on Android Studio and R8

Android developers know that APK size is an important factor in user engagement. Code shrinking helps reduce the size of your APK by getting rid of unused code and resources as well as making your actual code take less space (also known as minification or obfuscation).

That's why we're investing in improving code shrinking to make it faster and more efficient. We're excited to announce that the next generation code shrinker, R8, is available for preview as part of Android Studio 3.3 beta.

R8 does all of shrinking, desugaring and dexing in one step. When comparing to the current code shrinking solution, Proguard, R8 shrinks the code faster while improving the output size.

The following data comes from benchmark on the Santa Tracker app, you can find the project with benchmark details on this GitHub repository.

How to try it

R8 is available with Android Studio 3.3 beta and works with Proguard rules. To try it, set the following in your project's gradle.properties file:

android.enableR8=true

For the more adventurous, R8 also has full mode that is not directly compatible with Proguard. In order to try that out you can additionally set the following in your gradle.properties file:

android.enableR8.fullMode=true

This turns on more optimizations, that can further reduce app size. However, you might need a few extra keep rules to make it work.

We have tested R8 correctness and performances on a number of apps and the results are promising so we plan to switch R8 as the default shrinker in Android studio soon.

Please give R8 a try and we would love to hear your feedback. You can file a bug report using this link.

Today, at the Computer History Museum in Mountain View, CA, we kicked off the Android Dev Summit, taking a look back at the last 10 years of Android and then jumping into some important new features for Android developers. Here's a look at some of the things we shared!

Unfolding Android into new experiences

As early as Android 1.6, Android and our partners have contemplated different screen sizes and densities, enabling the platform to power a broad category of form factors and new experiences like Android TV, Android Auto, Wear OS and even Android apps on Chromebooks. Phone screens are an area where Android partners set the bar, introducing "phablets" when phone screens were small. Fast forward to today, when a phablet is... just a phone, a standard size users have come to love.

Now we see a Android device makers creating a new category: Foldables. Taking advantage of new flexible display technology, the screen can literally bend and fold.

There are two variants broadly speaking: two-screen devices and one-screen devices. When folded, foldables look like phones, fitting in your pocket or purse. When unfolded, their defining feature is what we call screen continuity. For example, start a video with the folded smaller screen - and later you can sit down and unfold the device to get a larger tablet-sized screen for a beautiful, immersive experience. As you unfold, the app seamlessly transfers to the bigger screen without missing a beat. We're optimizing Android for this new form factor. And, making changes to help developers everywhere take advantage of the possibilities this creates for amazing new experiences, new ways to engage and delight your users. Tune in to the Foldables session at Dev Summit this week to learn more. Expect to see Foldables coming from several Android manufacturers, including one Samsung previewed today and plans to offer next year.

Kotlin: updates to the fastest growing language

We made Kotlin a first class language on Android in 2017. This month we had over 118,000 new projects using Kotlin started in Android Studio - from those users who opt in to share metrics. That's a 10X increase from last year. It's become the fastest growing language in terms of growth of number of contributors on GitHub, and voted the #2 most loved language on Stack Overflow. In our surveys, the more developers use Kotlin, the higher their satisfaction.

Last week, JetBrains released the latest version of Kotlin, 1.3, which brings new language features, APIs, bug fixes, and performance improvements:

• Inline classes allow you to create a type which doesn't allocate unless boxed. For the constrained devices that Android apps target, avoiding allocation while retaining type-safety is a big advantage.
• Unsigned numbers are now part of the Kotlin standard library including UInt, UByte, and ULong. These new types are built using inline classes.
• Multiplatform code previously written for Android or the JVM can now also target Javascript or native. This unlocks the possibility of reusing parts of your codebase on even more platforms.
• Coroutines support is now stable. The language and library support combine to simplify how you interact with asynchronous operations and perform concurrent work–things that are essential to every Android app.

All of these new features of Kotlin 1.3 will be integrated into the Kotlin-specific APIs that we provide–a majority of which are through KTX extensions as part of Jetpack.

Android Jetpack: Navigation, Work Manager, and Slices

At Google I/O we announced Jetpack, the next generation of tools and Android APIs to accelerate Android application development. Jetpack builds on the foundations laid out by Support Library and Architecture. Already, 80% of top 1,000 apps and games are using one of the new Jetpack libraries in production.

This summer we moved AndroidX - Jetpack's evolution of the original Android Support Library - to public AOSP. This means you can see features and bug fixes implemented in real-time, and contribute to any of the AndroidX libraries. You can learn more about contributing here.

We've been working to get as much feedback and refinement as possible on two new Architecture Component libraries: Navigation and Work Manager, and we plan to move both to Beta this month. The Navigation Architecture Component offers a simplified way to implement Android's navigation principles in your application, using a single Activity. Plus, the new Navigation Editor in Android Studio creates and edits your navigation architecture. This eliminates navigation boilerplate, gives you atomic navigation operations, easier animated transitions and more. WorkManager makes it easy to perform background tasks in the most efficient manner, choosing the most appropriate solution based on the application state and device API level.

Navigation Editor

We're also excited to see Android Slices move to public Search experiments! At I/O this year we introduced Slices, a new way to bring users to your app. Slices are like a mini snippet of your app, where you can surface content and actions. You can book a flight, play a video, or call a ride. Slices is another example where we want to be open very early, but we want to take the time to get it right. We're moving into public EAP this month with Doist, Kayak and others. We'll run experiments surfacing Slices in Google search results. To learn more, there's also a session today at Dev Summit with more info and best practices.

Android Studio: focusing on productivity, build speed, quality and fundamentals

Android Studio is our official IDE for Android development. We asked where do you spend the most time? When we gather data from Android Studio's opted-in users we see that build time are getting faster with every release, sometimes as fast as 20%, but we also see build time getting slower and slower over time. So, how can both things be true? We've been digging in hard to understand.

It turns out build is a pretty complicated ecosystem. Developer choices makes a huge difference. Our developers are using a very broad (and growing) combination of OSes, custom plug-ins, annotation processors, languages. All of these can significantly affect times. In one case, a plugin some users like to add was silently slowing build speeds by up to 45%. Learning this, we realized we need build profiling and analysis tools so you can easily understand what's slowing your build down. We're also investing more in our own plugins to accelerate performance to make sure we continue to improve the performance of core build.

Android Studio 3.3 launches beta 3 today. In coming releases expect to see a strong focus on quality and fundamentals: reducing the number of crashes and hangs, optimizing memory usage, and fixing user-impacting bugs. We also announced today that we're making Android Studio an officially supported IDE on Chrome OS early next year; learn more here.

Android App Bundles and dynamic features

App sizes have grown dramatically, up 5x since 2012. But larger apps have downsides: lower install conversion rates, lower update rates, and higher uninstalls. This is why we built the Android App Bundle, the new publishing format that serves only the code and resources a user needs to run your app on their specific device; on average apps see 35% size savings compared to a universal APK. The app bundle also saves you time and effort with each release since you don't need to use incomplete solutions like multi-APK. Android Studio 3.2 brought full IDE support of app bundles, and there are now thousands of app bundles in production totaling billions of installs, including Google's apps like YouTube, Google Maps, Google Photos, and Google News.

The app bundle now supports uncompressed native libraries; with no additional developer work needed, the app bundle now makes apps using native libraries an average of 8% smaller to download and 16% smaller on disk on M+ devices.

Once you switch to the app bundle you can also start modularizing your app. With dynamic feature modules, you can load any app functionality on demand instead of at install time. You don't need to keep big features that are only used once, on every single device forever; dynamic features can be installed and uninstalled dynamically when your app requests them.

In-app Updates API

We've heard that you'd like more controls to ensure that users are running the latest and greatest version of your app. To address this, we're launching an In-app Updates API. We're testing the API with early access partners and will be launching it to all developers soon.

You'll have two options with this API; the first is a full-screen experience for critical updates when you expect the user to wait for the update to be applied immediately. The second option is a flexible update, which means the user can keep using the app while the update is downloaded. You can completely customize the update flow so it feels like part of your app.

Instant discovery

We're also making instant apps easier than ever to adopt. We recently made using web URLs optional, enabling you to take your existing play store deep link traffic and send users to your instant experience if it's available. Additionally, we've raised the instant app size limit to 10MB for the Try Now button on the Play Store and web banners to make it even easier to adopt.

In the Android Studio 3.3 beta, you can now build an instant-enabled app bundle. This means that you can now build and deploy both your Instant and installed experiences from a single Android Studio project, and include them in a single Android App Bundle. You only have to upload just ONE artifact for both instant and installed app.

As developers, your feedback has been critical in shaping these investment areas; you are part of how we work, from early ideas, to EAPs and canaries, Beta, and iterating after launch. We hope you join us for the next two days whether you're watching the 30+ sessions on the livestream, joining social, or with us in-person in Mountain View. From the team, a sincere thank you for all your thoughtful feedback and contributions. We hope you enjoy Android Dev Summit.

Posted by Leo Sei, Product Manager on Android

As you may have heard from the Android Dev Summit, we announced that we're expanding support in Android to include Foldables, in preparation for upcoming devices from hardware partners like Samsung.

Here are a set of recommendations and information to make sure your application provides a great user experience on this new form factor (you can also check out the Android Dev Summit dedicated session here)

1. Screen continuity

On this new form factor, your application could be transitioned from one screen to another automatically (eg. when folding / unfolding a foldable phone).

During this transition, your app will receive a configuration change for the new layout (and possibly density in some cases).

To provide a great user experience when changing from one screen to the other, you want to make sure your app properly support runtime configuration change.

How to test: Emulators for various devices should become available soon (eg., Samsung will publish a folding / unfolding emulator apk later in Q4 which should work on Samsung Galaxy S4 tablets as well as the AOSP emulator in Android studio).

2. Multi-resume

Today, when an app is in multi-window but not focused, it is on the OnPause state.

While we provide recommendations on how to support multi-window, we noticed a significant number of apps are not handling the onPause state according to those recommendations (video paused or stopped, instant messages not displayed etc).

To help developers provide the best user experience on multi-window with minimal effort, we're allowing device manufacturers to keep all apps resumed when in multi-windows in P.

To opt-in to this behavior in Android P, add the following meta-data in your app manifest:

<meta-data android:name="android.allow_multiple_resumed_activities" android:value="true" />

Note: With the next Android version we're looking into how to optimize compatibility for this behavior.

How to test: There are no device at the moment with this behavior but device manufacturers are working to update existing devices to allow developers to test. Stay tuned for more details from device manufacturers.

3. Multi-display

Beginning with Android 8.0 (API level 26), the platform offers enhanced support for multiple displays. If an activity supports multi-window mode and is running on a device with multiple displays, users can move the activity from one display to another. When an app launches an activity, the app can specify which display the activity should run on. See here for the full documentation

How to test: You can try it out by using the "Developer options > Simulate secondary displays" option. Keep in mind that those simulated display do not process inputs.

Posted by Iliyan Malchev, Project Treble Architect

Last week at the 2018 Android Dev Summit, we demonstrated the benefits of Project Treble by showing the same Generic System Image (GSI) running on devices from different OEMs. We highlighted the availability of GSI for Android 9 Pie that app developers can use to develop and test their apps with Android 9 on any Treble-compliant device.

Launched with Android Oreo in 2017, Project Treble has enabled OEMs and silicon vendors to develop and deploy Android updates faster than what was previously possible. Since then, we've been working with device manufacturers to define Vendor Interfaces (VINTF) and draw a clear separation between vendor and framework code on Android devices.

Going forward, all devices launching with Android 9 Pie or later will be Treble-compliant and take full advantage of the Treble architecture to deliver faster upgrades. Thanks to Treble, we expect to see more devices from OEMs running Android 9 Pie at the end of 2018 as compared to the number of devices that were running Android Oreo at the end of 2017.

The GSI is built from the latest available AOSP source code, including the latest bug fixes contributed by OEMs. Device manufacturers already use GSI to validate the implementation of the vendor interface on their devices, and Android app developers can now harness the power of the GSI to test their apps across different devices. With GSI, you can test your apps on a pure AOSP version of the latest Android dessert, including the latest features and behavior changes, on any Treble-compliant device that's unlocked for flashing.

We're continuing to work on making GSI even more accessible and useful for app developers. For example, the GSI could enable early access to future Android platform builds that you can run on a Treble-compliant Android 9 device, so you could start app development and validation before the AOSP release.

If you are interested in trying GSI today, check out the documentation for full instructions on how to build GSI yourself and flash it to your Treble-compliant device.