Posted by Leticia Lago, Head of Developer Marketing, EMEA
At the start of this year we opened submissions for 2020’s Google Play Indie Games Festival - an international competition celebrating incredible indie games from Europe, Japan and South Korea.
We’ve received hundreds of fantastic submissions that showcase the technical abilities and groundbreaking creativity of independent studios. Many thanks to everyone who submitted their game. After some hard choices and late nights, we’re happy to announce our 20 finalists in each region.
Please check out the games below (in alphabetical order); each one is a true work of art. They will be receiving promotions and prizes to help them grow their business. They’ll also be competing in the Finals for the top prizes.
While this is a happy announcement, we must also inform you that we will be unable to hold the Finals as planned on April 25 in Poland, Japan and South Korea due to the COVID-19 situation. We will be postponing the events until further notice, as the health and safety of finalists, jury members, players and others involved is our top priority. Please stay tuned for further announcements.
60 Parsecs! by Robot Gentleman
Aisle Trial by Jake Matthews-Belcher
Alien Escape by Korion Games
Alt-Frequencies by Accidental Queens
Bad North by Rawfury
Bounce that Bird! by Affinity Project
Cessabit: a Stress Relief Game by Tepes Ovidiu
Color Spots by UX Apps
Cookies Must Die by Rebel Twins
Demons Never Lie by Maika Hernandez
Doors: Awakening by Big Loop
Faraway: Galactic Escape by Pine Studio
inbento by Afterburn
My Diggy Dog 2 by King Bird Games
The White Door by Rusty Lake
Tiny Tomb: Dungeon Explorer by Tinycorp
Traffix by Infinity Games
Tricky Castle by Team Tricky
Unhatched by Filip Loster
Void Tyrant by Quite Fresh
Amayadori by CHARON・Yanase
CUBE GARDEN by Fukudanuki
GIGAFALL by Shiki Game Studio
GummyShooter by simatten
Home Fighter by hap Inc.
Matsuro Palette by SleepingMuseum
METBOY! by REBUILD GAMES
Mocha - Dagsaw Puzzle - by Kotoriyama, Inc.
MonsterTrader by Mitsuhiro Okada
Overturn by Katsu Matsuda
Shiritori - The Word Chain Game by Baton
Snowman Story by Odencat
SOUND JOURNEY SCHOOL WANDERER by SOUND JOURNEY
TAP! DIG! MY MUSEUM! by oridio Inc.
Teiji Taisha Online by toru sugitani
The Final Taxi by Zxima.LLC
Uncrowned by NESTOPI Inc.
Wasurenaide, otona ni natte mo by GAGEX Co.,Ltd.
World for Two by Seventh rank
Zelle by Odencat Fuming
Castle Defense Online by BlackHammer
CAT THE DJ by CATSBY STUDIO
DiceEmpire by Banjiha Games
Domino City by Bad Beans
DUST by I-eye studio
Electroad by Night Owl Studio
Extreme football by 9M Interactive
From Earth by Kentauros Entertainment
Great Sword - Stickman Action RPG by Olivecrow
Heroes Restaurant by Team Tapas
Little Boy by 39Studio
Magic Survival by LEME
Mayday Memory by StoryTaco.inc
Petrider by Ddookdak studio
Project Mars by Moontm
QV by Izzle
Sand Shark : The Boy and The Sea by GABANGMAN STUDIO
Staroid : Brick breaker shooter by Spring Games
Sword Master Story by CodeCAT
Undestroyed by Keymaker games
The competition was open to indie developers from the following European countries: Austria, Belgium, Belarus, Bulgaria, Croatia, Czech Republic, Denmark, Estonia, Finland, France, Germany, Hungary, Israel, Italy, Latvia, Lithuania, Netherlands, Norway, Poland, Portugal, Romania, Russia, Slovakia, Slovenia, Spain, Sweden, Turkey, Ukraine, and the United Kingdom (including Northern Ireland).
How useful did you find this blog post?
★ ★ ★ ★ ★
As part of the Android 11 developer preview we’ve released Android 11 system images, which are capable of executing ARM binaries with significantly improved performance. Previously, developers who were dependent on ARM libraries and could not build an x86 variant of their app either had to use system images with full ARM emulation, which are much slower than x86 system images when run on x86-based computers, or resort to physical devices. The new Android 11 system images are capable of translating ARM instructions to x86 without impacting the entire system. This allows the execution of ARM binaries for testing without the performance overhead of full ARM emulation.
The new Android 11 (Google APIs) x86 system image supports ARM ABIs, while the older Android Oreo system image does not
The significance of this may require a bit of context, especially if you build apps exclusively with Kotlin or the Java programming language. Unlike Kotlin or the Java programming language, both of which execute on the Android Runtime (ART), any C++ in your Android app compiles directly into machine instructions. This means that it needs to be compiled differently based on the architecture of the target device. Mobile phones tend to have ARM processors; consequently, many C++ dependencies you might add to your app, like a camera barcode scanner library, are only compatible with ARM processors. This is a problem if you develop on a computer with an x86-based processor, as it would prevent you from running your app.
Previously, if you wanted to get around this limitation and execute an app built for ARM on your x86 machine, you would have had to use an emulator system image with full ARM emulation. Due to the overhead of translating an entire system’s worth of ARM instructions to x86, emulator system images with full ARM emulation tend to run much slower than x86-based system images when run on x86 host machines. Additionally, emulator system images with full ARM emulation cannot take advantage of the hardware acceleration and CPU virtualization technologies provided by x86 processors.
The new ARM-compatible Android 11 system images allow the entire system to run x86 natively and take advantage of virtualization technologies as usual. When an app’s process requires an ARM binary, the binary is translated to x86 within that process exclusively. This allows the rest of the process to continue executing in x86, including the Android Runtime (ART), and other performance-critical libraries like libGLES and libvulkan. In addition to this, the translator avoids expensive memory access instrumentation and the associated performance hit by avoiding the execution of low-level hardware-specific libraries. These new emulator system images can be used both locally and on your own continuous integration infrastructure. This is possible thanks to collaboration with ARM Limited.
If you have previously chosen physical devices over the emulator due to the lack of performant ARM support, try out the Android 11 system images, which are now available alongside the Android 11 Developer Preview. These system images can be downloaded in Android Studio via either the SDK Manager or the Android Virtual Device Manager.
Using the Android Virtual Device Manager to create an AVD that runs Android 11
Once you get your app running on the emulator, consider adapting it for Chrome OS. Chrome OS also supports the execution of Android apps built for ARM on x86 laptops. Building for Chrome OS provides access to a substantial ecosystem of larger screen devices, allowing your application to reach even more users globally.
This technology should enable more developers to test with the Android Emulator. That said, we still recommend that developers publish both x86 and ARM ABI variants of their apps to achieve the best physical device performance and reach as many users as possible. Going forward, we plan to roll this technology out across a wider variety of API levels and ensure that it supports testing all use cases that a physical device would. Given that this is a new technology, please let us know of any problems via our Issue Tracker.
Note that the ARM to x86 translation technology enables the execution of intellectual property owned by Arm Limited. It will only be available on Google APIs and Play Store system images, and can only be used for application development and debug purposes on x86 desktop, laptop, customer on-premises servers, and customer-procured cloud-based environments. The technology should not be used in the provision of commercial hosted services.
Java is a registered trademark of Oracle and/or its affiliates.
Posted by Greg Hartrell, Head of Product Management, Games on Android & Google Play
While we're sorry we didn't get to see you all in person at GDC, we hope you are all staying healthy and safe. As many of us look to press on with work as much as possible, we’d like to share with you what our teams have been working on at the digital Google for Games Developer Summit. We couldn’t be happier with the continued growth of the vibrant Android gaming ecosystem. In fact, Android remains the world's most popular mobile platform with more than 2.5 billion monthly active devices and great news for game developers, we’re seeing more than 1.4 trillion minutes played per month in your games on Google Play. It’s important to us that our platforms are highly useful to every kind of game developer, so our payment system helps games monetize in more than 65 countries. Moreover, we offer our users more than 275 local forms of payment, including more than 180 carrier billing options, with gift cards sold in over 900 thousand unique retail locations worldwide.
Across Android and Google Play, our mission is to deliver the best platform to build, discover, and experience games. Specifically, we’re working on ways to help you increase the reach of your games and manage the fragmentation of the Android ecosystem. We’re also focused on helping you access a wider player base, once you’ve made a great game and are ready to get it out there. Last year, we shared that we’re investing heavily in our games efforts to address your challenges in these areas, and now we are excited to share several new tools and services built specifically with game developers in mind.
New Android tools for mobile game development A major area of investment for us has been making it easier for developers to build and optimize games for Android. Here’s a round-up of several new tools we’re releasing:
New ways to reach more devices and win go-to-market The Google Play store is shifting to be more gameplay centric by showing more visuals that demonstrate gameplay and a new system of tags to help users learn more about specific game traits and aid in exploration. Learn how you can ensure your game is of high-quality and leverage various features and new services to help you succeed in your go-to-market activities.
Thanks for your support in continuing to build incredible games. Make sure to try some of the new tools and services we just released and catch the full playlist of mobile developer sessions. If you’re interested in sharing feedback to help shape the development of cutting edge features, apply to join our developer preview programs from Android and Google Play. You can also learn about all of the offerings we have to help game developers building on Android at d.android.com/games.
Posted by Dave Burke, VP of Engineering
It’s been a difficult few months for many around the world. The Android team at Google is a global one, and we, like many of you, are learning how to adapt to these extraordinary times. We want to thank you, our developer community, who have given us valuable feedback on Android 11 amidst these circumstances. We hope you, your families and colleagues are all staying well.
Just as many of you are trying to press on with work where possible, we wanted to share the next milestone release of Android 11 for you to try. It’s still an early build, but you can start to see how the OS is enabling new experiences in this release, from seamless 5G connectivity to wrapping your UI around the latest screens, to a smarter keyboard and faster messaging experience.
There’s a lot to check out in Developer Preview 2 - read on for a few highlights and visit the Android 11 developer site for details. Today’s release is for developers only and not intended for daily or consumer use, so we’re making it available by manual download and flash only for Pixel 2, 3, 3a, or 4 devices. To make flashing a bit easier, you can optionally get today’s release from the Android Flash Tool. For those already running Developer Preview 1 or 1.1, we’re also offering an over-the-air (OTA) update to today’s release.
Let us know what you think, and thank you to everyone who has shared such great feedback so far.
5G state API - DP2 adds a 5G state API to let you quickly check whether the user is currently on a 5G New Radio or Non-Standalone network. You can use this to highlight your app’s 5G experience or branding when the user is connected. You can use this API together with the 5G dynamic meteredness API and bandwidth estimator API, as well as existing connectivity APIs, to take advantage of 5G’s improved speeds and latency.
Hinge angle for foldables - A top request for foldable devices has been an API to get the angle of the device screen surfaces. Android 11 now supports a hinge angle sensor that lets apps query directly or through a new AndroidX API for the precise hinge angle, to create adaptive experiences for foldables.
Call screening service improvements - To help users manage robocalls, we’re adding new APIs to let call-screening apps do more to help users. In addition to verifying an incoming call’s STIR/SHAKEN status (standards that protect against caller ID spoofing) as part of its call details, call-screening apps can report a call rejection reason. Apps can also customize a system-provided post call screen to let users perform actions such as marking a call as spam or adding to contacts. We’ll have more to share on this soon.
New ops and controls in Neural Networks API - Activation functions control the output of nodes within a neural network. At Google AI, we discovered a swish activation function allowing for faster training time and higher accuracy across a wide variety of tasks. In Android 11, we’re adding a computationally efficient version of this function, the hard-swish op. This is key to accelerating next-generation on-device vision models such as MobileNetV3 which forms the base model for many transfer learning use cases. Another major addition is the Control ops enabling more advanced machine learning models that support branching and loops. Finally, we’ve also added new execution controls to help you minimize latency for common use cases: Asynchronous Command Queue APIs reduce the overhead when running small chained models. See the NDK sample code for examples using these new APIs.
We’re adding several more features to help keep users secure and increase transparency and control. Give these a try with your apps right away and let us know what you think.
Foreground service types for camera and microphone - in Android 10 we introduced the manifest attribute foregroundServiceType as a way to help ensure more accountability for specific use-cases. Initially apps could choose from “location” and several others. Now in Android 11 we’re adding two new types - “camera” and “microphone”. If your app wants to access camera or mic data from a foreground service, you need to add the foregroundServiceType value to your manifest.
Scoped storage updates- We’re continuing to iterate on our work to better protect app and user data on external storage. In this release we’ve made further improvements and changes, such as support to migrate files from the legacy model to the new scoped storage model, and better management of cached files. Read more here and watch for more enhancements in subsequent updates.
Read more about these and other Android 11 privacy features here.
Synchronized IME transitions - A new set of APIs let you synchronize your app’s content with the IME (input method editor, aka soft keyboard) and system bars as they animate on and offscreen, making it much easier to create natural, intuitive and jank-free IME transitions. For frame-perfect transitions, a new insets animation listener notifies apps of per-frame changes to insets while the system bars or the IME animate. Additionally, apps can take control of the IME and system bar transitions through the WindowInsetsAnimationController API. For example, app-driven IME experiences let apps control the IME in response to overscrolling the app UI. Give these new IME transitions a try and let us know what other transitions are important to you.
Synchronized IME transition through insets animation listener.
App-driven IME experience through WindowInsetsAnimationController.
Variable refresh rate - Apps and games can now set a preferred frame rate for their windows. Most Android devices refresh the display at 60Hz refresh rate, but some devices support multiple refresh rates, such as 90Hz as well as 60Hz, with runtime switching. On these devices, the system uses the app’s preferred frame rate to choose the best refresh rate for the app. The API is available in both the SDK and NDK. See the details here.
Resume on reboot - Android 11 improves the experience of scheduled overnight over-the-air software updates. Like in previous versions of Android, the device must still reboot to apply the OTA update, but with resume on reboot, apps are now able to access Credential Encrypted (CE) storage after the OTA reboot, without the user unlocking the device. This means apps can resume normal function and receive messages right away - important since OTA updates can be scheduled overnight while the device might be unattended. Apps can still support Direct Boot to access Device Encrypted (DE) immediately after all types of reboot. Give resume on reboot a try by tapping “Restart after 2AM” with your next Developer Preview OTA update, more details here.
Camera support in Emulator - The Android emulator now supports front and back emulated camera devices. The back camera supports Camera2 API HW Level 3 (includes YUV reprocessing, RAW capture). It’s a fully CTS-compliant LEVEL_3 device that you can use to test advanced features like ZSL and RAW/DNG support. The front camera supports FULL level with logical camera support (one logical device with two underlying physical devices). This camera emphasizes logical camera support, and the physical camera devices include narrow and wide field of view cameras. With this emulated camera support, you can build and test with any of the camera features added in Android 11. More details coming soon.
We’re working to make updates faster and smoother by prioritizing app compatibility as we roll out new platform versions. In Android 11 we’ve added new processes, tools, and release milestones to minimize the impact of platform updates and make them easier for developers.
With Developer Preview 2, we’re well into the release and getting closer to Beta. so now is the time to start your compatibility testing and identify any work you’ll need to do. We recommend doing the work early, so you can release a compatible update by Android 11 Beta 1. This lets you get feedback from the larger group of Android 11 Beta users.
When we reach Platform Stability, system behaviors, non-SDK greylists, and APIs are finalized. At this time, plan on doing your final compatibility testing and releasing your fully compatible app, SDK, or library as soon as possible so that it is ready for the final Android 11 release. More on the timeline for developers is here.
You can start compatibility testing on a Pixel 2, 3, 3a, or 4 device, or you can use the Android Emulator. Just flash the latest build, install your current production app, and test all of the user flows. There’s no need to change the app’s targetSdkVersion at this time. Make sure to review the behavior changes that could affect your app and test for impacts.
To help you with testing, we’ve made many of the breaking changes toggleable, so you can force-enable or disable them individually from Developer options or adb. Check out the details here. Also see the greylists of restricted non-SDK interfaces, which can also be enabled/disabled.
App compatibility toggles in Developer Options.
Developer Preview has everything you need to try the Android 11 features, test your apps, and give us feedback. Just download and flash a device system image to a Pixel 2 / 2 XL, Pixel 3 / 3 XL, Pixel 3a / 3a XL, or Pixel 4 / 4 XL device, or set up the Android Emulator through Android Studio. Next, update your Android Studio environment with the Android 11 Preview SDK and tools, see the set up guide for details.
As always, your feedback is crucial, so please continue to let us know what you think — the sooner we hear from you, the more of your feedback we can integrate. When you find issues, please report them here.
Last May at Google I/O, we announced that Android was going Kotlin first, and now over 60% of the top 1000 Android apps use Kotlin. One feature we love about Kotlin is that nullability is baked into its type system — when declaring a reference, you say upfront whether it can hold null values. In this post, we’ll look at how the Android 11 SDK does more to expose nullability information in its APIs and show how you can prepare your Kotlin code for it.
How does nullability in Kotlin work?
When writing code in Kotlin, you can use the question mark operator to indicate nullability:
KOTLIN var x: Int = 1 x = null // compilation error var y: Int? = 1 y = null // okay
This aspect of Kotlin makes your code safer — if you later call a method or try to access a property on a non-null variable like x, you know you’re not risking a null pointer exception. We hear over and over again that this feature of Kotlin gives developers more peace of mind and leads to higher quality apps for end users.
x
How does nullability work with the Java programming language?
Not all of your (or Android’s) APIs are written in Kotlin. Fortunately, the Kotlin compiler recognizes annotations on Java programming languages methods that indicate whether they produce nullable or non-nullable values. For example:
JAVA public @Nullable String getCurrentName() { return currentName; }
The @Nullable annotation ensures that when using the result of getCurrentName in a Kotlin file, you can’t dereference it without a null check. If you try, Android Studio will notify you of an error, and the Kotlin compiler will throw an error in your build. The opposite is true of @NonNull — it tells the Kotlin compiler to treat the method result as a non-null type, forbidding you from assigning that result to null later in your program.
@Nullable
getCurrentName
@NonNull
null
The Kotlin compiler also recognizes two similar annotations, @RecentlyNullable and @RecentlyNonNull, which are the exact same as @Nullable and @NonNull, only they generate warnings instead of errors1.
@RecentlyNullable
@RecentlyNonNull
Nullability in Android 11
Last month, we released the Android 11 Developer Preview, which allows you to test out the new Android 11 SDK. We upgraded a number of annotations in the SDK from @RecentlyNullable and @RecentlyNonNull to @Nullable and @NonNull (warnings to errors) and continued to annotate the SDK with more @RecentlyNullable and @RecentlyNonNull annotations on methods that didn’t have nullability information before.
What’s next
If you are writing in Kotlin, when upgrading from the Android 10 to the Android 11 SDK, you may notice that there are some new compiler warnings and that previous warnings may have been upgraded to errors. This is intended and a feature of the Kotlin compiler — these warnings tell you that you may be writing code that crashes your app at runtime (a risk you would miss entirely if you weren’t writing in Kotlin). As you encounter these warnings and errors, you can handle them by adding null checks to your code.
As we continue to make headway annotating the Android SDK, we’ll follow this same pattern — @RecentlyNullable and @RecentlyNonNull for one numbered release (e.g., Android 10), and then upgrade to @Nullable and @NonNull in the next release (e.g., Android 11). This practice will give you at least a full release cycle to update your Kotlin code and ensure you’re writing high-quality, robust code.
1. Due to rules regarding handling of annotations in Kotlin, there is currently a small set of cases where the compiler will throw an error for @Nullable references but not for @RecentlyNullable references.
Java is a trademark of Oracle and/or its affiliates.
Last month, Game Developers Conference (GDC) organizers made the difficult decision to postpone the conference. We understand this decision, as we have to prioritize the health and safety of our community. GDC is one of our most anticipated times of the year to connect with the gaming industry. Though we won’t be bringing the news in-person this year, we’re hosting the Google for Games Developer Summit, a free, digital-only experience where developers can watch the announcements and session content that was planned for GDC.
Google for Games Developer Summit
The Developer Summit kicks off on March 23rd at 9:00AM PT with our broadcasted keynote. Immediately following, we’ll be releasing a full lineup of developer sessions with over 10 hours of content to help take your games to the next level.
Here are some types of sessions to expect:
Sign up to stay informed at g.co/gamedevsummit.
Support for the game developer community
We recognize every developer is impacted differently by this situation. We’re coordinating with the GDC Relief Fund to sponsor and assist developers who’ve invested in this moment to further grow their games.
We also understand many developers were looking forward to sharing their content with peers. To help with this, developers can use YouTube to stream events from small to large using tools like Live Streaming and Premieres.
We can’t wait to share what we have in store for gaming. Discover the solutions our teams have been building to support the success of this community for years to come.
This article was cross-posted from the Google Developer Blog. Google Play will be participating in the Google for Games Developer Summit on March 23rd at 9:00AM PT to share how we're making Google Play even more powerful for game developers!
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
