The latest Android and Google Play news for app and game developers.
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!
For many international developers Russia is considered to be an opportunity to grow their app or games business. According to the 2017 report on the 'Mobile Internet Economy in Russia [PDF]', Russia's population is young with 45% of people being under 35 years old.1 The report also found that mobile subscriptions are at 160% of the population of 146 million people, meaning people with data plans have more than one on average – considerably higher than other well connected countries.2 Last year Android accounted for 84% of all smartphones in Russia and smartphone shipments are still growing with demand up 11% in early 2017 compared to 2016.
Russian people are very engaged in terms of smartphone mobile usage, Russia is one of the top countries in terms of apps downloaded per person3. Half of the population are gamers; their favorite game genres being strategy, builders and farms, shooters, puzzles and fighters. The most popular app categories are dating (with strong local developers), music & video, social & messaging and shopping.4
Along with understanding Russian mobile trends, there are market specific best practices which can help you tailor your apps and games for a local audience to increase your chance of business success.
For more guidance, read the localization checklist.
On July 24st we launched the first Now in Russian collection on Google Play, featuring 24 titles from international developers such as Kabam's Transformers, GTarcade's Legacy of Discord, Yodo1's Crossy Road, im30's Last Empire - War Z and others.
We are planning to refresh the collection by the end of the year and we would love to include your title! Submit your recently localized title for a chance to be included.
People enjoy using apps and games which meet their performance and quality expectations. Excessive battery usage, slow render times, and crashes, on the other hand, can be a source of frustration. In fact, in an internal analysis of app reviews on Google Play, we noticed that half of 1-star reviews mentioned app stability. Developers who focus on app quality can see improvements in their rating, and ultimately their retention and monetization.
As part of our continued effort to deliver the best possible Google Play experience, we recently enhanced our search and discovery algorithms to reflect app quality. This results in higher quality apps being surfaced in the Play Store more than similar apps of lower quality (eg: apps that exhibit more frequent crashes). The change has had a positive impact on engagement -- we've seen that people go on to use higher quality apps more and uninstall them less.
Developers focusing on performance can use the Play Console to help find and fix a number of quality issues. Android vitals identifies key performance issues, reported by opted-in devices which have your app installed, so you can address them. The pre-launch report shows you the result of testing your alpha or beta app on popular physical devices so you can catch issues before launching updates. Also, ratings and reviews can provide additional insights related to app quality, directly from people using your app. To see the positive effect this can have, find out how Busuu increased their rating from 4.1☆ to 4.5☆ by focusing on app performance.
Google Play strives to help people find and discover safe, high quality, useful, and relevant apps. By focusing on the quality and performance of your app, you'll find more success on Google Play. For more tips and best practices to grow your app or game business, get the Playbook app.
LLVM, the compiler infrastructure used to build Android, contains multiple components that perform static and dynamic analysis. One set of these components that have been used extensively when analyzing Android are the sanitizers, specifically AddressSanitizer, UndefinedBehaviorSanitizer and SanitizerCoverage. These sanitizers are compiler-based instrumentation components contained in compiler-rt that can be used in the development and testing process to push out bugs and make Android better. The sanitizers that are currently available in Android can discover and diagnose many memory misuse bugs and undefined behavior and can give code coverage metrics to ensure that your test suite is as complete as possible.
This blog post details the internals of the current Android sanitizers—AddressSanitizer, UndefinedBehaviorSanitizer and SanitizerCoverage—and show how they can be used within the Android build system.
AddressSanitizer (ASan) is a compiler based instrumentation capability that allows for runtime detection of many types of memory errors in C/C++ code. In Android, the checks for the following classes of memory errors have been tested:
Android allows for full build instrumentation by ASan, and also allows for ASan instrumentation at the app level through asanwrapper. Instructions for both instrumentation techniques can be found on source.android.com.
AddressSanitizer is built upon two high-level concepts. The first is instrumentation of all memory-related function calls, including alloca, malloc, and free, with information to track memory allocation, free, and usage statistics. This instrumentation allows for ASan to detect invalid memory usage bugs including double-free, use-after scope, return, and free. ASan can also detect reads and writes that occur out of bounds of defined memory regions. It does this by padding all allocated memory buffers and variables. If a read or write to this padding region occurs, ASan catches it and outputs information useful for diagnosing the memory violation. This padding is known as poisoned memory in ASan terms. Here is an example of what poisoned memory padding looks like with stack allocated variables:
ASan uses shadow memory to keep track of which bytes are normal memory and which bytes are poisoned memory. Bytes can be marked as completely normal (marked as 0 in shadow memory), completely poisoned (high bit of the corresponding shadow byte is set), or the first k bytes are unpoisoned (shadow byte value is k). If shadow memory indicates a byte is poisoned, then ASan crashes the program and outputs information useful for debugging purposes, including the call stack, shadow memory map, the type of memory violation, what was read or written, PC that caused the violation and the memory contents.
AddressSanitizer: heap-buffer-overflow on address 0xe6146cf3 at pc 0xe86eeb3c bp 0xffe67348 sp 0xffe66f14 WRITE of size 39 at 0xe6146cf3 thread T0 #0 0xe86eeb3b (/system/lib/libclang_rt.asan-arm-android.so+0x64b3b) #1 0xaddc5d27 (/data/simple_test_fuzzer+0x4d27) #2 0xaddd08b9 (/data/simple_test_fuzzer+0xf8b9) #3 0xaddd0a97 (/data/simple_test_fuzzer+0xfa97) #4 0xaddd0fbb (/data/simple_test_fuzzer+0xffbb) #5 0xaddd109f (/data/simple_test_fuzzer+0x1009f) #6 0xaddcbfb9 (/data/simple_test_fuzzer+0xafb9) #7 0xaddc9ceb (/data/simple_test_fuzzer+0x8ceb) #8 0xe8655635 (/system/lib/libc.so+0x7a635) 0xe6146cf3 is located 0 bytes to the right of 35-byte region [0xe6146cd0,0xe6146cf3) allocated by thread T0 here: #0 0xe87159df (/system/lib/libclang_rt.asan-arm-android.so+0x8b9df) #1 0xaddc5ca7 (/data/simple_test_fuzzer+0x4ca7) #2 0xaddd08b9 (/data/simple_test_fuzzer+0xf8b9) SUMMARY: AddressSanitizer: heap-buffer-overflow (/system/lib/libclang_rt.asan-arm-android.so+0x64b3b) Shadow bytes around the buggy address: 0x1cc28d40: fa fa 00 00 00 00 07 fa fa fa fd fd fd fd fd fd 0x1cc28d50: fa fa 00 00 00 00 07 fa fa fa fd fd fd fd fd fd 0x1cc28d60: fa fa 00 00 00 00 00 02 fa fa fd fd fd fd fd fd 0x1cc28d70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1cc28d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x1cc28d90: fa fa fa fa fa fa fa fa fa fa 00 00 00 00[03]fa 0x1cc28da0: fa fa 00 00 00 00 07 fa fa fa 00 00 00 00 03 fa 0x1cc28db0: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa 0x1cc28dc0: fa fa 00 00 00 00 00 02 fa fa fd fd fd fd fd fd 0x1cc28dd0: fa fa 00 00 00 00 00 02 fa fa fd fd fd fd fd fd 0x1cc28de0: fa fa 00 00 00 00 00 02 fa fa fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb
More information on what each part of the report means, and how to make it more user-friendly can be found on the LLVM website and in Github.
Sometimes, the bug discovery process can appear to be non-deterministic, especially when bugs require special setup or more advanced techniques, such as heap priming or race condition exploitation. Many of these bugs are not immediately apparent, and could surface thousands of instructions away from the memory violation that was the actual root cause. As ASan instruments all memory-related functions and pads data with areas that cannot be accessed without triggering an ASan-related callback, memory violations are caught the instant they occur, instead of waiting for a crash-inducing corruption. This is extremely useful in bug discovery and root cause diagnosis. In addition, ASAN is an extremely useful tool for fuzzing, and has been used in many fuzzing efforts on Android.
UndefinedBehaviorSanitizer (UBSan) performs compile-time instrumentation to check for various types of undefined behavior. Device manufacturers can include it in their test builds by including LOCAL_SANITIZE:=default-ub in their makefiles or default-ub: true in the sanitize block of blueprint files. While UBSan can detect many undefined behaviors, Android's build system directly supports:
UBSan's integer overflow checking is also used in Android's build system. UBSan also supports unsigned-integer-overflow, which is not technically undefined behavior, but is included in the sanitizer. These can be enabled in makefiles by setting LOCAL_SANITIZE to signed-integer-overflow, unsigned-integer-overflow, or the combination flag integer, which enables signed-integer-overflow, unsigned-integer-overflow, integer-divide-by-zero, shift-base, and shift-exponent. These can be enabled in blueprint files by setting Misc_undefined to the desired flag. These UBSan targets, especially unsigned-integer-overflow are used extensively in the mediaserver components to eliminate any latent integer overflow vulnerabilities.
The default implementation on Android is to abort the program when undefined behavior is encountered. However, starting in October 2016, UBSan on Android has an optional runtime library that gives more detailed error reporting, including type of undefined behavior encountered, file and source code line information.
In Android.mk files, this is enabled with:
LOCAL_SANITIZE:=unsigned-integer-overflow signed-integer-overflow LOCAL_SANITIZE_DIAG:=unsigned-integer-overflow signed-integer-overflow
And in Android.bp files, it is enabled with:
sanitize: { misc_undefined: [ "unsigned-integer-overflow", "signed-integer-overflow", ], diag: { misc_undefined: [ "unsigned-integer-overflow", "signed-integer-overflow", ], }, },
Here is an example of the information provided by the UBSan runtime library:
external/icu/icu4c/source/common/ucnv.c:1193:23: runtime error: unsigned integer overflow: 4291925010 + 2147483647 cannot be represented in type 'unsigned int' external/icu/icu4c/source/common/cstring.c:288:16: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'uint32_t' (aka 'unsigned int') external/harfbuzz_ng/src/hb-private.hh:894:16: runtime error: unsigned integer overflow: 72 - 55296 cannot be represented in type 'unsigned int' external/harfbuzz_ng/src/hb-set-private.hh:82:24: runtime error: unsigned integer overflow: 32 - 562949953421312 cannot be represented in type 'unsigned long' system/keymaster/authorization_set.cpp:500:37: runtime error: unsigned integer overflow: 6843601868186924302 * 24 cannot be represented in type 'unsigned long'
Sanitizer tools have a very simple code coverage tool built in. SanitizerCoverage allows for code coverage at the call level, basic block level, or edge level. These can be used as a standalone instrumentation technique or in conjunction with any of the sanitizers, including AddressSanitizer and UndefinedBehaviorSanitizer. To use the new guard-based coverage, set fsanitize-coverage=trace-pc-guard. This causes the compiler to insert __sanitizer_cov_trace_pc_guard(&guard_variable) on every edge. Each edge has its own uint32_t guard_variable. In addition, a module constructor, __sanitizer_cov_trace_pc_guard_init(uint32_t* start, uint32_t* stop) is also generated. All the __sanitizer_cov_ functions should be provided by the user. You can follow the example on Tracing PCs with guards.
In addition to control flow tracing, SanitizerCoverage allows for data flow tracing. This is activated with fsanitize-coverage=trace-cmp and is implemented by instrumenting all switch and comparison instructions with __sanitizer_cov_trace_* functions. Similar functionality exists for integer division and GEP instructions, activated with fsanitize-coverage=trace-div and fsanitize-coverage=trace-gep respectively. This is an experimental interface, is not thread-safe, and could change at any time, however, it is available and functional in Android builds.
During a coverage sanitizer session, the coverage information is recorded in two files, a .sancov file, and a sancov.map file. The first contains all instrumented points in the program, and the other contains the execution trace represented as a sequence of indices into the first file. By default, these files are stored in the current working directory, with one created for each executable and shared object that ran during the execution.
ASan, UBSan, and SanitizerCoverage are just the beginning of LLVM sanitizer use in Android. More LLVM Sanitizers are being integrated into the Android build system. The sanitizers described here can be used as a code health and system stability mechanism and are even currently being used by Android Security to find and prevent security bugs!
Play Console
