Tag Archives: Featured

Google Play Billing Library 1.0 released

Posted by Neto Marin, Developer Advocate

In June we announced the developer preview for a new Google Play Billing Library. Today, we are pleased to announce the official release of the Play Billing Library 1.0. This library simplifies the development process for Google Play Billing, allowing you to focus your efforts on your app.

Thank you for your valuable feedback and suggestions that helped us reach the 1.0 release. Watch the video below for a quick overview of the library's features.

Before you start

With Play Billing, you can receive payments from users around the world via a payment system they trust and you can take advantage of features and reports in the Play Console to manage and earn more revenue.

If you have never implemented in-app billing in your apps, or you want to know what you can offer using Play Billing Library, read the In-app Billing Overview to familiarize yourself with concepts and terminology that make it easier for you to implement In-app Billing using the Play Billing Library.

Getting started

Play Billing Library is available through Maven repository, and adding Play Billing Library to your project is simple as adding the following dependency into your app's build.gradle file:

dependencies {
    ...
    compile 'com.android.billingclient:billing:1.0'
}

The Play Billing Library 1.0 automatically adds the com.android.vending.BILLING permission to your APK. This means you no longer need to manually include it in your application module's manifest.

BillingClient and PurchasesUpdatedListener

These classes are the most important pieces when integrating the library into your Android app. The BillingClient is the bridge between your app and Google Play. You will use it for listing available products, starting the billing flow for in-app products or subscriptions (i.e. opening the payment interface), getting user purchases, and creating or modifying subscriptions.

When creating your BillingClient instance, you'll need to set a PurchasesUpdatedListener. This allows your app to receive updates from the In-app Billing API, including transaction results after the billing flow, as well as purchases completed outside of your app, e.g. user redeemed a Promo Code or bought a product on another device.

The following code demonstrates how you could override the )">onPurchasesUpdated() method of your PurchasesUpdatedListener:

@Override
void onPurchasesUpdated(@BillingResponse int responseCode,
        List<Purchase> purchases) {
    if (responseCode == BillingResponse.OK
            && purchases != null) {
        for (Purchase purchase : purchases) {
            handlePurchase(purchase);
        }
    } else if (responseCode == BillingResponse.USER_CANCELED) {
        // Handle an error caused by a user canceling the purchase flow.
    } else {
        // Handle any other error codes.
    }
}

You can implement the PurchasesUpdatedListener in your Activity or in any other class you want, according to your app's architecture. And here's the code for creating the BillingClient instance, and setting the PurchasesUpdatedListener:

mBillingClient = BillingClient.newBuilder(mContext)
                              .setListener(mPurchasesUpdatedListener)
                              .build();

Listing and selling products

To sell products in your app, first, you need to add them using the Play Console. For more details about how to add in-app products see the page Administering In-app Billing.

Attention: If this is a brand new app, before adding the products you must publish it to the alpha or beta distribution channel. For more information, see Draft Apps are No Longer Supported.

To get a list of product details with prices for current user, call , com.android.billingclient.api.SkuDetailsResponseListener)">querySkuDetailsAsync(). You must also specify a listener which implements the SkuDetailsResponseListener interface. You can then override the onSkuDetailsResponse() method which notifies the listener when the query finishes, as illustrated by the following sample code:

List<String> skuList = new ArrayList<> ();
skuList.add("premiumUpgrade");
skuList.add("gas");
mBillingClient.querySkuDetailsAsync(SkuType.INAPP , skuList,
    new SkuDetailsResponseListener() {
        @Override
        public void onSkuDetailsResponse(SkuDetailsResult result) {
            // Process the result.
        }
    })

After the user chooses a product to buy, you'll need to start the billing flow and handle the transaction result. To start a purchase request from your app, call the launchBillingFlow() method on the Play Billing Library client. You must call the launchBillingFlow() method (and all the other methods from BillingClient) from the UI thread.

The launchBillingFlow() method needs BillingFlowParams object that contains relevant data for completing the purchase, such as the product ID of the item to purchase and the product type (in this case, SkuType.INAPP). To get an instance of BillingFlowParams, construct it with newBuilder() method:

BillingFlowParams.Builder builder = BillingFlowParams
                                       .newBuilder()
                                       .setSku(skuId).setType(SkuType.INAPP);
int responseCode = mBillingClient.launchBillingFlow(builder.build());

As we mentioned earlier, the transaction result will be sent to the )">onPurchasesUpdated() method. For details how to process the data received on )">onPurchasesUpdated() and how to handle a purchase, check the section Purchase an item in our training guide.

Consuming products

By default, all in-app products are managed. It means that Google Play tracks the product ownership and doesn't allow to buy multiple times. To be able to buy a product again, you must consume the product before it becomes available again.

It's common to implement consumption for in-app products which users may want to purchase multiple times, such as in-game currency or equipment. You typically don't want to implement consumption for in-app products that user purchases once and provide a permanent effect, such as a premium upgrade.

To consume a product, call the consumeAsync() method on the Play Billing Library client and pass in the purchaseToken String value returned when you made the purchase. The consumption result is returned via onConsumeResponse() method of the ConsumeResponseListener interface, that you must override to handle the consumption result.

The following example illustrates consuming a product using the associated purchaseToken:

ConsumeResponseListener listener = new ConsumeResponseListener() {
    @Override
    public void onConsumeResponse(@BillingResponse int responseCode, 
                                  String outToken) {
        if (responseCode == BillingResponse.OK) {
            // Handle the success of the consume operation.
            // For example, increase the number of player's coins,
            // that provide temporary benefits
        }
    }
};
mBillingClient.consumeAsync(purchaseToken, listener);

Sample updated: Trivial Drive V2

With a new library comes a refreshed sample! To help you to understand how to implement in-app billing in your app using the new Play Billing Library, we've rewritten the Trivial Drive sample from the ground up.

Since we released Trivial Drive back in 2013, many new features, devices, and platforms have been added to the Android ecosystem. To reflect this evolution, the Trivial Drive v2 sample now runs on Android TV and Android Wear.

What's next?

Before integrating within your app, you can try the Play Billing Library with the codelab published during Google I/O 2017: Buy and Subscribe: Monetize your app on Google Play.

In this codelab, you will start with a simplified version of Trivial Drive V2 that lets users to "drive" and then you will add in-app billing to it. You'll learn how to integrate purchases and subscriptions as well as the best practices for developing reliable apps that handle purchases.

Get more info on the Play Billing Library and the official reference for classes and methods documentation on the Android Developers website. For a step-by-step guide to implementing the Play Billing Library in your project, visit the library's training class.

We still want your feedback

If you have issues or questions, file a bug report on the Google Issue Tracker, and for issues and suggestions on the sample (like a bug or a new feature), contact us on the Trivial Drive issues page.

For technical questions on implementation, library usage, and best practices, you can use the tags google-play and play-billing-library on StackOverflow or visit the communities on our Google+ page.

Helping indie developers get discovered on Google Play

Posted by Adriana Puchianu, Google Play Developer Marketing

There are increasing growth opportunities for indie game developers, but being one can still feel daunting in today's crowded gaming industry. We've been working hard to help indie developers find an audience and to recognize them for their creativity and innovation. We launched the Indie Corner as a destination for exciting new games along with longstanding indie masterpieces. Since launch, more than 380 games have been featured. Earlier this year, we launched Android Excellence which showcases apps and games that deliver incredible user experiences on Android, while providing another opportunity to be discovered on Google Play.

We've also held several indie games contests across the globe, giving indies the chance to showcase their games and find new audiences. In April, we selected the winner of the second Indie Games Festival in South Korea and we recently announced the top 20 finalists of this year's San Francisco event. Come and see the finalists in person on September 23rd, it's free to attend and open to the public. Soon we'll be bringing back the second Indie Games Contest in Europe too.

Watch François Alliot, the developer of Reigns, an indie game showcased in Android Excellence and the winner of last year's Indie Games Contest in Europe, share how he built a successful games business in the video below.

And, finally, check out our recent Q&A with Spry Fox, makers of the popular game Alphabear, to learn more about what it’s like to be an indie game developer.

How useful did you find this blogpost?

Optimize your Android apps for Chromebooks

Posted by Cheryl Lindo Jones, Mobile App Solutions Consultant, Google Play

As more Chromebooks are enabled with Google Play, now is a great time to optimize your Android app for Chromebooks to reach a larger audience. The changes made to optimize for large screens will benefit mobile devices that are able to project to desktop monitors, like the Samsung Galaxy S8. The current list of Chromebooks that can access the Play Store continues to grow.

There are several differences to consider when optimizing your Android app or game for Chromebooks:

  • Larger screen sizes and higher resolutions
  • Multi-window and resizable-window support
  • Different hardware input methods: keyboard, trackpad, mouse, stylus
  • Convertible Chromebooks enabling use in laptop and tablet modes

Chromebook users can change screen resolutions, switch between various input methods, and convert from laptop to tablet mode at any time, so Android apps and games should handle all of these situations gracefully.

Discoverability on Google Play

If Android apps or games require hardware not available in a Chromebook (like cellular capability or GPS), those titles will not show up on Google Play for Chromebook users, similar to Play on Android tablets. Developers should maximize discoverability on Google Play by doing the following:

Set requested permissions and uses-features in the manifest to ensure compatibility with Chromebooks. Not all Chromebooks will have touchscreens, GPS, or rear-facing cameras which are typical for smartphones. Update the manifest so that sensors and hardware not commonly found on Chromebooks are not required. Example:

<uses-feature android:name="android.hardware.touchscreen"
    android:required="false" />

Additionally, to educate Chromebook users on any Chrome OS-specific features that have been implemented, for example supporting additional input methods like keyboard, trackpad, and stylus, or supporting large, high-resolution screens with a responsive layout, developers should update the app description on Google Play. It would also be useful to provide screenshots showcasing how well the app or game works on the larger screen, or how the title works on a Chromebook specifically.

Optimizing functionality

While most apps and games already work fairly well on Chromebooks without any changes, it is still a good idea to explore how to provide an optimized, consistent experience for Chromebook users.

Large screens and resizable windows

Chromebook users will be more inclined to multitask, opening multiple apps and/or games at once, taking advantage of the screen size, and operating in a manner consistent with a desktop or laptop form factor. Unlike on Android phones, they can also change the screen resolution to fit more onto the screen, or enlarge the fonts, UI, and graphics, if needed. Multi-window support and fully resizable window support are key for this usage. Graphics, fonts, layout, and touch targets should be adjusted accordingly as the screen resolution and orientation changes.

It is also important to note that just because an app or game window is not in focus, it does not mean that it is not visible. For example, if a video app is open in an inactive window, it should continue to play content "in the background" because it could still be visible along side another app window. To fully support multi-window usage in this case, pause video in onStop(), and resume in onStart().

Targeting Android N (API level 24 and higher) will signal to the Chrome OS window manager that compatibility restrictions should not be used. This allows for more flexibility and control on the developer's part for supporting window resizing.

The system will handle window management best if Android N is targeted, but for pre-N API support, windows can be toggled between either a default size selected at app launch, or a full-screen mode with either the window bar visible, or with window UI hidden in immersive full-screen mode.

When handling different windowing modes, it is important to know that the window area for an app or game will be offset by the presence or absence of the window control bar. The app should not assume that the activity will always be at (0,0) in the window. Adjust the layout and touch targets accordingly. It is somewhat common to see apps or games become unresponsive after a window resize or orientation change because it did not gracefully handle the presence of the window control bar, or the higher resolution settings of a Chromebook screen.

Orientation support

Because of the laptop form-factor, Chromebook users expect landscape to be the default orientation for apps on Chromebooks. However, Android apps often assume that portrait is the default orientation to support, due to the typical way users interact with their smartphones. To offer flexibility to users, it is highly recommended to support both portrait and landscape orientations. Some Chromebooks are convertible, so users can change between laptop and tablet modes at will, switching between portrait and landscape orientation, according to what feels comfortable for a given use case.

Most importantly, if possible, do not require a restart if the orientation or window size changes. If a user is in the process of filling out a form, creating or editing some content, or in the middle of a level in a game and loses progress because of an window change -- intentional or not -- it would be a poor user experience.

Developers can monitor window configuration changes using onConfigurationChanged() and dynamically handle those changes by adding this line to the activity's manifest:

android:configChanges="screenSize|smallestScreenSize|orientation|screenLayout".

If it is absolutely necessary to require a restart upon changes to the window, at least restore state by using the onSaveInstanceState() method so that work or state is not lost.

Additionally, it is important to be consistent with the app's orientation as the user is navigating through activities. Currently, the system forces Android apps to follow the orientation of the root activity to help maintain consistency. However, this may result in a situation where, perhaps an app starts out in landscape orientation, and a login screen normally laid out for portrait orientation pops up, and now does not look optimized due to an unresponsive layout. Also, it is still possible to have a case where a springboard activity starts out in an orientation that is different from the primary orientation of the app. Please keep these possible scenarios in mind when designing the layout for activities.

Finally, developers should be aware of the differences in handling cameras and orientation on Chromebooks. Obviously, Android phones have front-facing and rear-facing cameras that are situated at the top of a portrait-oriented screen. The front-facing cameras on Chromebooks are situated at the top of a landscape-oriented screen. Many Chromebooks do not have rear-facing cameras. If an app requires a camera, it would be best to use android.hardware.camera.any to access the front-facing camera, if a rear-facing one is not available. Again, developers should target Android N and, if possible allow the app to be resizable so that the system can take care of properly orienting the camera previews.

Supporting multiple input methods

Chromebook users are used to interacting with webpages and apps using a keyboard and trackpad. Effectively supporting these two input methods for an Android app means:

  • Supporting hotkeys for commands that a desktop app user may be familiar with
  • Using arrow and tab keys and a trackpad to navigate an activity
  • Allowing hover and opening context menus
  • Supporting other trackpad gestures to enhance productivity in desktop/laptop mode

Something as simple as hitting return to send text in a messaging app, or allowing a user to navigate fields by hitting the tab key will make an app feel more efficient and cohesive on a Chromebook.

While there is a compatibility mode for Chrome OS to emulate touchscreen scrolling and other touch events, it would be best to optimize an Android app by declaring

<uses-feature
    android:name="android.hardware.type.pc"
    android:required="false" />

in the manifest to disable compatibility mode in order to further define custom support for keyboard and trackpad.

Similarly, the system can guess at giving focus to the right views when navigating via the tab or arrow keys on a keyboard. But for best performance, specify how keyboard navigation should be handled in the activity manifest using the android:nextFocusForward attribute for tab navigation, and android:nextFocusUp, android:nextFocusDown, android:nextFocusLeft, android:nextFocusRight attributes for arrow key navigation.

On a related note, some Chromebooks do not have touchscreens, therefore well-optimized Android apps on Chrome should not assume the user can perform typical swipe and multi-touch tap gestures to navigate through an app or game. If primary functionality cannot be performed using only a keyboard or trackpad, the user experience will be severely impacted on non-touchscreen Chromebooks. Try to "translate" existing touchscreen tap and swipe gestures into something that can be easily done on a trackpad or using the keyboard.

Newer Chromebooks are gaining stylus support, allowing for richer interactions for sketchbook and note-taking apps, photo editors, games, and more. Developers are encouraged to use available APIs to support pressure-sensitivity, tilt, and eraser inputs. To enable users to comfortably rest their hands on the screen while writing, drawing, or playing games with the stylus, support palm rejection. The system will attempt to ignore input from a user's resting palm, but in case such erroneous touch events are registered, Android apps should gracefully handle ACTION_CANCEL events to erase the erroneous inputs.

By supporting all of these additional input methods, users will be able to take full advantage of the laptop mode for Chromebooks to work more efficiently, or to be more creative.

Learn more

While a lot was covered in this article, we have additional resources for you to learn more about optimizing their apps and games for Chromebooks. Read our Medium post with tips to get your app running great on Chromebooks and watch our session at Google I/O 2017, Android Apps for Chromebooks and Large Screen Devices. There is also training material on the Android developers website for building apps for Chrome OS. If you have any questions, reach out to the Android developer community and post with the hashtag #AndroidAppsOnChromeOS.

How useful did you find this blogpost?

Android Developer Story: Zalando increases installs and revenue by focusing on app quality

Posted by Adriana Puchianu

Based in Berlin, Zalando is Europe's leading online fashion platform. With more than 70% of its traffic now coming from mobile, the company has invested a lot in improving the quality of its app to provide a good user experience. Investing in bridging the online and the offline worlds, as well as providing a seamless cross-platform experience, has had positive results on their user engagement and revenue. Using features like A/B testing, the pre-launch report and the new release dashboard from the Google Play Console, Zalando saw a 6% increase in installs and a 15% increase in the users' lifetime value.

Watch Rushil Dave, Senior Product Specialist and Meritxell Rivera, Android Developer discuss how the company has improved user experience and key revenue and engagement metrics by investing in app quality for their Zalando app.

How useful did you find this blogpost?

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

Posted by Kacey Fahey, Developer Marketing, Google Play

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

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

Meet the finalists

7 Pin Pool
SPG Inc
Age of Rivals
Roboto Games
Brave Hand
Heart Shaped Games
(game not yet released)
Covens
Raincrow Studios, LLC
Crashy Cars
pixelbizarre
Dokudo
Sense of Wonder
Flipping Legend
Hiding Spot
Gladiator Rising
Happii Gamer Studio
Jigsaw Story
Happy Square Studio Inc
Loteria Latin Bingo
Gorilla Bean Games
Maruta Escape
Busan Sanai Games
(game not yet released)
NoStranger
Black Vein Productions
Slayaway Camp
Blue Wizard Digital
Space Tunnel
Spacewave Studios
Star Vikings Forever
Akupara Games
Storm Wars
Zom.bio
Tiny Bubbles
Pine Street Codeworks
(game not yet released)
Topsoil
Nico Prins

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

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

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

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

How useful did you find this blogpost?

How to improve app design for Wear 2.0

Posted by Steven Tepper, App Quality Consultant, Google Play

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

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

Navigation

  1. Use the WearableDrawerLayout navigation drawer for simple and infrequent navigation: Simple navigation includes tasks such as accessing app settings, switching users or logging out. You can implement this on Wear 2.0 to switch between different views or sections of the app via a swipe down from the top of the screen, or an action drawer can be set up for context-specific actions when swiping up from the bottom of the screen.
  2. Present a navigation drawer as a single-page drawer to enable users to navigate views quickly: A navigation drawer can be presented as either a multi-page or single-page drawer. The single-page layout is useful for when the user is expected to navigate quickly between 7 or less views of the app. Remember that if the app is using a single-page drawer, the iconography should be clear and understandable as there will not be any sort of text labeling in this layout. If there are more than 7 views to navigate to or the views are not easily represented by icons, you should instead use the multi-page drawer layout.
  3. Use multiple app launchers if your app has two or three discrete functions: For example, if your app supports both activity tracking—with various options, actions, and views—and historical analysis and management of tracked activities, you can use multiple app launchers to handle these tasks. Alternatively, if your app has a simple home screen, these features could be placed in line, at the bottom of the screen.
  4. Use peeking at the top of the action drawer to provide quick access to the primary action: If there is no primary action associated with the view, override the default behavior and force an overflow button to peek instead, exposing all actions at the bottom of a view, when tapped.

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

Notifications

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

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

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

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

To learn more about adding wearable features to notifications.

Complications

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

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

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

Standalone functionality on Wear devices

  1. Make sure your app is able to handle itself if there is no companion app installed when using the android.hardware.type.watch hardware feature flag: Using this feature enables your app to become searchable and installable directly on Wear devices without needing to install a companion phone app, so ensure your app can handle itself to avoid a confusing or broken user experience.
  2. Ensure your wearable app doesn't rely on the phone app for sign-in/authentication or primary functionality: When requiring complicated input for authentication (for example, password entry) your wearable app can point to the companion phone, but should rely on web UI for account/password entry rather than an app.
  3. Where a companion app must be present on a phone to support your app in some other way, the app should use the CapabilityApi: This should be used to properly direct users to the Play Store listing on their companion device to install the missing app. Otherwise, the app should function on its own, using the Wear built-in Wi-Fi, GPS, or other connectivity functions.
  4. Include wording about any companion app requirements or briefly mention how your Wear app should function within the Play Store listing description: This will help set expectations and guide users to install the correct apps for the best possible experience.
  5. Incorporate the com.google.android.wearable.standalone flag in the manifest if your Wearable app can function without any phone companion interaction: This flag indicates that the wearable app can be installed and will fully function when not paired to an Android or iOS companion phone.

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

How useful did you find this blogpost?

Start on Android and succeed on Google Play

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

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

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

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

Start on Android

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

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

We are just getting started

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

  • Socratic - A Spark Capital backed company that allows students to solve math problems by snapping a photo with their camera and using computer vision to return relevant answers and related concepts and video.
  • Astro - A Redpoint portfolio company that layers AI on top of your email to help intelligently manage your inbox.
  • Snaky Snake -
  • Peanut - A Tinder-like app for connecting moms, funded by NEA and Felix Capital.
  • Gyroscope - A startup working on an "operating system for the human body".
  • Empower - An exciting new money management app backed by Sequoia Capital, coming soon to Android.

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

Get in touch with us

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

How useful did you find this blogpost?

Introducing Android 8.0 Oreo

Posted By: Dave Burke, VP of Engineering

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

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

What's in Android Oreo?

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

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

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

  • System optimizations: We worked across the system to help apps run faster and smoother -- for example, in the runtime we added a new concurrent compacting garbage collection, code locality, and more.
  • Background limits: We added new limits on background location and wi-fi scans and changes in the way apps run in the background. These boundaries prevent unintentional overuse of battery and memory and apply to all apps -- make sure you understand and account for these in your apps.
  • Complementary Android Vitals dashboards and IDE profilers: In the Play Console you can now see aggregate data about your app to help you pinpoint common issues - excessive crash rate, ANR rate, frozen frames, slow rendering, excessive wakeups, and more. You'll also find new performance profilers in Android Studio 3.0, and new instrumentation in the platform.

In Android 8.0 your app can directly pin a specific app shortcut in the launcher to drive engagement (left). Notification dots keep users active in your app and let them jump directly to the app's core functions (right).

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

  • Autosizing textview: Use autosizing TextView to automatically fill a TextView with text, regardless of the amount. You can create an array of preset text sizes, or set min and max sizes with a step granularity, and the text will grow and shrink to fill the available TextView space.
  • Fonts in XML: Fonts are now a fully supported resource type. You can now use fonts in XML layouts and define font families in XML.
  • Downloadable fonts and emoji: With downloadable fonts you can load fonts from a shared provider instead of including them in your APK. The provider and support library manage the download of fonts and shares them across apps. The same implementation also supports downloadable emoji, so you can get updated emoji without being limited to the emoji built into the device.
  • Adaptive icons: You can now create adaptive icons that the system displays in different shapes, based on a mask selected by a device manufacturer. The system also animates interactions with the icons, and uses them in the launcher, shortcuts, settings, sharing dialogs, and in the overview screen.

Adaptive icons display in a variety of shapes across different device models.
  • Shortcut pinning: App shortcuts and homescreen widgets are great for engaging users and now you can let users add and pin shortcuts and widgets to the launcher from within your app. There's also a new option to add a specialized activity to help users create shortcuts. The activity is complete with custom options and confirmation.
  • Wide-gamut color for apps: Imaging apps can now take full advantage of new devices that have a wide-gamut color capable display. To display wide gamut images, apps enable a flag in their manifest files (per activity) and load bitmaps with an embedded wide color profile (AdobeRGB, Pro Photo RGB, DCI-P3, etc.).
  • WebView enhancements: In Android Oreo, we've enabled WebView multiprocess mode by default and added an API to let your app handle errors and crashes. You can also opt in your app's WebView objects to verify URLs through Google Safe Browsing.
  • Java 8 Language APIs and runtime optimizations: Android now supports several new Java Language APIs, including the new java.time API. In addition, the Android Runtime is faster than ever before, with improvements of up to 2x on some application benchmarks.

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

Make sure your apps are ready

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

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

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

Speed your development with Android Studio

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

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

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

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

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

Publish your updates to Google Play

Google Play is open for apps compiled against or targeting API 26. When you're ready, you can publish your APK updates in your alpha, beta, or production channels.

Make sure that your updated app runs well on Android Oreo as well as older versions. We recommend using Google Play's beta testing feature to get early feedback from a small group of users, then do a staged rollout. We're looking forward to seeing your app updates!

What's next for Android Oreo?

We'll soon be closing the Developer Preview issue tracker, but please keep the feedback coming! You can file a new issue against Android 8.0 in the AOSP issue tracker.

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

500 million devices now supported for Android Instant Apps

Posted by Jonathan Karmel

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

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

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

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

How useful did you find this blogpost?

Android Instant Apps: Best practices for managing download size

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

Refactoring your codebase

The biggest binary size benefit comes from refactoring your app into multiple feature modules. Even if your current size and feature set don't require multiple features, we recommend designing for it, so you can quickly add more features in the future without affecting the binary size of existing features. We also highly recommend having a unified modular codebase to produce both installable and instant application binaries, as this will reduce the burden of maintaining separate projects and code and provide a cleaner project structure across both. Based on the experience of our early access partners, we believe this will have the largest impact to the binary size at download. However, it also requires the most investment.
To get to that end, you can start with a single (base) module and then refactor code by moving relevant portions to feature module(s). Note that you do not need to worry about the binary size while developing your instant app, as the size limit does not apply for locally built binaries. You can also publish your binary through the Play Developers Console to the Development track (special track for quick deployment of your instant app during development), where the size limit is 10MB. [1, 2] The 4MB restriction is applied once your binary graduate out of the Development track.
Each feature module can have one (or more) entry points – activities – that correspond to a given URL. When splitting a single code base into multiple modules, you will have different entry points for different features, and the platform will load the relevant feature as needed. Remember, the total binary to be downloaded for any given entry point should be under 4MB, so the combined size of any feature module and the base module must be below 4MB.
It is advised to define the feature–activity–entry point mappings first, and then structure the refactoring effort towards reducing the binary size for each entrypoint..
Also consider how your libraries are included. If a specific feature module requires certain libraries they should be included in the feature module only, instead of being added in the base APK. This will reduce the size of the base module. For example, let's say you have an application that depends on libraries X, Y, and Z. Initially, you may pack all the libraries in the base module by placing all the dependencies in the base gradle.build file. But if only the code in the feature module requires library Z, it makes sense to move that dependency from the base module to the feature module.This works as long as no other feature modules depend on the same library. If multiple feature modules use the same library it definitely makes sense to keep it in the base module.

Lint checks

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

String resources

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

Switch to WebP

Significant reduction of the drawable resources size may be achieved by switching to WebP images instead of PNGs. Android Instant Apps supports all features of the WebP format (transparency, lossless, etc.) so there will be no loss in functionality. Keep in mind that application launcher icons must use PNG format, but it should not be a problem since projects normally keep those in mipmap- directories. If a backward compatible solution is required, you need to include the original PNG images in the APK module and it will override WebP resources automatically (main source set overrides all resources from AAR/feature module). [4]
Of course, going with vector drawables may let you save even more of the precious space, but using vector drawables will require a code change while the above mentioned trick with WebP images for the instant app and PNG images for the installable APK requires no code modifications.

Download assets at runtime

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

Review native libraries

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

Review external libraries

Next review the list of all external libraries linked with the app's code. You may find some unexpected surprises courtesy of transitive dependencies. Transitive dependencies occur when the library your project relies upon depends on another library, which in turn may depend on yet another library. Sometimes those transitive dependencies may contain unexpected surprises such as libraries you do not need at all (i.e. a JSON processing library you never use in your code.) Please see "Excluding transitive dependencies" section in the Gradle User Guide for further details.
Android Studio has several useful tools for analyzing the external dependencies for the project. It always helps to start with the Project view:
The "Project" view shows a section called "External libraries", where you can see all the libraries used by the project including any transitive dependencies:
In order to further reduce the base feature size you may need to pay attention to the code dependencies and external libraries. Check the "Project" view and look for unused libraries that might be transitive dependencies the project does not need. Also look for libraries that provide the same functionality (e.g. multiple libraries for image loading/caching). [4]
You can also compare different builds with APK Analyzer tool, and it works with instant APKs, too.
Finally, review the list of transitive dependencies and exclude the ones you do not need. Use the following command to review the dependencies graph: gradle -q :MODULE:dependencies --configuration compile. Further details can be found in the Gradle documentation.

Other tips

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

Hear from other developers using Android Instant Apps

Finally, check out these great posts by developers that have already built an instant app:
Visit the Android Developers website to get started with Android Instant Apps and check out more instant apps success stories from other developers.