The latest Android and Google Play news for app and game developers.
Today we're releasing the source code for the official Google I/O 2017 for Android app.
This year's app substantially modifies existing functionality and adds several new features. It also expands the tech stack to use Firebase. In this post, we'll highlight several notable changes to the app as well as their design considerations.
The most prominent new feature for 2017 is the event reservation system, designed to help save in-person attendees' time and provide a streamlined conference experience. Registered attendees could reserve sessions and join waitlists prior to and during the conference; a reservation provided expedited entry to sessions without having to wait in long lines. Reservation data was synced with attendees' conference badges, allowing event staff to verify reservations using NFC-enabled phones. Not only was the reservation feature incredibly popular, but the reservation data helped event staff change the size of session rooms both before and during I/O to adjust for actual demand for seats.
The reservation feature was implemented using Firebase Realtime Database (RTDB) and Cloud Functions for Firebase. RTDB provided easy sync across user devices — we just had to implement a listener in our code to receive database updates. RTDB also provided out-of-the-box offline support, allowing conference data to be available even in the face of intermittent network connectivity while traveling. A Cloud Function processed reservation requests in the background for the user, using transactions to ensure correctness of state (preventing mischievous users from grabbing too many seats!) and communicating with the event badging system.
As in previous years, we used a ContentProvider as an abstraction layer over all app data, which meant we had to figure out how to integrate RTDB data with the ContentProvider. We needed to negotiate between having two local caches for data: 1) the extant local SQLite database accessed via the ContentProvider, and 2) the local cache created by RTDB to facilitate offline access. We decided to integrate all app data under the ContentProvider: whenever reservation data for the user changed in RTDB, we updated the ContentProvider, making it the single source of truth for app data at all times. This meant that we needed to keep open connections to RTDB only on a single screen, the Session Detail Activity, where users might be actively managing their reservations. Reservation data displayed in other parts of the app was backed by the ContentProvider. In offline mode, or in case of a flaky or delayed connection to RTDB, we could just get the last known state of the user's reservations from the ContentProvider.
We also had to figure out good patterns for integrating RTDB into the overall sync logic of IOSched, especially since RTDB comes with a very different sync model than the ping-and-fetch approach we were using in the app. We decided to continue using Cloud Endpoints to synchronize user data across devices and with the web and iOS clients (the data itself was stored in Datastore). While RTDB provides out-of-the-box data syncing, we wanted to make sure that a user's reservation data was current across all devices, even when the app was not in the foreground. We used a Cloud Function to integrate RTDB reservation data into the sync flow: once reservation data for a user changed in RTDB, the function updated the endpoint, which triggered a Firebase Cloud Messaging downstream message to all the user's devices, which then scheduled data syncs.
This year's app also featured a Feed to apprise users about hour-by-hour developments at I/O (most of the app's users were remote, and the Feed was a window into the conference for them). The Feed was also powered by RTDB, with data pushed to the server using a simple CMS. We used a Cloud Function to monitor RTDB feed data; when feed data was updated on the server, the Function sent a Cloud Messaging downstream message to clients, which visually surfaced the presence of new feed items to the user.
In 2015 and 2016, we had adopted an MVP architecture for IOSched, and we continued using that this year. This architecture provides us with good separation of concerns, facilitates testing, and in general makes our code cleaner and easier to maintain. For the Feed feature, we decided to experiment with a more lightweight MVP implementation inspired by Android Architecture Blueprints, which provided the necessary modularity while being very easy to conceptualize. The goal here was both pedagogical and practical: we wanted to showcase an alternate MVP pattern for developers; we also wanted to showcase an architecture that was an appropriate fit for our needs for this feature.
For the first time, IOSched made heavy use of Firebase Remote Config. In the past, we had found ourselves unable to inform users when non-session data - wifi information, shuttle schedule, discount codes for ridesharing, etc. - changed just before or during the conference. Forcing an app update was not feasible; we just wanted in-app default values to be updatable. Using remote config easily solved this problem for us.
In the end, we ended up with a three-tier system of informing users about changes:
Even though we're releasing the 2017 code, we still have work ahead of us for the coming months. We'll be updating the code to follow modern patterns for background processing (and making our app "O" compliant), and in the future we'll be adopting Android's Architecture Components to simplify the overall design of the app. Developers can follow changes to the code on GitHub.
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.
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!
gradle -q :MODULE:dependencies --configuration compile
Based in the UK, Playdemic is a free-to-play mobile games developer. Their leading game Golf Clash is designed to provide a short and fun, competitive experience. It uses a simple and accessible game mechanics based on one-thumb gaming which has generated substantial user engagement, with an average of 44 minutes played over three sessions a day. Golf Clash is now played by more than 1.5 million players every day whilst the average revenue per user is equal to other platforms.
Watch Paul Gouge, CEO & Co-founder, and Gareth Jones, Head of Production, discuss how Playdemic uses live game operations ("live ops") to continuously engage players and grow their business on Google Play. Live ops are also referred to as "running games as a service"; they include the strategic distribution of content and interactions with players that are limited in time and are designed to increase engagement and monetization.
Watch more developer stories and learn about other features and best practices you can use to succeed on Google Play with the updated Playbook app.
Subscriptions can be a sustainable source of revenue, allowing you to invest in your long-term business growth with confidence. Subscription apps are growing rapidly on Google Play; the number of subscribers doubled in the last year and spend on subscriptions has increased 10-times over the past three years. To help the growing number of subscription businesses we're seeing, we introduced the subscriptions dashboard in the Google Play Console at I/O 2017. Today, we're adding three new subscription reports covering acquisition, retention, and cancellations to help you understand your data and make informed business decisions. Find information below on the new features, our updated best practices to help you grow your subscriptions business, and stories from other developers succeeding on Google Play.
The acquisition report enables you to evaluate different acquisition channels, including Adwords and UTM-tagged campaigns. This can help you identify which channels and campaigns are the most successful in acquiring new subscribers.
The retention report displays the lifetime retention of a customized cohort of your subscribers. It allows you to easily compare different subscription products, plots key events such as the end of a free trial, and provides forecasts to enable you to make decisions faster.
Finally, the cancellations report. This detailed cancellation data shows when a user cancels, either voluntarily (such as when they choose to cancel) or involuntarily (for example, when there is payment failure). You can also see whether the cancellation was accompanied by the person uninstalling.
We're continually working to improve the Google Play Console. If you have ideas or feedback on how we can improve the subscriptions features, please let us know.
To benefit from these features, you need to be using Google Play Billing as the payment method for subscriptions in your app. Implementing Play Billing is easy with the new Google Play Billing Library. We've also updated Play Billing so the billing permission will be enforced when the buyer tries to initiate a purchase rather than when you publish your app. This means you can publish a single APK in both Play Billing supported and non-supported countries (rather than maintaining a separate APK that does not use the Billing permission for non-supported countries). Remember to check first if billing is supported before trying to offer any in-app purchases.
As developers become more sophisticated with their subscriptions offerings on Google Play, our most successful partners have learned a lot about what does and doesn't work well. Niko Schröer, a partner manager with expert knowledge of subscription apps, has a new post on Medium to help you become a successful subscriptions company. In the post, you'll find a link to our detailed user research on Android subscribers [PDF] published in June 2017, which offers helpful insights into what users look for in a subscription product. We've also published some new best practices on subscriptions, which you can read along with other tips to succeed on Google Play in the Playbook app.
Viki, a Singapore based video app, uses subscriptions to build a sustainable and predictable revenue stream, allowing them to invest in original content and provide better premium experiences for their users. Total revenue from subscriptions grew over 200% over the year, and by 700% in emerging markets like the Middle East and Latin America. Watch Alex Chan, Senior VP of Product and Engineering at Viki, tell the story.
The developer of Anghami, a popular music service in the Middle East and North Africa, increased the number of subscribers in their app with user interface experiments and introductory pricing. During one promotional period, Anghami used introductory pricing to increase new sign-ups by 400% compared to their average daily sign-ups. Find out more about how Anghami achieves subscription success.
Android developers know that dex compilation is a key step in building an APK. This is the process of transforming .class bytecode into .dex bytecode for the Android Runtime (or Dalvik, for older versions of Android). The dex compiler mostly works under the hood in your day-to-day app development, but it directly impacts your app's build time, .dex file size, and runtime performance.
That's why we are investing in making important improvements in the dex compiler. We're excited to announce that the next-generation dex compiler, D8, is now available for preview as part of Android Studio 3.0 Beta release.
When comparing with the current DX compiler, D8 compiles faster and outputs smaller .dex files, while having the same or better app runtime performance.
D8 is available for your preview starting with Android Studio 3.0 Beta. To try it, set the following in your project's gradle.properties file:
android.enableD8=true
We have tested D8's correctness and performance on a number of apps, and the results are encouraging. We're confident enough with the results that we are switching to use D8 as the default dex compiler for building AOSP. There are currently no known issues, but we would love to hear your feedback. You can file a bug report using this link.
We plan to preview D8 over the next several months with the Android Studio 3.0 release. During this time, we will focus on addressing any critical bug reports we receive from the community. We plan to bring D8 out of preview and enable it as the default dex compiler in Android Studio 3.1. At that time, the DX compiler will officially be put in maintenance mode. Only critical issues with DX will be fixed moving forward.
Beyond D8, we are also working on R8, which is a Proguard replacement for whole program minification and optimization. While the R8 project has already been open sourced, it has not yet been integrated with the Android Gradle plugin. We will provide more details about R8 in the near future when we are ready to preview it with the community.
In April, we announced Java 8 language features with desugaring. The desugaring step currently happens immediately after Java compilation (javac) and before any bytecode reading or rewriting tools are run. Over the next couple of months, the desugar step will move to a later stage in the pipeline, as part of D8. This will allow us to further reduce the overall build time and produce more optimized code. This change means that any bytecode reading or rewriting tools will run before the desugar step. If you develop .class bytecode reading or rewriting tools for Android, you will need to make sure they can handle the Java 8 bytecode format so they can continue to work properly when we move desugaring into D8.
Happy dex'ing!
Today, we're releasing Developer Preview 5 (DP5) of Android Things, which includes the major change of being based on the upcoming Android O release. Android Things is Google's platform to enable Android Developers to create Internet of Things (IoT) devices, and seamlessly scale from prototype to production.
Android O is currently under Developer Preview for phones and tablets, and DP5 is now based on this upcoming release (previous releases were based on Android N). This means that your future Android Things applications should target API 26 to work correctly on the platform with our support libraries.
DP5 now adds support for the new NXP SprIoT i.MX6UL design, as listed in our developer kits documentation. With Intel discontinuing the Edison and Joule hardware designs, these platforms are moving to legacy support. They will not continue to receive the latest platform updates, but developers may continue to access the DP4.1 system images from the Android Things Console.
An important goal of Android Things is to help developers seamlessly scale from prototype to production. When we exit Developer Preview, we will differentiate between hardware platforms targeted for prototyping-only and hardware reference designs that can scale to production. Production-ready hardware will satisfy Google's security requirements and include long term support from the silicon manufacturers. We will have more to share later on.
With the move to the Android O codebase, there are new API features from Android as well as specific features for Android Things. For those developers using UserDriver APIs, you will need to add new permissions to your AndroidManifest.xml. The documentation contains details about the permissions needed for each driver type. DP5 also now supports OpenGL ES 2.0 and WebView on the Raspberry Pi 3, which was a highly requested feature from developers. We have also implemented dynamic pin muxing for the Raspberry Pi 3, with pins being configured at runtime depending on what features are being used.
The samples for Android Things are now available directly in Android Studio for browsing and importing. You can now go to File, New, Import Samples, and search for Things to see everything that is available. We have a wide range of samples, demonstrating how to interact with buttons, sensors, LEDs, and displays, as well as implementing Google Assistant and TensorFlow.
We recently launched the Android Things Console, which provides the ability to support over-the-air updates (OTA) to Android Things devices. We have recently made a number of UX improvements to the console to improve usability and functionality. DP5 is now available within the Android Things Console, but the DP5 update will not be pushed automatically to devices without your intervention. You will need to update your application for DP5, then create a new update and push it via the console yourself.
With Android Things being updated to Android O, significant changes have been made to the platform. Please send us your feedback by filing bug reports and feature requests, and asking any questions on Stack Overflow. To start using DP5, use the Android Things Console to download system images and update existing devices. More information about the changes are available in the release notes. You can also join Google's IoT Developers Community on Google+, a great resource to get updates and discuss ideas. Also, we have our new hackster.io community, where everyone can share the amazing projects they have built!
Play Console
