Author Archives: Android Developers

What’s new with Fast Pair

Posted by Catherina Xu (Product Manager)

Last November, we released Fast Pair with the Jaybird Tarah Bluetooth headphones. Since then, we’ve engaged with dozens of OEMs, ODMs, and silicon partners to bring Fast Pair to even more devices. Last month, we held a talk at I/O announcing 10+ certified devices, support for Qualcomm’s Smart Headset Development Kit, and upcoming experiences for Fast Pair devices.

The Fast Pair team presenting at I/O 2019.

The Fast Pair team presenting at I/O 2019.

Upcoming experiences

Fast Pair makes pairing seamless across Android phones - this year, we are introducing additional features to improve Bluetooth device management.

  • True Wireless Features. As True Wireless Stereo (TWS) headphones continue to gain momentum in the market and with users, it is important to build system-wide support for TWS. Later this year, TWS headsets with Fast Pair will be able to broadcast individual battery information for the case and buds. This enables features such as case open and close battery notifications and per-component battery reporting throughout the UI.

     Detailed battery level notifications surfaced during “case open” for TWS headphones.

    Detailed battery level notifications surfaced during “case open” for TWS headphones.

    • Find My Device. Fast Pair devices will soon be surfaced in the Find My Device app and website, allowing users to easily track down lost devices. Headset owners can view the location and time of last use, as well as unpair or ring the buds to locate when they are in range.

    Connected Device Details. In Android Q, Fast Pair devices will have an enhanced Bluetooth device details page to centralize management and key settings. This includes links to Find My Device, Assistant settings (if available), and additional OEM-specified settings that will link to the OEM’s companion app.

    The updated Device details screen in Q allows easy access to key settings and the headphone’s companion app.

    The updated Device details screen in Q allows easy access to key settings and the headphone’s companion app.

    Compatible Devices

    Below is a list of devices that were showcased during our I/O talk:

    • Anker Spirit Pro GVA
    • Anker SoundCore Flare+ (Speaker)
    • JBL Live 220BT
    • JBL Live 400BT
    • JBL Live 500BT
    • JBL Live 650BT
    • Jaybird Tarah
    • 1More Dual Driver BT ANC
    • LG HBS-SL5
    • LG HBS-PL6S
    • LG HBS-SL6S
    • LG HBS-PL5
    • Cleer Ally Plus

    Interested in Fast Pair?

    If you are interested in creating Fast Pair compatible Bluetooth devices, please take a look at:

    Once you have selected devices to integrate, head to our Nearby Devices console to register your product. Reach out to us at fast-pair-integrations@google.com if you have any questions.

  • Kotlin named Breakout Project of the Year at OSCON

    Posted by Wojtek Kaliciński, Developer Advocate, Android

    Stephanie on Stage with Kotlin on screen

    Stephanie Saad Cuthbertson announces support for Kotlin during the Developer Keynote at I/O 2017.

    Today at OSCON (the O'Reilly Open Source Software Conference), Kotlin was awarded the Open Source Award for Breakout Project of the Year.

    There is no doubt to us why Kotlin received this award: it’s a fast moving (but thoughtfully developed) programming language that lets you write better code, faster. It’s great to see Kotlin continue to receive the sort of recognition as Breakout Project of the Year, building on other awards like #1 fastest growing language on Github.

    We’re big fans of Kotlin, and we’ve heard that you are too – feedback from you is in part why we announced support for the language over two years ago. This meant bundling the Kotlin plugin in Android Studio, along with promising to support Kotlin-built apps going forward.

    But there was a long way to go for many teams at Google to provide a first class experience with Kotlin in the Android ecosystem, and to convince developers that Kotlin on Android is not just a fad, but is here to stay.

    If you haven’t tried Kotlin yet, now is a great time to start! In fact, in the past two years, we’ve been adding a number of new features and upgrades to the Kotlin for Android experience, including:

    • Android Jetpack APIs now have first class support for Kotlin Coroutines, transforming the way we do async operations on Android. This includes Room, LiveData, ViewModels, WorkManager and more coming in the future.

    • Many Jetpack libraries have Kotlin extension libraries (KTX) to make using them even more fluent with Kotlin.
    • The compilation toolchain has received many improvements for Kotlin, including compiler enhancements, incremental annotation processing with KAPT, and Kotlin-specific R8 optimizations.
    • All of our documentation pages now contain Kotlin code snippets, so you can easily compare how our APIs work in both languages.
    Kotlin code snippet
    • Most of our flagship samples are also written in Kotlin (including IOSched, Plaid, Sunflower and many more), along with any new samples that we make in the future.
    • We've added a language switcher to our API reference pages, so you can have a Kotlin view of the AndroidX library and the Android framework.
    Kotlin view of the AndroidX library
    • We doubled down on providing guidance to developers and teams who want to switch to Kotlin on our developers.android.com/kotlin pages.
    • Our Developer Relations engineers are posting real life examples and guides on integrating Kotlin in your apps on our Medium publication, such as the great intro to Coroutines on Android series and many more.
    • If you prefer to learn Kotlin in person, you can join one of the many Kotlin/Everywhere events happening around the world. If you are an organizer in a local developer community, consider signing up to host your own event!
      This initiative is a cooperation between JetBrains and Google.
    • For those of you who don't have access to in-person training, we added a new, free course on Udacity for Developing Android apps in Kotlin. Our Kotlin Bootcamp for Programmers course is still available as well!
    • We have worked with many external partners to gather feedback and learn about their experiences with Kotlin, such as this case study with Square.
    • And lastly, we've enabled Kotlin as a supported language for Android app teams at Google. We're already seeing adoption in apps such as Google Home, Google Drive, Android System UI, Nest, with many more to follow.

    The road to fully supporting Kotlin on Android was not always easy, but it was truly rewarding seeing Kotlin adoption among professional Android developers rise from a handful of early adopters to around 50% since the original announcement!

    We were confident when we announced earlier this year at Google I/O 2019 that Android is going increasingly Kotlin-first, opening up the possibility for APIs built specifically around Kotlin and for Kotlin users, starting with the new, declarative UI toolkit - Jetpack Compose (still in early development).

    We want to congratulate JetBrains, our partners through the Kotlin Foundation and creators of Kotlin, on receiving the OSCON Open Source Award today. It shows how disruptive and transformative Kotlin has been, and not just for the Android developer community, but beyond.

    We know one thing: on Android, Kotlin is here to stay.

    Android Dev Summit 2019 Registration is Open

    Posted by Sean McQuillan, Developer Advocate, Android

    Registration now open! #AndroidDevSummit. Oct 23-24 in Sunnyvale, CA

    Registration is now open for Android Dev Summit 2019!

    Learn, share, and connect at #AndroidDevSummit 2019. It's a great place to learn new Android development skills, share feedback and ideas with the Android engineering team, and connect with Android developers from around the globe.

    Join us for the two day conference on October 23-24 hosted at the Google Event Center (MP7) in Sunnyvale, CA. We'll share two days of deep technical talks covering topics such as Jetpack, Android Studio, Android Q, Kotlin, and more. You will learn about the latest innovations straight from the Android engineering team, discover best practices to help you build even better apps, and accelerate your teams’ productivity on Android.

    The Android engineering team will be there in person to answer your questions, hear your ideas and feedback (we love that!), and discuss the direction of Android development. And you will be joined by Android developers from around the globe ⁠— it’s a great place to connect with your community.

    Conference details

    When: October 23-24

    Where: Google Event Center (MP7)

    Unable to attend?

    Wherever you are, you can still watch the talks and engage with the community. You can tune in from anywhere to watch all of the talks online by joining our livestream. Sign up here to stay updated on event announcements. All of the talks will also be posted on YouTube soon after the event, so you can always catch up with the recordings on your own schedule.

    The event schedule has not yet been posted, but we encourage you to check out last year’s sessions to learn more about the great content and opportunities Android Dev Summit has to offer.

    Register now

    Attendance is free and by invitation only ⁠— register now to become eligible for an invitation. Selected attendees will receive their tickets after registration closes on August 15th at 5:00pm PDT. #AndroidDevSummit will fill up fast, so be sure to register today.

    What’s new for text in Android Q

    Posted by Florina Muntenescu, Android Developer Advocate

    Displaying text is an important task in most apps, so in Android Q we're continuing to introduce new features to support your needs and improve performance. We disabled hyphenation by default, enabled creating a typeface using multiple fonts or font families, exposed the list of fonts installed on the device, and improved some of the most-used text styling APIs.

    Hyphenation is off by default in Android Q and AppCompat v1.1.0

    Our performance tests showed that when hyphenation is enabled, up to 70% of the time spent on measuring text is on hyphenation.

    pie chart showing CPU of time spent making StaticLayout: Hyphenation takes up to 70% of the time spent measuring text, 30% Other text

    Hyphenation takes up to 70% of the time spent measuring text

    Given that hyphenation often isn’t needed for all TextViews in an app, and because of the impact on performance, we decided to turn hyphenation off by default in Android Q and AppCompat v1.1.0. If you want to use hyphenation, you need to manually turn it on in your app by setting the hyphenation frequency to normal. You can set this in multiple ways:

    As a TextAppearance attribute in styles.xml:

    <style name="MyTextAppearance" parent="TextAppearance.AppCompat">
        <item name="android:hyphenationFrequency">normal</item>
    </style>
    

    As a TextView attribute:

    <TextView android:hyphenationFrequency="normal" />
    

    Directly in code:

    textView.hyphenationFrequency = Layout.HYPHENATION_FREQUENCY_NORMAL
    

    Find out more about how hyphenation works from this talk at Android Dev Summit 2018.

    Use multiple custom fonts in the same TextView

    Consider a button which mixes a custom font (Lato in this example) with an icon font:

    Secure Checkout Button with lock icon, icon and latin fonts

    Button with icon and Latin fonts

    The Button class accepts only a single instance of a typeface to be set on the text. Pre-Android Q, you can create a Typeface using a single font family. Android Q enables the creation of a typeface from multiple font families with a new API, Typeface.CustomFallbackBuilder, that allows adding up to 64 font families per typeface.

    Our icon font example can be implemented like this:

    button.typeface = Typeface.CustomFallbackBuilder(
        // add the Latin font
        FontFamily.Builder(
            Font.Builder(assets, "lato.ttf").build()
        ).build()
    ).addCustomFallback(
        // add the icon font
        FontFamily.Builder(
            Font.Builder(assets, "icon_font.ttf").build()
        ).build()
    ).build()
    

    When creating the font family, make sure you don’t put fonts that belong to different families in the same font family object nor the same style fonts into the same font family. For example, putting Lato, Kosugi, and Material into the same font family creates an invalid configuration, as does putting two bold fonts into the same font family.

    To define the general font family (serif, sans-serif, or monospace) to be used when text is rendered using system fonts, use the setSystemFallback() method to set the system fallback font:

    Typeface.CustomFallbackBuilder(
        FontFamily.Builder(
           ...
        ).build()
    ).setSystemFallback("sans-serif")
    .build()
    

    Text styling API updates

    Android Q brings several updates to different text styling APIs:

    Improved support for variable fonts

    TextAppearance now supports the fontVariationSettings attribute:

    <style name="MyTextAppearance" parent="TextAppearance.AppCompat">
        <item name="android:fontVariationSettings">...</item>
    </style>
    

    The fontVariationSettings attribute can be set directly on the TextView in Android Q and in AppCompatTextView:

    <TextView
        ...
        app:fontVariationSettings="..."
    />
    

    Improved spans APIs

    TextAppearanceSpan now supports typeface, shadow settings, fontFeatureSettings and fontVariationSettings.

    LineBackgroundSpan and LineHeightSpan interfaces now have standard implementations: LineBackgroundSpan.Standard and LineHeightSpan.Standard.

    Access system fonts

    With more than 100 languages supported by Android, and with different fonts supporting different character sets, knowing which system font can render a given character is not trivial. Apps doing their own text rendering such as games, document viewers, or browsers need this information. In Android Q, you can retrieve the supported system font for a string with the FontMatcher NDK API.

    System fonts that can render this text

    System fonts that can render this text

    Let’s consider the above search string. The FontMatcher API returns us the font object and length. A simplified pseudocode example looks like this:

    // font = NotoSansCJK-Regular.ttc
    // length = 2
    auto[font, length] = AFontMatcher_match("たすく a.k.a. のな");
    
    // font = Roboto-Regular.ttf
    // length = 8
    auto[font, length] = AFontMatcher_match(" a.k.a. のな");
    
    // font = NotoSansCJK-Regular.ttc
    // length = 2
    auto[font, length] = AFontMatcher_match("のな");
    

    The FontMatcher API never returns nullptr:

    • If no font supports the given string, a font for Tofu (󟿽), the missing glyph symbol, is returned.
    • If no exact style is supported, a font with the closest, most similar style is returned.

    If you want to get all available system fonts, you can do this with a new font enumeration API. In Java, you can use SystemFonts.getAvailableFonts, or in the NDK, you can use ASystemFontIterator. The results of the font enumeration are changed only by a system update, so you should cache them.

    Font updates

    New Myanmar font

    Android added a new Myanmar font to Android Q that is Unicode-compliant and capable of rendering both Unicode and non-Unicode Burmese (commonly known as Zawgyi), right out of the box. This means starting in Android Q, Android makes it easier for users to switch to Unicode: a user can now use a Unicode font to read Unicode and non-Unicode text for the first time. Android also added new requirements to the Android ecosystem CDD that takes a stronger stance in requiring Unicode, including a new subtag "Qaag" which OEMs should use as a locale designating non-Unicode Burmese. All of these changes should make developers’ life easier in the long term, as reduced ecosystem fragmentation makes it easier to develop for our 50M users in Myanmar.

    New emojis

    New emojis in Android Q

    New emojis in Android Q

    Say Hello to your new emoji friends! The latest update includes a number of disability-focused emojis, 59 gender-inclusive designs, multi-racial couples, as well as a few cute animals and household objects. See the latest and greatest in Gboard on your Android Q device of choice.

    Text plays an important role in a vast majority of apps, so we’re continuing to invest in improving text API features and performance. Learn more about the new APIs in Android Q along with best practices when working with text in our Google I/O 2019 talk:

    Android Q Beta 5 Update

    Posted by Dave Burke, VP of Engineering

    AndroidQ logo

    Android Q Beta 5 launches today! Today we're rolling out Beta 5, bringing Android Q Beta very close to the system behaviors you'll see in the final release. Developer APIs were already finalized in the previous update. So, now is the time to test your apps for compatibility and make sure they are ready!

    You can get Beta 5 today on Pixel devices by enrolling here. If you're already enrolled and received Beta 4 on your Pixel device, you'll automatically get the update to Beta 5. Partners participating in the Android Q Beta program will also be updating their devices to Beta 5 over the coming weeks.

    To get started with Android Q Beta, visit developer.android.com/preview.

    What’s in Beta 5?

    The Beta 5 update includes the latest Android Q system images for Pixel and Android jEmulator, along with the final Android Q developer APIs (API level 29), the official API 29 SDK, and updated build tools for Android Studio. These give you everything you need to test your apps on Android Q and build with Android Q features.

    Gestural navigation updates

    As we talked about at Google I/O, we’ve been working closely with device-maker partners to ensure a standardized Android gestural navigation for users and developers. Gestural navigation lets apps use the full screen for content while minimizing the visible system chrome and navigation – which is particularly important on today’s edge-to-edge screens. In Beta 5 we’re continuing to improve and polish based on your feedback and we wanted to provide an update on a few key areas.

    We’ve introduced a swipe gesture from either corner to get to the Assistant - you’ll notice indicators in the bottom corners that we’re continuing to tune.

    For apps using a navigation drawer, we’ve added a peek behavior when users have grabbed the drawer to indicate that a swipe will bring in the navigation drawer. This works for all versions of DrawerLayout, with DrawerLayout 1.1.0-alpha02 optimized for the best experience.

    Custom launchers are another area where we’ve heard feedback and we’re continuing to work on issues, particularly with stability and Recents. Starting in Beta 6, we’ll switch users to 3-button navigation when they are using a custom launcher by default. We’ll address the remaining issues in a post-launch update allowing all users to switch to gestural navigation. Meanwhile, please continue to give us your feedback.

    Get your apps ready for Android Q!

    With the consumer release coming soon, it’s highest priority for all Android developers to update your current apps for compatibility as soon as possible.

    Here’s how to do it:

    We realize that supporting these changes is an investment for you too, and we're working to minimize the impact on your apps and be responsive to your input as we move toward the final release.

    Enhance your app with Android Q features and APIs

    Next, when you're ready, dive into Android Q and learn about the new features and APIs that you can use. Here are some of the top features to get started with.

    We recommend these for every app:

    • Dark Theme: Ensure a consistent experience for users who enable system-wide dark theme by adding a Dark Theme or enabling Force Dark.
    • Support gestural navigation in your app by going edge-to-edge and making sure your custom gestures are complementary to the system navigation gestures.
    • Optimize for foldables: Deliver seamless, edge-to-edge experiences on today’s innovative devices by optimizing for foldables.

    We recommend these if relevant for your app:

    • More interactive notifications: If your notifications include messages, enable suggested replies and actions in notifications to engage users and let them take action instantly.
    • Better biometrics: If you use biometric auth, move to BiometricPrompt, the preferred way to support fingerprint auth on modern devices.
    • Enriched recording: To support captioning or gameplay recording, enable audio playback capture -- it’s a great way to reach more users and make your app more accessible.
    • Better codecs: For media apps, try AV1 for video streaming and HDR10+ for high dynamic range video. For speech and music streaming, you can use Opus encoding, and for musicians, a native MIDI API is available.
    • Better networking APIs: If your app manages IoT devices over Wi-Fi, try the new network connection APIs for functions like configuring, downloading, or printing.

    These are just a few of the many new features and APIs in Android Q -- to see them all, visit the Android Q Beta site for developers.

    Publish your app updates to Google Play

    As soon as you're ready, publish your APK updates to Google Play that are compiled against, or optionally targeting, API 29. To make sure that your updated app runs well on Android Q as well as older versions, try using Google Play testing tracks. With tracks you can safely get early feedback from a small group of users -- including Beta 5 users — and then do a staged rollout to production.

    How do I get Beta 5?

    It’s easy! Just enroll any supported Pixel device here to get the update over-the-air. If you're already enrolled, you'll receive the update soon and no action is needed on your part. Downloadable system images are also available here. Partners who are participating in the Android Q Beta program will be updating their devices over the coming weeks. See android.com/beta for details.

    To get started developing, download the official API 29 SDK and tools into the stable release of Android Studio 3.4, or for the latest Android Q support update to Android Studio 3.5 Beta. Then follow these instructions to configure your environment, and see the release notes for known issues.

    There will be one more Beta release before the consumer launch later this quarter. Please continue to share your feedback and requests -- you can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues.

    Also, the Android engineering team will host a Reddit AMA on r/androiddev to answer your technical questions about Android Q later this month. Look out for an announcement on r/androiddev with details in the coming weeks. We look forward to addressing your questions!

    Capturing Audio in Android Q

    Posted by Don Turner, Developer Advocate for Android Media

    In Android Q there's a new API which allows applications to capture the audio of other applications. It's called the AudioPlaybackCapture API and it enables some important use cases for easier content sharing and accessibility.

    Some examples include:

    • Live captioning - allowing the audio content of the currently playing app to be captioned or translated in real time. In fact, the Live Caption feature shown at I/O this year is a client of this API. Live captioning allows your users to engage with audible content even when it's impossible or inconvenient to do so, such as listening in a public place without headphones.
    • Game recording and streaming - In-game sounds can be recorded and streamed to live audiences, helping to increase the social reach of game content.

    There may be some situations where a developer wishes to disallow the capture of their app's audio. This article explains how audio capture works for users and how developers can disallow their app's audio from being captured if they need to.

    What does the user see?

    In order to capture the audio of other apps the user must grant the record audio permission to the app doing the capturing.

    AUDIO_RECORD permissions dialog

    AUDIO_RECORD permissions dialog

    Additionally, before a capture session can be started the capturing app must call MediaProjectionManager.createScreenCaptureIntent(). This will display the following dialog to the user: screen capture intent dialog

    Screen capture intent dialog

    The user must tap "Start now" in order for a capturing session to be started. This will allow both video and audio to be captured.

    cast icon showing red in status bar

    Cast icon showing red in status bar

    During a capture session the cast icon is shown in red in the status bar.

    Can my app's audio be captured?

    Whether your app's audio can be captured by default depends on your target API. Here's a table which summarizes the default behaviour:

    Target API Third party apps can capture your app's audio by default? System apps and components can capture your app's audio by default?
    28 and below No, the app needs to explicitly opt-in Yes for audio with usage type MEDIA, GAME and UNKNOWN
    29 Yes for audio with usage type MEDIA, GAME and UNKNOWN Yes for audio with usage type MEDIA, GAME and UNKNOWN


    Disallowing capture by third party apps

    There may be situations where an app wishes to disallow its audio from being captured by other apps. This could be because the audio contains:

    • sensitive information - such as private voice recordings.
    • copyrighted material - such as copyrighted music or audio from movies and TV shows.

    An app's audio capturing policy can be set either for all audio or for each individual audio player.


    Disallowing capture of all audio by third party apps

    To disallow capture of all audio by third party apps you can do either of the following:

    Add the following to your AndroidManifest.xml <application

    ...

    android:allowAudioPlaybackCapture="false"/>

    Programmatically disable capture by running the following code prior to playing audio AudioManager.setAllowedCapturePolicy(ALLOW_CAPTURE_BY_SYSTEM)


    Disallowing capture on a per player basis by third party apps

    To disallow capture for an individual player you can set the capture policy for the audio player when it is built by calling:

    AudioAttributes.Builder.setAllowedCapturePolicy(ALLOW_CAPTURE_BY_SYSTEM)
    

    This approach may be useful if your app plays content with differing licenses. For example, both copyrighted and royalty-free content.


    Disallowing capture by system apps and components

    By default system apps and components are allowed to capture an app's audio if its usage is MEDIA, GAME and UNKNOWN, as this enables important accessibility use cases, such as live captioning.

    In rare cases where a developer wishes to disallow audio capture for system apps as well they can do so in a similar way to the approach for third party apps. Note that this will also disallow capture by third party apps.


    Disallowing capture of all audio

    This can only be done programmatically by running the following code before any audio is played:

    AudioManager.setAllowedCapturePolicy(ALLOW_CAPTURE_BY_NONE)
    


    Disallowing capture on a per player basis

    To disallow capture for an individual player you can set the capture policy for the audio player when it is built:

    AudioAttributes.Builder.setAllowedCapturePolicy(ALLOW_CAPTURE_BY_NONE)
    


    What next?

    If your app is targeting API 28 or below and you would like to enable audio capture add android:allowAudioPlaybackCapture="true" to your app's manifest.xml.

    If you would like to disallow some or all of your audio from being captured then update your app according to the instructions above.

    For more information check out the Audio Playback Capture API documentation.

    Indie Games Showcase from Google Play – meet the winners!

    Posted by Patricia Correa, Director, Developer Marketing

    We just wrapped up the Indie Games Showcase in Europe, Japan & South Korea! Back in March we started our search for some of the newest and most creative indie titles from these regions. The search culminated last week with the celebration of indie developers at events in London, Tokyo, and Seoul, and the selection of the winners from our finalists. Developers from 12 countries traveled to the events and showcased their games to the audience of gamers, industry experts, YouTube creators, and journalists.

    The games were on show to the public, who spent several hours trying out their games and voting for their favourites, alongside the Google Play team. The top 10 finalists were then selected, and went on to pitch their games, and compete for big prizes in front of the jury.

    collage of event pictures

    Now, we are happy to announce the winners from each region! They will be returning home with a prize package that includes promotions on the Google Play Store, consultations with Google teams, Google hardware, and more.

    We also want to take this opportunity to congratulate all the other finalists and developers who entered the competition this year. We are impressed by your creativity and passion, and hope you will continue to create amazing experiences for players worldwide.

    European illustration with Eiffel Tower and Matryoshka dolls

    Europe

    logos for the Europe top 3

    G30 - A Memory Maze by Ivan Kovalov (Russia)

    Ordia by Loju (United Kingdom)

    Photographs by EightyEight Games (United Kingdom)


    The other finalists as selected by audience and Google Play votes were:

    logos for the European top 10

    #DRIVE by Pixel Perfect Dude (Poland)

    Fly THIS! By Northplay (Denmark)

    Golf Peaks by Afterburn (Poland)

    Rest in Pieces by Itatake (Sweden)

    see/saw by Kamibox (Germany)

    STAP by Overhead Game Studio (United Kingdom)

    Tesla vs. Lovecraft by 10tons (Finland)

    mt.Fuji and other Japanese emblems

    Japan

    logos for the Japan top 3

    Infection - 感染 - by CanvasSoft

    MeltLand by 個人

    Bear's Restaurant by 個人


    The other finalists as selected by audience and Google Play votes were:

    logos for the Japan top 10

    Lunch Time Fish by SoftFunk HULABREAKS

    ReversEstory by 個人

    Kamiori - カミオリ by TeamOrigami

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

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

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

    Persephone by Momo-pi

    Korean space needle and temple

    South Korea

    logos for the South Korea top 3

    ROOMS: The Toymaker's Mansion by HandMade Game

    Seoul2033: Backer by Banjiha Games

    Cartoon Craft by Studio NAP


    The other finalists as selected by audience and Google Play votes were:

    logos for the South Korea top 10

    Hexonia by Togglegear

    Hexagon Dungeon by Bleor Games

    7Days - Decide your story by Buff Studio

    WhamBam Warriors by DrukHigh

    Onslot Car by Wondersquad

    Maze Cube by IAMABOY

    언노운 나이츠 by teamarex

    How useful did you find this blog post?

    Advanced in-app billing: handling alternative purchase flows

    Posted by Oscar Rodriguez, Developer Advocate

    When designing and developing an app or game, at some point you may ask yourself if you want to monetize it.

    If you choose to do so by selling products via Google Play, you will most likely have a store screen that shows available items for sale, and use the Google Play Billing Library to display dialogs that allow your users to complete their purchase.

    While there is a more detailed explanation in the documentation and in the Billing Library TrivialDrive samples, the general flow is as follows:

    1. Call the launchBillingFlow() method from the UI thread to launch the Google Play purchase dialog.
    2. If the purchase was successful, Google Play calls the onPurchasesUpdated() method to deliver the result of the purchase operation.
    3. If your app has a server, we strongly recommend that you verify the purchase from your server by using the Subscriptions and In-App Purchases API.
    4. Acknowledge the purchase either with consumeAsync() for consumable items or with acknowledgePurchase() for non-consumable items.
    5. Finally, grant entitlement to the purchased item inside the app.

    If your app is still using the Google Play Billing AIDL API, it is also possible to perform the same task. Keep in mind that the AIDL API is now deprecated, so we strongly recommend you migrate to the Google Play Billing Library as soon as possible.

    If you are using the AIDL API, the flow is very similar:

    1. Send a getBuyIntent() or getBuyIntentExtraParams() request to specify the item to purchase, and then call startIntentSenderForResult() to launch the Google Play purchase dialog.
    2. When the purchase dialog finishes, Google Play sends a response Intent to your onActivityResult() method, where you can verify if the purchase was successful.
    3. If your app has a server, we strongly recommend that you verify the purchase from your server by using the Subscriptions and In-App Purchases API.
    4. If the purchase was successful, call the getPurchases() method to retrieve a list of owned items that are still not consumed. For consumable items, call the consumePurchase() method to make the item available for purchase again.
    5. Finally, grant entitlement to the purchased item inside the app.

    Nevertheless, just implementing the above mentioned flow is not enough to correctly handle all types of purchases. There are two main cases in which purchases will not be correctly handled by this flow.

    The first case happens when the purchase flow is interrupted before it finishes. The app may have crashed, the user may have killed the app, or the user’s Internet connection may have been lost. In any case, it is possible for the app not to have delivered the item to the user even though Google Play has already processed the payment. In this case, the item is in limbo, because Google Play will not allow an item to be re-purchased until it is consumed, but the app or game won’t consume the item outside of the flow mentioned above.

    The second case happens during alternative purchase flows, such as in-app promotions, the recently announced out-of-app subscription surfaces, promo codes for subscriptions, or other promotions in collaboration with Google. In these cases, a user gets an item directly on the Play Store app, while the target app or game may be paused, not running, or even not installed.

    For these cases, the Google Play Billing Library and the Google Play Billing AIDL API offer a mechanism to detect purchases that are not acknowledged or consumed.

    When using the Google Play Billing API, do the following:

    1. In your app’s onResume() callback, call the queryPurchases() method to retrieve a list of items, so you can determine which ones are unacknowledged.
    2. If your app has a server, we strongly recommend that you verify the purchase from your server by using the Subscriptions and In-App Purchases API.
    3. If there are owned but unacknowledged items, acknowledge the purchase either with consumeAsync() for consumable items or with acknowledgePurchase() for non-consumable items.
    4. Grant entitlement to the purchased item inside the app.

    For the Google Play Billing AIDL API, do the following:

    1. In your app’s onResume() callback, call the getPurchases() method to retrieve a list of owned items that are still not consumed.
    2. If your app has a server, we strongly recommend that you verify the purchase from your server by using the Subscriptions and In-App Purchases API.
    3. For consumable items, call the consumePurchase() method to make the item available for purchase again.
    4. Finally, grant entitlement to the purchased item inside the app.

    In either case, when you detect and process an unconsumed item in this manner, users will expect the app or game to communicate about it. We suggest that you display a dialog, message box, or notification that tells the user that they have successfully received their item.

    Keep in mind that your app’s onResume() callback will be called when its process is started, as well as when it is brought to the foreground, regardless of which screen the app or game was in before it was paused. For example, a game with a home screen, a store screen, and a game screen might get its onResume() called from any of those screens. For an optimal user experience, we suggest you make it so your app or game handles unacknowledged or unconsumed items regardless of the screen you display when onResume() gets called. Thorough testing of this process in each screen is crucial to deliver a great user experience.

    Finally, there is one more case your app must handle: when a user acquires an item from the Play Store app, and both the Play Store app and your app are visible at the same time with multi-window mode.

    To support this scenario with the Google Play Billing Library, do the following:

    1. Google Play calls the onPurchasesUpdated() method to notify your app that there is a new pending item.
    2. If your app has a server, we strongly recommend that you verify the purchase from your server by using the Subscriptions and In-App Purchases API.
    3. Acknowledge the purchase either with consumeAsync() for consumable items or with acknowledgePurchase() for non-consumable items.
    4. Finally, grant entitlement to the purchased item inside the app.

    For the Google Play Billing AIDL API, do the following:

    1. In your app’s onResume() callback, register a PurchasesUpdatedListener to receive the com.android.vending.billing.PURCHASES_UPDATED intent. Also, in your app’s onPause() callback, unregister the listener.
    2. If your app has a server, we strongly recommend that you verify the purchase from your server by using the Subscriptions and In-App Purchases API.
    3. Google Play calls your listener to notify your app that there is a new pending item. Inside it, call the getPurchases() method to retrieve a list of owned items that are still not consumed. For consumable items, call the consumePurchase() method to make the item available for purchase again.
    4. Finally, grant entitlement to the purchased item inside the app.

    Just as before, you should display a dialog, message box, or notification that tells the user that they have successfully received their item.

    If you follow these steps, your app or game will be better prepared to robustly handle purchase flow interruptions and alternative purchase flows.

    Moving Android Studio and Android Emulator to 64-bit versions

    Posted by Sam Lin, Product Manager, Android

    With Project Marble, the Android Studio team focused our efforts on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. Performance is an underlying tenant to delivering a high quality IDE. To this end, we are sharpening our product focus and we will only support 64-bit operating systems going forward. Using Android Studio with an 64-bit operating systems enables efficient access to memory for both the IDE and the Android Emulator, and overall leads to a better development experience. While this change will not affect most Android Studio users, this change does have an impact if you use 32-bit versions of Microsoft® Windows®. To aid in this transition for those developers using 32-bit versions of Microsoft Windows, we want to give you details on the upcoming depreciation timeline plus steps to take to be ready for this upcoming change.

    Timeline

    To minimize the impact of this change towards exclusively supporting 64-bit operating systems, we will first deprecate the 32-bit version. During the depreciation phase, both Android Studio and the Android Emulator will continue to work but the products will not receive new feature updates. During this transition period you can still download the product from the Android Studio web site. After one year, we will officially end product support and will remove the 32-bit product version download links. Note, if you have the 32-bit version of Android Studio previously installed during this period then the product should continue to work, but we will not provide a link for you to re-download the product. The exact dates for the depreciation and end-of-support period are in the table below:

    Supported 32-bit Product Version Deprecation from End of Support on
    Android Studio IDE 3.6 December 31, 2019 December 31, 2020
    Android Emulator 28.0.25 Jun 30, 2019 December 31, 2020

    Advantages of a 64-bit development environment

    There are a few advantages to using a 64-bit version of Android Studio, which include:

    • Performance - The IDE can perform better because it can access more than 4GB of memory. The increase in memory especially provides a better experience when you are working on a large project.
    • 64-bit App Support - You can build both 32-bit and 64-bit versions of apps if your app uses C/C++ native code. Testing on both architectures can help you to get ready for the 64-bit requirement on Google Play which starts on August 1st, 2019.
    • Testing on Emulators - Both the 32-bit and 64-bit Android Emulator system images are supported by the 64-bit version of the Android Emulator. This flexibility makes it easier to test your app in different Android environments with one development machine.

    Next steps

    To recap, before ending support for the 32-bit version of Android Studio, we want to inform you in advance, provide guidance, and allow for a one-year lead time to help you migrate to a 64-bit operating system. You can still use 32-bit versions of Android Studio, but be mindful that these version will not receive future updates. Therefore, if you want to migrate we suggest you start planning early so that you can continue to get the latest product updates and take advantage of the performance improvements of a 64-bit development environment.

    Android Q Beta 4 and Final APIs!

    Posted by Dave Burke, VP of Engineering

    AndroidQ logo

    Last month at Google I/O we talked about what’s new for Android developers, from new features in Android Q to the latest in Kotlin and Jetpack.

    With Android Q, we highlighted three themes: innovation, security and privacy, and digital wellbeing. We want to help you take advantage of the latest new technology -- 5G, foldables, edge-to-edge screens, on-device machine learning, and more -- while making sure users' security, privacy, and wellbeing are always a top priority.

    We also talked about how we’re going increasingly Kotlin-first, and continuing to expand Jetpack with new libraries like CameraX, Jetpack Security and Jetpack Compose -- a modern reactive-style UI toolkit for Android that takes advantage of Kotlin. If you missed the livestream for the keynotes or tech sessions, make sure to check out the full playlist of Android and Play sessions.

    Today we’re releasing Beta 4 with the final Android Q APIs and official SDK -- the time is now to get your apps ready for the final release later in the summer!

    You can get Beta 4 today on Pixel devices by enrolling here. If you're already enrolled and received the Beta 3 on your Pixel device, you'll automatically get the update to Beta 4. Partners participating in the Android Q Beta program will also be updating their devices to Beta 4 over the coming weeks.

    To get started with Android Q Beta, visit developer.android.com/preview.

    What’s in Beta 4?

    The Beta 4 update includes the latest Android Q system images for Pixel and Android Emulator, along with the final Android Q developer APIs (API level 29), the official API 29 SDK, and updated build tools for Android Studio. Together, these give you everything you need to test your apps for compatibility with Android Q and build with Android Q features and APIs.

    To get started, download the official API 29 SDK and tools into the stable release of Android Studio 3.4, or for the latest Android Q support update to Android Studio 3.5 Beta. Then follow these instructions to configure your environment, and see the release notes for known issues.

    Make your apps compatible with Android Q!

    With the developer APIs finalized and release candidate builds coming soon, it’s critical for all Android developers to test their current apps for compatibility with Android Q. We recommend getting started as soon as possible.

    Just install your current app from Google Play onto an Android Q Beta device or emulator, then test. As you work through the flows, your app should run and look great and handle all of the Android Q behavior changes properly. Watch for impacts from privacy changes, gestural navigation, changes to dynamic linker paths for Bionic libraries, and others.

    Make sure that you test with the Android Q privacy features, such as the new location permissions, restrictions on background activity starts, changes to data and identifiers, and other key privacy features. See the privacy checklist to get started, and review the behavior changes doc for more areas to test.

    Android Developers YouTube channel UI on landscape mode.

    You can use the updated Android Emulator to test your apps for compatibility.

    If you plan to update your platform targeting to API 29, also make sure to test with scoped storage, location permission for wireless scans, and permission for fullscreen intents. You can read about other changes that could affect apps here.

    It's also important to test for uses of restricted non-SDK interfaces and move to public SDK or NDK equivalents instead. Watch for logcat warnings that highlight these accesses and use the StrictMode method detectNonSdkApiUsage() to catch them programmatically.

    Last, make sure to fully test the libraries and SDKs in your app to make sure they work as expected on Android Q and follow best practices for privacy, performance, UX, data handling, and permissions. If you find an issue, try updating to the latest version of the SDK, or reach out to the SDK developer for help. You can also report SDK compatibility issues here.

    When you’ve finished your testing and made any updates, we recommend publishing your compatible app right away. This lets Android Beta users test the app now, and helps you deliver a smooth transition to users as they update to Android Q.

    We realize that supporting these changes is an investment for you too, and we're working to minimize the impact on your apps and be responsive to your input as we move toward the final release in the coming months.

    Enhance your app with Android Q features and APIs

    When you're ready, dive into Android Q and learn about the new features and APIs that you can use in your apps. Android Q features can help you engage users, give them more control and security, and even improve your app's performance.

    mobile device notification window

    Android Q provides system-suggested replies and actions in notifications.

    For example, you can deliver seamless, edge-to-edge experiences on today’s innovative devices by optimizing for foldables and supporting gestural navigation in your app. To engage more users, try supporting Dark Theme, suggested replies and actions in notifications, sharing shortcuts, and settings panels.

    Google Maps app closes to display home screen with ocean aerial image

    Gestural navigation lets you offer an edge-to-edge experience in your apps.

    If your app manages IoT devices over Wi-Fi, try the new network connection APIs for functions like configuring, downloading, or printing. If your app manages Wi-Fi internet connections, try the network suggestion APIs as an easier way to surface preferred Wi-Fi networks, without needing to request location permission.

    If you use the camera, learn about dynamic depth format. For media, you can use AV1 for video streaming and HDR10+ for high dynamic range video. For speech and music streaming, you can use Opus encoding, and for musicians, a native MIDI API is available.

    Dynamic Depth lets you offer specialized blurs and bokeh options in your app.

    To support captioning or gameplay recording, enable audio playback capture -- it’s a great way to reach more users and get your app noticed. If your app uses power intensively, try using the new thermal API to optimize app performance based on device temperature.

    BiometricPrompt is now the preferred way to support fingerprint auth on modern devices, so all developers using fingerprint or other biometric auth should move to using this API as soon as possible. To make the transition easy, use the backwards-compatible BiometricPrompt API that we’re providing in the AndroidX library. Android Q supports both standard and passive (no confirmation, for face and other passive modes) auth flows.

    These are just a few of the many new features and APIs in Android Q -- to see them all, visit the Android Q Beta site for developers.

    Publish your app updates to Google Play

    Today with Android Q Beta 4 we’re also opening up publishing on Google Play to apps that are compiled against, or optionally targeting, API 29. This means you can now push your updates to users now through Google Play to test your app’s compatibility, including on devices running Android Q Beta 4.

    How do I get Beta 4?

    It’s easy! Just enroll any supported Pixel device here to get the update over-the-air. If you're already enrolled, you'll receive the update soon and no action is needed on your part. Downloadable system images are also available here. Partners that are participating in the Android Q Beta program will be updating their devices over the coming weeks. See android.com/beta for details.

    For even broader testing on supported devices, you can also get Android GSI images, and if you don’t have a device you can test on the Android Emulator.

    As always, your input is critical, so please continue to let us know what you think. You can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues. You've shared great feedback with us so far and we're working to integrate as much of it as possible in the next Beta release.

    We're looking forward to seeing your apps on Android Q!