Tag Archives: Android

Congratulations to the finalists of the Indie Games Showcase from Google Play

Posted by Patricia Correa, Director, Platforms & Ecosystems Developer Marketing

Google Play Indie Games Showcase Announcements gif

Back in March we opened submissions for the Indie Games Showcase, an international competition for games studios from Europe*, South Korea, and Japan who are constantly pushing the boundaries of storytelling, visual excellence, and creativity in mobile.

We were once again impressed by the diversity and creativity that the indie community is bringing to mobile, and we’re happy to announce the 20 finalists.

Check out the local websites to learn more about the finalists and the events.

European illustration with Eiffel Tower and Matryoshka dolls

Europe

Europe Finalists logos for Indie Games Showcase

AntVentor by LoopyMood (Ukraine)

CHUCHEL by Amanita Design (Czech Republic)

#DRIVE by Pixel Perfect Dude (Poland)

Fly THIS! By Northplay (Denmark)

Fobia by Tapteek (Russia)

G30 - A Memory Maze by Ivan Kovalov (Russia)

Gold Peaks by Afterburn (Poland)

Grayland by 1DER Entertainment (Slovakia)

Hexologic by MythicOwl (Poland)

Lucid Dream Adventure by Dali Games (Poland)

OCO by SPECTRUM48 (United Kingdom)

Ordia by Loju (United Kingdom)

Peep by Taw (Russia)

Photographs by EightyEight Games (United Kingdom)

Rest in Pieces by Itatake (Sweden)

Returner Zhero by Fantastic, yes (Denmark)

see/saw by Kamibox (Germany)

STAP by Overhead Game Studio (United Kingdom)

Tesla vs. Lovecraft by 10tons (Finland)

Tiny Room Stories: Town Mystery by Kiary games (Russia)

mt.Fuji and other Japanese emblems

Japan

Japan Finalists logos for Indie Games Showcase

ALTER EGO by 株式会社カラメルカラム

Infection - 感染 - by CanvasSoft

Jumpion - Make a two-step jump ! by Comgate

Lunch Time Fish by SoftFunk HULABREAKS

MeltLand by 個人

ReversEstory by 個人

キグルミキノコ Q-bit -第一章- by 個人

SumoRoll - Road to the Yokozuna by Studio Kingmo

Escape Game: The Little Prince by 株式会社 Jammsworks

Kamiori - カミオリ by TeamOrigami

Bear's Restaurant by 個人

クマムシさん惑星 ミクロの地球最強伝説 by Ars Edutainment

ゴリラ!ゴリラ!ゴリラ!by Gang Gorilla Games

Girl x Sun - Terasene - Tower defence & Novel game by SleepingMuseum

タシテケス by 個人

Destination: Dragons! by GAME GABURI

Cute cat's cake shop by 個人

Persephone by Momo-pi

Hamcorollin' by illuCalab.

Food Truck Pup: Cooking Chef by 合同会社ゲームスタート

Korean space needle and temple

South Korea

South Korea Finalists logos for Indie Games Showcase

다크타운 - 온라인 by 초콜릿소프트

Bad 2 Bad: Extinction by Dawinstone

셧더펑 : 슈팅액션 by Take Five Games

Cartoon Craft by Studio NAP

Catch Idle by HalftimeStudio

Hexagon Dungeon by Bleor Games

Hexonia by Togglegear

Mahjong - Magic Fantasy by Aquagamez

Maze Cube by IAMABOY

Road to Valor: World War II by Dreamotion Inc.

Onslot Car by Wondersquad

ROOMS: The Toymaker's Mansion by HandMade Game

Rhythm Star: Music Adventure by Anbsoft

7Days - Decide your story by Buff Studio

Seoul2033: Backer by Banjiha Games

Super Jelly Pop by STARMONSTER

UNLINK Daily Puzzle by Supershock

몬스터파크 온라인 by OVENCODE

WhamBam Warriors by DrukHigh

언노운 나이츠 by teamarex

We will welcome all finalists at events in London, Seoul, and Tokyo, where they will showcase their games to an audience of players, press and industry experts, for a chance to win the top prizes.

The events are open to the public, so if you would like to meet these games developers, try out their creations, and help choose the winners, sign up on the regional websites.

Congratulations to all finalists!

* The competition is open to developers from the following European countries and Israel: Austria, Belgium, Belarus, Czech Republic, Denmark, Finland, France, Germany, Italy, Netherlands, Norway, Poland, Romania, Russia, Slovakia, Spain, Sweden, Ukraine, and the United Kingdom (including Northern Ireland).

How useful did you find this blog post?

Wide Color Photos Are Coming to Android: Things You Need to Know to be Prepared

Posted by Peiyong Lin, Software Engineer

Android is now at the point where sRGB color gamut with 8 bits per color channel is not enough to take advantage of the display and camera technology. At Android we have been working to make wide color photography happen end-to-end, e.g. more bits and bigger gamuts. This means, eventually users will be able to capture the richness of the scenes, share a wide color pictures with friends and view wide color pictures on their phones. And now with Android Q, it's starting to get really close to reality: wide color photography is coming to Android. So, it's very important to applications to be wide color gamut ready. This article will show how you can test your application to see whether it's wide color gamut ready and wide color gamut capable, and the steps you need to take to be ready for wide color gamut photography.

But before we dive in, why wide color photography? Display panels and camera sensors on mobile are getting better and better every year. More and more newly released phones will be shipped with calibrated display panels, some are wide color gamut capable. Modern camera sensors are capable of capturing scenes with a wider range of color outside of sRGB and thus produce wide color gamut pictures. And when these two come together, it creates an end-to-end photography experience with more vibrant colors of the real world.

At a technical level, this means there will be pictures coming to your application with an ICC profile that is not sRGB but some other wider color gamut: Display P3, Adobe RGB, etc. For consumers, this means their photos will look more realistic.

orange sunset

Display P3

orange sunset

SRGB

Colorful umbrellas

Display P3

Colorful umbrellas

SRGB

Above are images of the Display P3 version and the SRGB version respectively of the same scene. If you are reading this article on a calibrated and wide color gamut capable display, you can notice the significant difference between these them.

Color Tests

There are two kinds of tests you can perform to know whether your application is prepared or not. One is what we call color correctness tests, the other is wide color tests.

Color Correctness test: Is your application wide color gamut ready?

A wide color gamut ready application implies the application manages color proactively. This means when given images, the application always checks the color space and does conversion based on its capability of showing wide color gamut, and thus even if the application can't handle wide color gamut it can still show the sRGB color gamut of the image correctly without color distortion.

Below is a color correct example of an image with Display P3 ICC profile.

large round balloons outside on floor in front of a concrete wall

However, if your application is not color correct, then typically your application will end up manipulating/displaying the image without converting the color space correctly, resulting in color distortion. For example you may get the below image, where the color is washed-out and everything looks distorted.

large round balloons outside on floor in front of a concrete wall

Wide Color test: Is your application wide color gamut capable?

A wide color gamut capable application implies when given wide color gamut images, it can show the colors outside of sRGB color space. Here's an image you can use to test whether your application is wide color gamut capable or not, if it is, then a red Android logo will show up. Note that you must run this test on a wide color gamut capable device, for example a Pixel 3 or Samsung Galaxy S10.

red Android droid figure

What you should do to prepare

To prepare for wide color gamut photography, your application must at least pass the wide color gamut ready test, we call it color correctness test. If your application passes the wide color gamut ready tests, that's awesome! But if it doesn't, here are the steps to make it wide color gamut ready.

The key thing to be prepared and future proof is that your application should never assume sRGB color space of the external images it gets. This means application must check the color space of the decoded images, and do the conversion when necessary. Failure to do so will result in color distortion and color profile being discarded somewhere in your pipeline.

Mandatory: Be Color Correct

You must be at least color correct. If your application doesn't adopt wide color gamut, you are very likely to just want to decode every image to sRGB color space. You can do that by either using BitmapFactory or ImageDecoder.

Using BitmapFactory

In API 26, we added inPreferredColorSpace in BitmapFactory.Option, which allows you to specify the target color space you want the decoded bitmap to have. Let's say you want to decode a file, then below is the snippet you are very likely to use in order to manage the color:

final BitmapFactory.Options options = new BitmapFactory.Options();
// Decode this file to sRGB color space.
options.inPreferredColorSpace = ColorSpace.get(Named.SRGB);
Bitmap bitmap = BitmapFactory.decodeFile(FILE_PATH, options);

Using ImageDecoder

In Android P (API level 28), we introduced ImageDecoder, a modernized approach for decoding images. If you upgrade your apk to API level 28 or beyond, we recommend you to use it instead of the BitmapFactory and BitmapFactory.Option APIs.

Below is a snippet to decode the image to an sRGB bitmap using ImageDecoder#decodeBitmap API.

ImageDecoder.Source source =
        ImageDecoder.createSource(FILE_PATH);
try {
    bitmap = ImageDecoder.decodeBitmap(source,
            new ImageDecoder.OnHeaderDecodedListener() {
                @Override
                public void onHeaderDecoded(ImageDecoder decoder,
                        ImageDecoder.ImageInfo info,
                        ImageDecoder.Source source) {
                    decoder.setTargetColorSpace(ColorSpace.get(Named.SRGB));
                }
            });
} catch (IOException e) {
    // handle exception.
}

ImageDecoder also has the advantage to let you know the encoded color space of the bitmap before you get the final bitmap by passing an ImageDecoder.OnHeaderDecodedListener and checking ImageDecoder.ImageInfo#getColorSpace(). And thus, depending on how your applications handle color spaces, you can check the encoded color space of the contents and set the target color space differently.

ImageDecoder.Source source =
        ImageDecoder.createSource(FILE_PATH);
try {
    bitmap = ImageDecoder.decodeBitmap(source,
            new ImageDecoder.OnHeaderDecodedListener() {
                @Override
                public void onHeaderDecoded(ImageDecoder decoder,
                        ImageDecoder.ImageInfo info,
                        ImageDecoder.Source source) {
                    ColorSpace cs = info.getColorSpace();
                    // Do something...
                }
            });
} catch (IOException e) {
    // handle exception.
}

For more detailed usage you can check out the ImageDecoder APIs here.

Known bad practices

Some typical bad practices include but are not limited to:

  • Always assume sRGB color space
  • Upload image as texture without necessary conversion
  • Ignore the ICC profile during compression

All these cause a severe users perceived results: Color distortion. For example, below is a code snippet that results in the application not color correct:

// This is bad, don't do it!
final BitmapFactory.Options options = new BitmapFactory.Options();
final Bitmap bitmap = BitmapFactory.decodeFile(FILE_PATH, options);
glTexImage2D(GLES20.GL_TEXTURE_2D, 0, GLES31.GL_RGBA, bitmap.getWidth(),
        bitmap.getHeight(), 0, GLES20.GL_RGBA, GLES20.GL_UNSIGNED_BYTE, null);
GLUtils.texSubImage2D(GLES20.GL_TEXTURE_2D, 0, 0, 0, bitmap,
        GLES20.GL_RGBA, GLES20.GL_UNSIGNED_BYTE);

There's no color space checking before uploading the bitmap as the texture, and thus the application will end up with the below distorted image from the color correctness test.

large round balloons outside on floor in front of a concrete wall

Optional: Be wide color capable

Besides the above changes you must make in order to handle images correctly, if your applications are heavily image based, you will want to take additional steps to display these images in the full vibrant range by enabling the wide gamut mode in your manifest or creating a Display P3 surfaces.

To enable the wide color gamut in your activity, set the colorMode attribute to wideColorGamut in your AndroidManifest.xml file. You need to do this for each activity for which you want to enable wide color mode.

android:colorMode="wideColorGamut"

You can also set the color mode programmatically in your activity by calling the setColorMode(int) method and passing in COLOR_MODE_WIDE_COLOR_GAMUT.

To render wide color gamut contents, besides the wide color contents, you will also need to create a wide color gamut surfaces to render to. In OpenGL for example, your application must first check the following extensions:

And then, request the Display P3 as the color space when creating your surfaces, as shown in the following code snippet:

private static final int EGL_GL_COLORSPACE_DISPLAY_P3_PASSTHROUGH_EXT = 0x3490;

public EGLSurface createWindowSurface(EGL10 egl, EGLDisplay display,
                                      EGLConfig config, Object nativeWindow) {
  EGLSurface surface = null;
  try {
    int attribs[] = {
      EGL_GL_COLORSPACE_KHR, EGL_GL_COLORSPACE_DISPLAY_P3_PASSTHROUGH_EXT,
      egl.EGL_NONE
    };
    surface = egl.eglCreateWindowSurface(display, config, nativeWindow, attribs);
  } catch (IllegalArgumentException e) {}
  return surface;
}

Also check out our post about more details on how you can adopt wide color gamut in native code.

APIs design guideline for image library

Finally, if you own or maintain an image decoding/encoding library, you will need to at least pass the color correctness tests as well. To modernize your library, there are two things we strongly recommend you to do when you extend APIs to manage color:

  1. Strongly recommend to explicitly accept ColorSpace as a parameter when you design new APIs or extend existing APIs. Instead of hardcoding a color space, an explicit ColorSpace parameter is a more future-proof way moving forward.
  2. Strongly recommend all legacy APIs to explicitly decode the bitmap to sRGB color space. Historically there's no color management, and thus Android has been treating everything as sRGB implicitly until Android 8.0 (API level 26). This allows you to help your users maintain backward compatibility.

After you finish, go back to the above section and perform the two color tests.

Dark mode available for Calendar and Keep on Android

What’s changing 

Google Calendar and Keep will now support Dark mode on Android.

 

Dark mode for Google Calendar. 

 

Dark mode for Google Keep. 

Who’s impacted 

End users.

Why you’d use it 

Dark mode is a popular feature that’s frequently requested by Calendar and Keep users. It creates a better viewing experience in low-light conditions by reducing brightness.

How to get started 


  • Admins: No action required. 
  • End users: 
    • Calendar 
      • Enable Dark mode by going to Settings > General > Theme. 
    •  Keep Enable 
      • Dark mode by going to Settings > Enable Dark Mode.

Additional details 


Both Calendar and Keep apps need to be updated to the latest version of the app to see this feature. 

Calendar 
Dark mode for Calendar will be supported on devices with Android N+ (i.e. Nougat and more recent releases).

Android Q users can set their OS to Dark mode, which means Calendar and all other apps will be in Dark mode by default. If users do not have their OS set to Dark mode, they can enable Dark mode in Calendar’s settings (see above).

For pre-Android-Q devices, users will be able to configure Calendar to go into Dark Mode when the device enters battery saving mode.

Keep 
Dark mode for Keep will be supported on devices with Android L-P. For these devices, Dark mode can be enabled from Keep’s settings (see above).

For Android Q devices, Dark will be on by default if the OS is set to Dark mode. Or, it can be enabled in Keep’s settings (see above).

Availability 

Rollout details 

  • Calendar: 
    • Gradual rollout (up to 15 days for feature visibility) starting on May 16, 2019. 
  •  Keep: 
    • Gradual rollout (up to 15 days for feature visibility) starting on May 20, 2019. G Suite editions Available to all G Suite editions. 
On/off by default? 

  • Calendar: 
    • For Android N - P, Dark mode will be OFF by default and can be enabled in Calendar settings (see above). 
    • For Android Q, this feature will be ON by default when the OS is set to Dark mode or can be enabled in Calendar settings (see above). 
  •  Keep: 
    • For Android L - P, this feature will be OFF by default and can be enabled in Keep settings (see above). 
    • For Android Q, this feature will be ON by default when the OS is set to Dark mode or can be enabled in Keep settings (see above).

Stay up to date with G Suite launches

Kotlin Is Everywhere! Join the global event series

Posted by Posted by Florina Muntenescu & Wojtek Kaliciński, Developer Advocates, Android

Last week at Google I/O, we announced a big step: Android development will become increasingly Kotlin-first. It’s a language that many of you already love: over 50% of professional Android developers now use Kotlin, and it’s the fastest-growing language on GitHub. As part of this announcement, many new Jetpack APIs and features will be offered first in Kotlin. So if you’re starting a new project, you should try writing it in Kotlin; code written in Kotlin often means much less code for you–less code to type, test, and maintain.

To help you dive deeper into Kotlin, we’re happy to announce a new program we’re launching together with JetBrains: Kotlin/Everywhere, a series of community-driven events focussing on the potential of Kotlin on all platforms. We are aiming to help learn the essentials and best practices of using Kotlin everywhere, be it for Android, back-end, front-end and other platforms.

Join the Kotlin/Everywhere global event series between June and December 2019.

Who can attend the events?

Whether you are a developer, a speaker, a Kotlin User Group, a Google Developer Group member or any other community leader join us. Anyone interested in learning Kotlin and its ecosystem, sharing knowledge, and hosting a Kotlin-focused event is welcome to attend.

If you are a developer wanting to learn more about Kotlin, or a speaker excited to share your Kotlin experience with others, you can find events near you to join. Just go to the map on the website. More events will be added over time.

How to host your Kotlin/Everywhere event?

If you want to host an event in your city, you can begin by checking out the detailed organizers’ guide. It will help you to decide on the format and what kind of support you might need. All the necessary tips and tricks, materials, and branding assets are inside. Go ahead and submit your event on the official web page.

Besides the detailed organizers’ guide, we also provide you with resources such as content, codelabs, and guidance to help you maximize your success. You can also apply for support: we have speakers from Google/JetBrains and can help by providing funding for venue, food and drinks, swag, or other. We will also list your event on the official website.

Still have questions? Ask them at our hangout sessions for organizers on May 16 and 17.

Let us know if you want to take part! Apply at kotl.in/everywhere

New features to make audio more accessible on your phone

Smartphones are key to helping all of us get through our days, from getting directions to translating a word. But for people with disabilities, phones have the potential to do even more to connect people to information and help them perform everyday tasks. We want Android to work for all users, no matter their abilities. And on Global Accessibility Awareness Day, we’re taking another step toward this aim with updates to Live Transcribe, coming next month.


Available on 1.8 billion Android devices, Live Transcribe helps bridge the connection between the deaf and the hearing via real-time, real-world transcriptions for everyday conversations. With this update, we’re building on our machine learning and speech recognition technology to add new capabilities.


First, Live Transcribe will now show you sound events in addition to transcribing speech. You can see, for example, when a dog is barking or when someone is knocking on your door.  Seeing sound events allows you to be more immersed in the non-conversation realm of audio and helps you understand what is happening in the world. This is important to those who may not be able to hear non-speech audio cues such as clapping, laughter, music, applause, or the sound of a speeding vehicle whizzing by.


Second, you’ll now be able to copy and save transcripts, stored locally on your device for three days. This is useful not only for those with deafness or hearing loss—it also helps those who might be using real-time transcriptions in other ways, such as those learning a language for the first time or even, secondarily, journalists capturing interviews or students taking lecture notes. We’ve also made the audio visualization indicator bigger, so that users can more easily see the background audio around them.

New features of Live Transcribe

Caption: See sound events, like whistling or a dog barking, in the bottom left corner of the updated Live Transcribe.

With billions of active devices powered by Android, we’re humbled by the opportunity to build helpful tools that make the world’s information more accessible in the palm of everyone’s hand. As long as there are barriers for some people, we still have work to do. We’ll continue to release more features to enrich the lives of our accessibility community and the people around them.

New! Learn How to Build Android Apps with Android Jetpack and Kotlin

Posted by Dan Galpin

Developing Android Apps with Kotlin, developed by Google together with Udacity, is our newly-released, free, self-paced online course. You'll learn how to build Android apps using industry-standard tools and libraries in the Kotlin programming language.

Android development fundamentals are taught in the context of an architecture that provides the scaffolding for robust, maintainable applications. The course covers why and how to use Android Jetpack components such as Room for databases, Work Manager for background processing, the Navigation component, and more. You'll use popular community libraries to simplify common tasks such as Glide for image loading, Retrofit for networking, and Moshi for JSON parsing. The course teaches key Kotlin features such as coroutines to help you write your app code more quickly and concisely.

As you work through the course, you'll build fun and interesting apps, such as a Mars photo gallery, a trivia game, a sleep tracker and much more.

Two mobile phones with flow chart in between depicting the difference between an over view and details.
Three screens for Android Navigation Component Trivia screen on mobile

This course is intended for people who have programming experience and are comfortable with Kotlin basics. If you're new to the Kotlin language, we recommend taking the Udacity Kotlin Bootcamp course first.

The course is available free, online at Udacity; take it in your own time at your own pace.

Come learn how to build Android apps in Kotlin with us at https://www.udacity.com/course/ud9012.

Supporting Google Play developers regarding local market withholding tax regulations

Posted by Gloria On, Program Manager, Google Play

Many developers are increasingly focused on growing their businesses globally, and there were more than 94 billion apps downloaded from Google Play in the last year, reaching more than 190 countries. The regulatory environment is frequently changing in local markets, and in some countries local governments have implemented withholding tax requirements on transactions with which Google or our payment processor partners must comply. We strive to help both developers and Google meet local tax requirements in markets where we do business, and where Google or our payment processor partners are required to withhold taxes, we may need to deduct those amounts from our payments to developers.

Due to new requirements in some markets, we'll be rolling out withholding taxes soon to all those doing business in those countries. We wanted to bring this to the attention of Google Play developers to allow you time to prepare for these upcoming changes and take any necessary measures to meet these obligations. We strongly recommend developers consult with a professional tax advisor on your individual tax implications in affected markets and for guidance on the potential impact on your business so that you can make any necessary preparations.

The first countries where we will roll out these changes will be Saudi Arabia, Kuwait, and Myanmar. You can refer to the Google Play help center page to stay informed on future updates and changes.

How useful did you find this blog post?

Find your balance with new Digital Wellbeing tools

Google I/O is always exciting for me. It’s a great moment when we get to tell the world about a wide range of new products and features that can help everyone do more with technology. Because of how intertwined tech is with every aspect of our lives, how we balance its use with our wellbeing has to be front and center. So, as we did last year, we made time to discuss how our users can find a balance by using technology more intentionally (and that might mean using it less).

Last year, we announced our commitment to digital wellbeing, a company-wide effort to help our users balance their technology use in a way that feels right for them. The idea has taken hold. A recent survey we commissioned found that 1 in 3 Americans have taken steps to improve their digital wellbeing in the last year, and more than 80 percent of them said this had a positive impact on their overall sense of wellbeing.

It’s still early, but we’re already seeing that some of our initial Digital Wellbeing features have helped people take control of their tech use. For instance, app timers have helped people stick to their goals over 90 percent of the time, according to our internal data from March of this year, and people who use Wind Down had a 27 percent drop in nightly usage on average.

Android Digital Wellbeing: Tools for balance

Coming to Android Q

We know there’s much more we can be doing, which is why we were excited to announce a number of new tools and features at I/O last week. We’re making several improvements to existing features, such as giving you more visibility into the status of your app timers, and allowing Wind Down to be scheduled by day of the week. And, building on the success of app timers, we’re extending its functionality to Chrome on Android, which will let you to set time limits on specific websites.

Our devices should help support our intentions throughout the day. Whether it’s work, school or family and friends that we want to focus on, our devices shouldn’t get in the way. Notifications are an important part of keeping you informed, but not all of them are urgent enough to divert your attention. Now you can choose to make some notifications ‘Gentle’. Gentle notifications won’t make noise, vibrate or appear on the lock screen but are always available if you want to browse.

And we created Focus mode, which allows you to temporarily pause distracting apps with a single tap from Quick Settings. Finally, because many people want more positive encouragement, we’re adding the ability  to set a screen time goal with helpful nudges to stay on track.

AndroidQ_Focus Mode.gif

New features for families

For parents, screen time is often a unique challenge; in fact, according to a recent study commissioned by Google, 67 percent of parents are concerned about the amount of time their kids spend on devices. People with kids tell us they love that Family Link lets them set daily screen time limits, but we know that nothing about parenting is black and white. We announced last week that Family Link will roll out new features that enable parents to fine-tune these boundaries by setting app-specific time limits and awarding bonus screen time directly from their own device. (We hope this will also help provide a little balance to family dynamics.)

But tools and features are just part of the solution; for families in particular, communication is key. So on wellbeing.google, we now offer tips and advice from experts, including a conversation guide to help parents talk to their kids about technology use.

We believe technology should improve life, not distract from it, so we’ve made a company-wide commitment to prioritize our users’ satisfaction over the amount of time they spend with our products, and our teams are designing with digital wellbeing as a core principle. We’re focused on improving lives—today and in the future—and digital wellbeing is one of the most important ways we’re working to make that happen.

What’s New in Android Q Security

Posted by Rene Mayrhofer and Xiaowen Xin, Android Security & Privacy Team

With every new version of Android, one of our top priorities is raising the bar for security. Over the last few years, these improvements have led to measurable progress across the ecosystem, and 2018 was no different.

In the 4th quarter of 2018, we had 84% more devices receiving a security update than in the same quarter the prior year. At the same time, no critical security vulnerabilities affecting the Android platform were publicly disclosed without a security update or mitigation available in 2018, and we saw a 20% year-over-year decline in the proportion of devices that installed a Potentially Harmful App. In the spirit of transparency, we released this data and more in our Android Security & Privacy 2018 Year In Review.

But now you may be asking, what’s next?

Today at Google I/O we lifted the curtain on all the new security features being integrated into Android Q. We plan to go deeper on each feature in the coming weeks and months, but first wanted to share a quick summary of all the security goodness we’re adding to the platform.

Encryption

Storage encryption is one of the most fundamental (and effective) security technologies, but current encryption standards require devices have cryptographic acceleration hardware. Because of this requirement many devices are not capable of using storage encryption. The launch of Adiantum changes that in the Android Q release. We announced Adiantum in February. Adiantum is designed to run efficiently without specialized hardware, and can work across everything from smart watches to internet-connected medical devices.

Our commitment to the importance of encryption continues with the Android Q release. All compatible Android devices newly launching with Android Q are required to encrypt user data, with no exceptions. This includes phones, tablets, televisions, and automotive devices. This will ensure the next generation of devices are more secure than their predecessors, and allow the next billion people coming online for the first time to do so safely.

However, storage encryption is just one half of the picture, which is why we are also enabling TLS 1.3 support by default in Android Q. TLS 1.3 is a major revision to the TLS standard finalized by the IETF in August 2018. It is faster, more secure, and more private. TLS 1.3 can often complete the handshake in fewer roundtrips, making the connection time up to 40% faster for those sessions. From a security perspective, TLS 1.3 removes support for weaker cryptographic algorithms, as well as some insecure or obsolete features. It uses a newly-designed handshake which fixes several weaknesses in TLS 1.2. The new protocol is cleaner, less error prone, and more resilient to key compromise. Finally, from a privacy perspective, TLS 1.3 encrypts more of the handshake to better protect the identities of the participating parties.

Platform Hardening

Android utilizes a strategy of defense-in-depth to ensure that individual implementation bugs are insufficient for bypassing our security systems. We apply process isolation, attack surface reduction, architectural decomposition, and exploit mitigations to render vulnerabilities more difficult or impossible to exploit, and to increase the number of vulnerabilities needed by an attacker to achieve their goals.

In Android Q, we have applied these strategies to security critical areas such as media, Bluetooth, and the kernel. We describe these improvements more extensively in a separate blog post, but some highlights include:

  • A constrained sandbox for software codecs.
  • Increased production use of sanitizers to mitigate entire classes of vulnerabilities in components that process untrusted content.
  • Shadow Call Stack, which provides backward-edge Control Flow Integrity (CFI) and complements the forward-edge protection provided by LLVM’s CFI.
  • Protecting Address Space Layout Randomization (ASLR) against leaks using eXecute-Only Memory (XOM).
  • Introduction of Scudo hardened allocator which makes a number of heap related vulnerabilities more difficult to exploit.

Authentication

Android Pie introduced the BiometricPrompt API to help apps utilize biometrics, including face, fingerprint, and iris. Since the launch, we’ve seen a lot of apps embrace the new API, and now with Android Q, we’ve updated the underlying framework with robust support for face and fingerprint. Additionally, we expanded the API to support additional use-cases, including both implicit and explicit authentication.

In the explicit flow, the user must perform an action to proceed, such as tap their finger to the fingerprint sensor. If they’re using face or iris to authenticate, then the user must click an additional button to proceed. The explicit flow is the default flow and should be used for all high-value transactions such as payments.

Implicit flow does not require an additional user action. It is used to provide a lighter-weight, more seamless experience for transactions that are readily and easily reversible, such as sign-in and autofill.

Another handy new feature in BiometricPrompt is the ability to check if a device supports biometric authentication prior to invoking BiometricPrompt. This is useful when the app wants to show an “enable biometric sign-in” or similar item in their sign-in page or in-app settings menu. To support this, we’ve added a new BiometricManager class. You can now call the canAuthenticate() method in it to determine whether the device supports biometric authentication and whether the user is enrolled.

What’s Next?

Beyond Android Q, we are looking to add Electronic ID support for mobile apps, so that your phone can be used as an ID, such as a driver’s license. Apps such as these have a lot of security requirements and involves integration between the client application on the holder’s mobile phone, a reader/verifier device, and issuing authority backend systems used for license issuance, updates, and revocation.

This initiative requires expertise around cryptography and standardization from the ISO and is being led by the Android Security and Privacy team. We will be providing APIs and a reference implementation of HALs for Android devices in order to ensure the platform provides the building blocks for similar security and privacy sensitive applications. You can expect to hear more updates from us on Electronic ID support in the near future.

Queue the Hardening Enhancements

Posted by Jeff Vander Stoep, Android Security & Privacy Team and Chong Zhang, Android Media Team

Android Q Beta versions are now publicly available. Among the various new features introduced in Android Q are some important security hardening changes. While exciting new security features are added in each Android release, hardening generally refers to security improvements made to existing components.

When prioritizing platform hardening, we analyze data from a number of sources including our vulnerability rewards program (VRP). Past security issues provide useful insight into which components can use additional hardening. Android publishes monthly security bulletins which include fixes for all the high/critical severity vulnerabilities in the Android Open Source Project (AOSP) reported through our VRP. While fixing vulnerabilities is necessary, we also get a lot of value from the metadata - analysis on the location and class of vulnerabilities. With this insight we can apply the following strategies to our existing components:

  • Contain: isolating and de-privileging components, particularly ones that handle untrusted content. This includes:
    • Access control: adding permission checks, increasing the granularity of permission checks, or switching to safer defaults (for example, default deny).
    • Attack surface reduction: reducing the number of entry/exit points (i.e. principle of least privilege).
    • Architectural decomposition: breaking privileged processes into less privileged components and applying attack surface reduction.
  • Mitigate: Assume vulnerabilities exist and actively defend against classes of vulnerabilities or common exploitation techniques.

Here’s a look at high severity vulnerabilities by component and cause from 2018:

Most of Android’s vulnerabilities occur in the media and bluetooth components. Use-after-free (UAF), integer overflows, and out of bounds (OOB) reads/writes comprise 90% of vulnerabilities with OOB being the most common.

A Constrained Sandbox for Software Codecs

In Android Q, we moved software codecs out of the main mediacodec service into a constrained sandbox. This is a big step forward in our effort to improve security by isolating various media components into less privileged sandboxes. As Mark Brand of Project Zero points out in his Return To Libstagefright blog post, constrained sandboxes are not where an attacker wants to end up. In 2018, approximately 80% of the critical/high severity vulnerabilities in media components occurred in software codecs, meaning further isolating them is a big improvement. Due to the increased protection provided by the new mediaswcodec sandbox, these same vulnerabilities will receive a lower severity based on Android’s severity guidelines.

The following figure shows an overview of the evolution of media services layout in the recent Android releases.

  • Prior to N, media services are all inside one monolithic mediaserver process, and the extractors run inside the client.
  • In N, we delivered a major security re-architect, where a number of lower-level media services are spun off into individual service processes with reduced privilege sandboxes. Extractors are moved into server side, and put into a constrained sandbox. Only a couple of higher-level functionalities remained in mediaserver itself.
  • In O, the services are “treblized,” and further deprivileged that is, separated into individual sandboxes and converted into HALs. The media.codec service became a HAL while still hosting both software and hardware codec implementations.
  • In Q, the software codecs are extracted from the media.codec process, and moved back to system side. It becomes a system service that exposes the codec HAL interface. Selinux policy and seccomp filters are further tightened up for this process. In particular, while the previous mediacodec process had access to device drivers for hardware accelerated codecs, the software codec process has no access to device drivers.

With this move, we now have the two primary sources for media vulnerabilities tightly sandboxed within constrained processes. Software codecs are similar to extractors in that they both have extensive code parsing bitstreams from untrusted sources. Once a vulnerability is identified in the source code, it can be triggered by sending a crafted media file to media APIs (such as MediaExtractor or MediaCodec). Sandboxing these two services allows us to reduce the severity of potential security vulnerabilities without compromising performance.

In addition to constraining riskier codecs, a lot of work has also gone into preventing common types of vulnerabilities.

Bound Sanitizer

Incorrect or missing memory bounds checking on arrays account for about 34% of Android’s userspace vulnerabilities. In cases where the array size is known at compile time, LLVM’s bound sanitizer (BoundSan) can automatically instrument arrays to prevent overflows and fail safely.

BoundSan instrumentation

BoundSan is enabled in 11 media codecs and throughout the Bluetooth stack for Android Q. By optimizing away a number of unnecessary checks the performance overhead was reduced to less than 1%. BoundSan has already found/prevented potential vulnerabilities in codecs and Bluetooth.

More integer sanitizer in more places

Android pioneered the production use of sanitizers in Android Nougat when we first started rolling out integer sanization (IntSan) in the media frameworks. This work has continued with each release and has been very successful in preventing otherwise exploitable vulnerabilities. For example, new IntSan coverage in Android Pie mitigated 11 critical vulnerabilities. Enabling IntSan is challenging because overflows are generally benign and unsigned integer overflows are well defined and sometimes intentional. This is quite different from the bound sanitizer where OOB reads/writes are always unintended and often exploitable. Enabling Intsan has been a multi year project, but with Q we have fully enabled it across the media frameworks with the inclusion of 11 more codecs.

IntSan Instrumentation

IntSan works by instrumenting arithmetic operations to abort when an overflow occurs. This instrumentation can have an impact on performance, so evaluating the impact on CPU usage is necessary. In cases where performance impact was too high, we identified hot functions and individually disabled IntSan on those functions after manually reviewing them for integer safety.

BoundSan and IntSan are considered strong mitigations because (where applied) they prevent the root cause of memory safety vulnerabilities. The class of mitigations described next target common exploitation techniques. These mitigations are considered to be probabilistic because they make exploitation more difficult by limiting how a vulnerability may be used.

Shadow Call Stack

LLVM’s Control Flow Integrity (CFI) was enabled in the media frameworks, Bluetooth, and NFC in Android Pie. CFI makes code reuse attacks more difficult by protecting the forward-edges of the call graph, such as function pointers and virtual functions. Android Q uses LLVM’s Shadow Call Stack (SCS) to protect return addresses, protecting the backwards-edge of control flow graph. SCS accomplishes this by storing return addresses in a separate shadow stack which is protected from leakage by storing its location in the x18 register, which is now reserved by the compiler.

SCS Instrumentation

SCS has negligible performance overhead and a small memory increase due to the separate stack. In Android Q, SCS has been turned on in portions of the Bluetooth stack and is also available for the kernel. We’ll share more on that in an upcoming post.

eXecute-Only Memory

Like SCS, eXecute-Only Memory (XOM) aims at making common exploitation techniques more expensive. It does so by strengthening the protections already provided by address space layout randomization (ASLR) which in turn makes code reuse attacks more difficult by requiring attackers to first leak the location of the code they intend to reuse. This often means that an attacker now needs two vulnerabilities, a read primitive and a write primitive, where previously just a write primitive was necessary in order to achieve their goals. XOM protects against leaks (memory disclosures of code segments) by making code unreadable. Attempts to read execute-only code results in the process aborting safely.

Tombstone from a XOM abort

Starting in Android Q, platform-provided AArch64 code segments in binaries and libraries are loaded as execute-only. Not all devices will immediately receive the benefit as this enforcement has hardware dependencies (ARMv8.2+) and kernel dependencies (Linux 4.9+, CONFIG_ARM64_UAO). For apps with a targetSdkVersion lower than Q, Android’s zygote process will relax the protection in order to avoid potential app breakage, but 64 bit system processes (for example, mediaextractor, init, vold, etc.) are protected. XOM protections are applied at compile-time and have no memory or CPU overhead.

Scudo Hardened Allocator

Scudo is a dynamic heap allocator designed to be resilient against heap related vulnerabilities such as:

  • Use-after-frees: by quarantining freed blocks.
  • Double-frees: by tracking chunk states.
  • Buffer overflows: by check summing headers.
  • Heap sprays and layout manipulation: by improved randomization.

Scudo does not prevent exploitation but rather proactively manages memory in a way to make exploitation more difficult. It is configurable on a per-process basis depending on performance requirements. Scudo is enabled in extractors and codecs in the media frameworks.

Tombstone from Scudo aborts

Contributing security improvements to Open Source

AOSP makes use of a number of Open Source Projects to build and secure Android. Google is actively contributing back to these projects in a number of security critical areas:

Thank you to Ivan Lozano, Kevin Deus, Kostya Kortchinsky, Kostya Serebryany, and Mike Logan for their contributions to this post.