ANDROID XDA: October 2015

Saturday, October 31, 2015

Customize Doze Parameters With Doze Settings Editor

Doze Settings Editor Lets You Customize Doze Parameters

Now that more people are starting to get their hands on Android 6.0, we’re starting to see some interesting apps and modifications that take advantage of Marshmallow’s new features. One in particular comes to us from XDA Member p0isonra1n, called Doze Settings Editor. With DSE, you can tweak the various rules that Doze follows to completely customize how it functions on your device.

Create Your Own Boot-LED Sequence On Sony Xperia SP

The Xperia SP has a beautiful LED bar on the device. Now, with XDA Senior Member Raienryu‘s help in the form of this guide, you can modify the illumination sequence of this LED bar during boot, allowing a greater level of personalization for the device!

Oppo Releases ColorOS v2.1.5i Stable Version For Find 7, To Now Focus On AOSP

Oppo has released a stable version of ColorOS ROM for the Find 7 and Find 7a. This update, marked as v2.1.5i, will the last ColorOS update for the Find 7 phones, with the team now shifting focus towards AOSP development.

The Importance of Open Source in Root

Honor 7 XDA Review: Polished Hardware, Unfinished Software

Friday, October 30, 2015

Who’s Down is a New Social Application by Google

Google has just quietly released a new social application into the Google Play Store called Who’s Down. This is a simple concept where you can instantly check to see if any of your friends are ‘down’ to do something. It does this with an on and off switch, but you can also customize it to say you are down to study, get lunch, etc.

XDA/Android Podcast Episode 5: “Battle of the X Phones, In Virtual Reality!”

The XDA/Android podcast will bring you the best news each week from the perspective of the XDA team, r/android mods, admins and users. Each week you can find our latest episode here, on Youtube, Pocketcasts and on your favorite podcast app through the RSS feed: http://ift.tt/1QXeF8c

On this week’s podcast, the few survivors of scheduling horrors discuss YouTube Red, the OnePlus X, Virtual Reality and the dreaded victory of form over function.

The winners of our Nexus giveaway are: Nate Meadows & Gabriel Fritz, we’ll be in touch over the weekend!!!

Today’s cast includes:

Mario Serrafero: Twitter
Daniel Marchena: Youtube
Mishaal Rahman: XDA Writer

Check Out XDA on Social Media. Twitter, Facebook and Google+

and don’t forget to pay a visit to r/Android!

Restore IMEI, Wifi & Bluetooth MAC on Xiaomi Redmi Note 2

XDA Senior Member Xmister has put together a guide on restoring the IMEI, Wifi MAC and Bluetooth MAC on the Xiaomi Redmi Note 2. Take a look and keep yourself prepared for any eventualities that may befall your device, or fix any that may have already!

Re-Unlock SIM and Stop PRL Updates on Sprint-based Moto X 2013

If you purchased a Moto X 2013 from Sprint, but used it unlocked on a different carrier, you may have received a recent update which SIM locks your device. To help such issues, XDA Member flopadmi has posted a guide based on his experiences which should help you to re-unlock the device and stop such PRL updates in the future.

Xperia Z5 and Z5 Compact Updated With Full Stagefright Fixes

Sony’s Xperia Z5, Z5 Dual and Z5 Compact have received a new firmware update which provides the full set of Stagefright fixes. The updates is ~281 MB in size, and also contains fixes for camera performance, heat management and increased accuracy from the fingerprint sensor.

OnePlus Announces Reflexion, a Photography App to Create Reflections Images

OnePlus Announces Reflexion, a Photography App to Capture Reflections

To help promote the OnePlus X, the Chinese OEM has just released a photography application called Reflexion for both Android and iOS. The application lets you take two photographs, one with the front camera and one with the back, and then it compiles the two photos into one single image with an ‘X’ type reflection effect.

Fabric Mobile Development Platform Introduces 8 New SDKS

Fabric, Twitter’s mobile development platform, allows developers to easily integrate third-party frameworks and libraries into their application. Although most commonly used for its Crashlytics support, Fabric maintains and updates a whole host of SDKs for use by mobile app developers. Fabric recently announced the introduction of 8 new SDKs to join the developer toolset. If you’re looking to develop an app and haven’t used Fabric before, check out their webpage to get started.

Learn How to Implement Material Design

Material Design, Google’s newer UI introduced in Lollipop, features colorful icons and beautiful animations. It’s a great design language for any developer to implement without having to spend much effort developing your own UI. But how do you implement Material Design for your app? Code-Labs has written up an excellent guide that will fill you in on all the basics and should only take around 2 hours of your time.

HTC Continues Struggling in Q3, Resulting in $137.63 Million Loss

2015 just has not been a great year for the Taiwanese handset maker HTC. Quarterly financial reports have been going out lately and HTC has just joined in with their numbers. In the third quarter of this year, HTC ended up losing $137 million dollars. This, compared to the $18.5 million in profit they had in Q3 of last year, is just not a good sign at all.

The LG V10 is Now Available at Verizon Wireless

If you’re a Verizon Wireless customer and you’ve been wanting to get the LG V10, then wait no more. The V10 is available on Verizon’s website as well as in most of their retail stores, and it is available in both Black or White color options. You can pick this device up for either $28 per month, with 0% APR financing, or you can pay $672 up front.

Google Executive Says They Are “Very Committed to Chrome OS”

Yesterday there was a report from the WSJ that said Google had plans to merge Chrome OS with Android. This was independently confirmed by both re/code as well as The Verge but the newly appointed head of Android and Chrome, Hiroshi Lockheimer, sent out a Tweet late last night saying they are still very committed to Chrome OS.

Chainfire Releases Root For Android 6.0 Without Modifying /system

If you have ever rooted a device, then chances are very good that you may have heard of Chainfire, XDA Senior Moderator and Senior Recognized Developer. In case you haven’t, Chainfire is the developer behind popular works like SuperSU, CF Auto Root, TriangleAway and CF.lumen, making him one of the most influential developer in the Android modding community.

We recently had reported on Chainfire’s decision to hand over SuperSU to Coding Code Mobile Technology LLC (CCMT), but noted that Chainfire will continue on SuperSU, eventually phasing himself out over the course of two years.

True to his word, Chainfire is still involved in SuperSU, and he has just released root for Android 6.0 Marshmallow without doing modifications to /system partition. This is being labelled as an experiment as the idea behind it has a few caveats, the major of which is that factory resetting the device will remove root.

To have root on modern Android versions, we need our files to be executable and our daemon to be started on boot. We normally do this by making modifications to /system, tapping into binaries and scripts executed by init. If we’re also modifying the boot image, then we should be able to do all this without modifying system at all.

So what benefits can we expect from a systemless root? We reached out to Chainfire, and the benefits of this over the traditional SuperSU include:

A cleaner approach and design
Easier unroot
An unlittered /system partition
Excludes things like “sugote”, which are not needed on Android 6.0 Marshmallow
OTA’s are slightly easier now, as reflashing boot image is usually a lesser hassle than reflashing an entire /system.
Most importantly, this does not soft brick your device if you do not have the correct kernel installation. Previous methods to root Android 6.0 required a SELinux policy patch in the kernel, without which, the device would not boot. With this method, if the supporting kernel is absent, you won’t have root but the device will boot.

This new method, as expected, does not work in cooperation with older root methods as the new method does not clean up old root files. Because of this, you need to reflash your stock /system partition to make sure you have a clean slate before starting off.

For downloads, please head on over to the forum post. The dev requests that discussions should happen over at the SuperSU Beta thread, so head on over there for general talk. Keep in mind this is experimental, and there will likely be bugs, so proceed at your own risk.

New Standards: Diving into the 6.0 Compatibility Definition Document

Marshmallow has seen the light of day on most Nexus devices already, but we’ve yet to see any third-party OEM update their phone to Marshmallow. How exactly will they incorporate Marshmallow’s new features into their specific flavors of Android?

It’s hard to say for sure, but thanks to the Compatibility Definition Document (CDD), we can be assured that OEMs won’t stray too far from stock Android’s implementation of the new 6.0 features.

Properly Roasting a Marshmallow

With each new version of Android, Google updates its compatibility guidelines to ensure a consistent user experience of all the new major features. From a user standpoint, it is vital that OEMs abide by the compatibility guidelines so that their favorite applications work consistently across all of their devices. Similarly, the developer benefits from having to expend less effort in targeting multiple devices if each device operates consistently on any given Android version. Finally, the OEMs benefit from the growth of the ecosystem as more users can justify buying their devices if more developers can justify developing for their devices. It’s a win-win situation for every party, and it’s in Google’s best interest to require any manufacturer building an Android device to abide by their compatibility guidelines.

How do they do that? Well, by controlling who gets a license to use Google Mobile Services (GMS), which consist of Google’s proprietary applications. OEMs looking to get their hands on a license for GMS have to abide by all of the requirements listed in the Compatibility Definition Document and pass the Compatibility Test Suite. Without access to applications like the Google Play Store, an OEM would have a very difficult time convincing people to invest in their ecosystem when the competition is so stiff.

The Ouya Game Store

Remember the Ouya Android gaming console? A large part of its failure can be tied to the lack of applications. Ouya just couldn’t convince enough developers it was worth investing their resources into porting their games, when they could instead continue targeting the lucrative Google Play Store. A few weeks after launch, Ouya revealed its “modest” sales data. After many months of unsuccessful attempts at penetrating the market, Ouya eventually sought to be bought out and was finally picked up by Razer in June.

Ouya instead sought to market to China, where Google has had trouble fighting the bureaucracy to get its services accepted by the country. Good timing, too, given Google’s recent push with Android TV.

In essence, OEMs depend on Google giving them a license to run Google Apps in order to compete with other Android devices. This has given Google an iron-grip on the Android ecosystem, and ensures that OEMs won’t stray too far from each the basic functionality of each new Android version. Even the mighty Samsung, who has invested heavily into Tizen, just can’t seem to dislodge the dominance of Android.

That being said, let’s dive into the Compatibility Definition Document for Android Marshmallow. It is absolutely packed with to the brim with useful information. Huge thanks to the team over at AndroidPolice for digging through and finding some of these, which I’ll use to summarize only the most pertinent bits.

Android Auto…motive? Google Drops Hints for the Future

First up, something interesting from the “Device Types” defined in Section 2.0.

Android Automotive implementation refers to a vehicle head unit running Android as an operating system for part or all of the system and/or infotainment functionality. Android Automotive implementations:

MUST declare the feature android.hardware.type.automotive.

MUST support uiMode = UI_MODE_TYPE_CAR

You might read this and think, “what’s the big deal? Don’t we already know about Android Auto?” And you’re right, we know plenty about the already announced Android Auto. However, Android Auto is just an app that anyone can just download. Google is referencing something entirely new here, and it’s referring to smart devices inside the car actually running a full version of Android. Many 2016 car models already run Android Auto, so who knows how long it will take for cars to ship with fully-fledged builds of Android OS.

Searching through the CDD, we can find multiple other references to Android Automotive, and piece together how Google intends the platform to function.

In Section 3.4.2 describing Browser Compatibility for instance, Android Automotive devices are listed as an exception to the rule requiring Android devices to ship with a standalone web browser. This makes sense, given the potential safety ramifications of users surfing the web while in a car.
According to Section 3.10, Android Automotive devices are strongly recommended to include Accessibility settings consistent with stock Android. This is likely done to allow consumers to enable the TalkBack feature (which I would guess most auto manufacturers would heavily emphasize anyways). Section 3.11 “Text Speech” further corroborates this notion by requiring the support of Android Text-To-Speech (TTS).
Next up, in Section 5.1.3 “Video Codecs” we see that Google strongly recommends any Android Automotive device support h265 High-Efficiency Video Codec (HEVC). This is interesting as it suggests Google is hoping for Android Automotive devices used as video consumption devices. Parents with kids will definitely find the ability to watch downloaded videos a boon.

Android “Automotive” – Using a Nexus 7 (Credits)
In Section 7.1.5, Google states that Android Automotive devices are the only devices not required to support legacy compatibility mode, meaning that any application designed without screen density independence will not be supported. You can imagine the frustration of any passenger trying to deal with a poorly scaled app while moving around in the car.
Android Automotive devices are not required to implement a soft keyboard, as mentioned in Section 7.2.1. Not surprising given that most people would expect to navigate such a device via touch or voice.
Under Section 7.2.3 “Navigation Keys”, Google states that the “Recents” and “Back” keys are not required, while the “Home” key is. You’re not likely to be navigating around the device very often, so I think Google was smart to not force OEMs to design their UIs around those two keys.
Android Automotive is not required to support OTA updates, as listed in Section 11. Since an Android Automotive device would only be able to update while the car is on, it makes sense not to require OTA support. It’s not like you can plug your car into the dock on your nightstand while it updates!

Professional Audio Devices – How Google seeks to reduce Audio Latency

We’ve covered previously how Marshmallow has reduced Audio Latency on most devices, but now Google had laid out a set of guidelines that if met, will easily allow developers to target certain devices sporting low latency audio.

5.10. Professional Audio

If a device implementation meets all of the following requirements, it is STRONGLY RECOMMENDED to report support for feature android.hardware.audio.pro via the android.content.pm.PackageManager class.

The device implementation MUST report support for feature android.hardware.audio.low_latency.

The continuous round-trip audio latency, as defined in section 5.6 Audio Latency, MUST be 20 milliseconds or less and SHOULD be 10 milliseconds or less over at least one supported path.

If the device includes a 4 conductor 3.5mm audio jack, the continuous round-trip audio latency MUST be 20 milliseconds or less over the audio jack path, and SHOULD be 10 milliseconds or less over at the audio jack path.

The device implementation MUST include a USB port(s) supporting USB host mode and USB peripheral mode.

The USB host mode MUST implement the USB audio class.

If the device includes an HDMI port, the device implementation MUST support output in stereo and eight channels at 20-bit or 24-bit depth and 192 kHz without bit-depth loss or resampling.

The device implementation MUST report support for feature android.software.midi.

If the device includes a 4 conductor 3.5mm audio jack, the device implementation is STRONGLY RECOMMENDED to comply with section Mobile device (jack) specifications of the Wired Audio Headset Specification (v1.1).

And there you have it. If an OEM wishes to build a device aimed at music lovers and music professionals, they can report that their device meets the “Professional Audio” requirements and signal to developers that their device is suitable to create music on.

Google Outlines Fingerprint Sensor Requirements

Android Marshmallow introduces system-wide fingerprint authentication, allowing you to secure your lock-screen and purchases using your finger. In order to be considered compatible with Marshmallow’s fingerprint implementation, OEMs must ensure that their fingerprint sensors follow specific requirements:

7.3.10. Fingerprint Sensor

Device implementations with a secure lock screen SHOULD include a fingerprint sensor. If a device implementation includes a fingerprint sensor and has a corresponding API for third-party developers, it:

MUST declare support for the android.hardware.fingerprint feature.

MUST fully implement the corresponding API as described in the Android SDK documentation.

MUST have a false acceptance rate not higher than 0.002%.

Is STRONGLY RECOMMENDED to have a false rejection rate not higher than 10%, and a latency from when the fingerprint sensor is touched until the screen is unlocked below 1 second, for 1 enrolled finger.

MUST rate limit attempts for at least 30 seconds after 5 false trials for fingerprint verification.

MUST have a hardware-backed keystore implementation, and perform the fingerprint matching in a Trusted Execution Environment (TEE) or on a chip with a secure channel to the TEE.

MUST have all identifiable fingerprint data encrypted and cryptographically authenticated such that they cannot be acquired, read or altered outside of the Trusted Execution Environment (TEE) as documented in the implementation guidelines on the Android Open Source Project site.

MUST prevent adding a fingerprint without first establishing a chain of trust by having the user confirm existing or add a new device credential (PIN/pattern/password) using the TEE as implemented in the Android Open Source project.

MUST NOT enable 3rd-party applications to distinguish between individual fingerprints.

MUST honor the DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT flag.

MUST, when upgraded from a version earlier than Android 6.0, have the fingerprint data securely migrated to meet the above requirements or removed. SHOULD use the Android Fingerprint icon provided in the Android Open Source Project.

Google is addressing some very important security concerns in this section of the CDD. With a maximum false acceptance rate of 0.002%, you can be rest assured that nobody’s finger but your own will be able to access your device. In addition, to ensure your fingerprint data is kept secure, developers can only access your fingerprint data using an API, and will not be able to tell the difference between multiple stored fingerprints. However, it’s a bit concerning that they only strongly recommend fingerprint sensors have a short latency between when the fingerprint sensor is touched and when it’s recognized, given how some devices seem to slowly react to your fingerprint.

Unmodified Doze Mode

Doze mode is Google’s answer to the plague of battery-destroying wakelocks. No longer can apps wake up in the background whenever they want to ping for new notifications, at least until you give it permission to. By default, Google sets most apps to be “optimized”, which means Doze mode will kick in when the device enters sleep mode. However, you’re free to prevent the app from being “optimized” if you wish to continue having the app ping for new notifications or sync data. To prevent any OEMs from messing with Doze mode (perhaps, to stop them from allowing you to disable Doze on any bloatware), Google is requiring OEMs to leave Doze mode entirely intact:

8.3. Power-Saving Modes

All apps exempted from App Standby and/or Doze mode MUST be made visible to the end user. Further, the triggering, maintenance, wakeup algorithms and the use of Global system settings of these power-saving modes MUST not deviate from the Android Open Source Project.

So you can be rest assured that you’ll have full control over what apps can trigger wakelocks on your device, no matter which device you purchase. In addition, you can be sure that Doze mode operates in the same exact way it would on a Nexus device thanks to Google laying down the hammer here.

Unmodified Battery Stats

Checking your battery stats under settings is a time-honored Android enthusiast tradition. It often served as a useful way to quickly find out what user apps were eating up most of your battery. However, in many cases you wouldn’t be able to figure out what hardware component triggered by certain apps was draining your battery. To do that, you would have to rely on apps like BetterBatteryStats which requires root to function properly. Now, Google is forcing OEMs to track and lay out the power consumption of all hardware components. No longer will a rogue system app hold a GPS lock without you knowing:

8.4. Power Consumption Accounting
A more accurate accounting and reporting of the power consumption provides the app developer both the incentives and the tools to optimize the power usage pattern of the application.

Therefore, device implementations MUST be able to track hardware component power usage and attribute that power usage to specific applications. Specifically, implementations:

MUST provide a per-component power profile that defines the current consumption value for each hardware component and the approximate battery drain caused by the components over time as documented in the Android Open Source Project site.

MUST report all power consumption values in milliampere hours (mAh)

SHOULD be attributed to the hardware component itself if unable to attribute hardware component power usage to an application.

MUST report CPU power consumption per each process’s UID. The Android Open Source Project meets the requirement through the uid_cputime kernel module implementation

MUST make this power usage available via the adb shell dumpsys batterystats shell command to the app developer

MUST honor the android.intent.action.POWER_USAGE_SUMMARY intent and display a settings menu that shows this power usage.

Developers, too, should rejoice, as Google requires this same information to be available via dumping the batterystats log. This should make debugging battery drain on applications much simpler.

Pre-Installed Apps can’t Bypass Permission Management

If you’ve already updated to Android Marshmallow on a Nexus device, you might be wondering why apps like Google Calendar need to request permission to access your calendar. Can’t that just be granted by default? Sure, it might make sense, but you have to remember that Google can’t go around pre-granting crucial permissions to each and every app that you think should be “trusted.” And Google can’t exactly afford to play favorites with any OEMs. Plus, it pays off for permission management to be so transparent. You’ll be training consumers to look out for permissions by introducing them to the concept from the very first apps they’re likely to interact with. From the CDD:

9.1 Permissions

Permissions with a protection level of dangerous are runtime permissions. Applications with targetSdkVersion > 22 request them at runtime. Device implementations:

MUST show a dedicated interface for the user to decide whether to grant the requested runtime permissions and also provide an interface for the user to manage runtime permissions

MUST have one and only one implementation of both user interfaces

MUST NOT grant any runtime permissions to preinstalled apps unless: the user’s consent can be obtained before the application uses it or the runtime permissions are associated with an intent pattern for which the preinstalled application is set as the default handler.

Google is being very strict here. Any apps which target SDK 23 and above (ie. apps made for Marshmallow) must provide an interface to grant/deny permissions on runtime. The only time a permission can be granted without user consent is if the user sets that application to be the default for that specific action (basically, if you set Google Calendar to be the default handler for Calendar events, you’re giving it permission to access your Calendar).

Full-Disk Encryption is Now a Requirement

When Lollipop was announced, Google unveiled support for full-disk encryption and shipped the Nexus 6 and Nexus 9 with encryption enabled by default. Yet, Google did not truly require device manufacturers to enable full-disk encryption, until now:

9.9 Full-Disk Encryption

If the device implementation supports a secure lock screen reporting “true” for KeyguardManager.isDeviceSecure(), and is not a device with restricted memory as reported through the ActivityManager.isLowRamDevice() method, then the device MUST support fulldisk encryption of the application private data (/data partition), as well as the application shared storage partition (/sdcard partition) if it is a permanent, non-removable part of the device.

For device implementations supporting full-disk encryption and with Advanced Encryption Standard (AES) crypto performance above 50MiB/sec, the full-disk encryption MUST be enabled by default at the time the user has completed the out-of-box setup experience. If a device implementation is already launched on an earlier Android version with full-disk encryption disabled by default, such a device cannot meet the requirement through a system software update and thus MAY be exempted.

What’s interesting is that Google has exempted devices sporting low amounts of memory, which makes sense as it would affect performance. According to the reference for the ActivityManager class, Google does not have a strict definition as to what constitutes a low RAM device, but leaves it up to the OEMs to determine. You’re unlikely to ever find a Marshmallow running device with such low end specs that it cannot support full-disk encryption, but Google does provide such an exception.

Another thing to note is that Google does not require full-disk encryption on any device upgrading to 6.0, only devices launching with 6.0.While unfortunate from a security standpoint, it can be somewhat justified given that many older devices do not support hardware based encryption and thus may suffer a performance hit if implemented. Many Nexus 6 owners opted to disable encryption in order to improve performance, after all.

How Would You Recommend Your Phone to Others?

Those who carefully plan a purchase often end up loving it. And those who are convinced they received the best bang for their buck, or the best experience, often want to share that, especially with those they deem worthy. How would you recommend your phone to other enthusiasts or to casual users? And to who would you recommend it?

OnePlus X Unveiled! 19″ Samsung Tablet?? Motorola Announces Droid Maxx 2 and Turbo 2 – XDA TV

OnePlus has unveiled the OnePlus X. That and much more news is covered by Jordan when he reviews all the important stories from this week from DroidCon in London. Included in this week’s news is the announcement of a new 18.4 inch tablet from Samsung called the View and be sure to check out the article talking about Motorola announcing the Droid Maxx 2 and Turbo 2. That’s not all that’s covered in today’s video!

Jordan talks about the other videos released this week on XDA TV. XDA TV Producer TK released an interviews with Swappa, Vinli and Chainfire with IonVR from the Big Android BBQ 2015. Then TK gave us a quick recap of the whole event. Also, Jordan gave us the next video in our Best Phones Under $100 series, this time talking about performance. Pull up a chair and check out this video.

Be sure to check out other great XDA TV Videos.

Stories mentioned:

Check out Jordan’s Tech Channel and Jordan’s Vlogging YouTube Channel

Win a Trip to China With Honor and XDA!

To celebrate Honor’s 2nd birthday in China, they are inviting two members of XDA to fly out to a fan party! The event will feature a showcase from Honor, fans and official partners, however also on the itinerary is a concert and extreme sports show! Winners, will fly out on the 11th of December and return on the 14th (subject to minor alterations), flights and accommodation are included and entrants must be from the UK. To enter simply fill out the form below.

Enter here:

Do you have any questions? Leave a comment below!

Thursday, October 29, 2015

Why Developers Shouldn’t Worry About App Standby

App Standby was introduced alongside Doze to improve user’s battery life. The feature intelligently restricts battery intensive background syncs and radios whenever an app is not in use. However, in contrast to Doze mode, App Standby still honors an app’s wakelocks and alarms. How is the feature triggered? The Android Developers Google+ page has laid out a general flowchart of when your app will enter standby and why you shouldn’t worry.

Using a fingerprint to Authenticate to Remote Servers

The release of Marshmallow brought with it the ability to use fingerprints to authenticate a user’s identity. If you’re a developer making an application that features online purchasing, then you might be interested in learning how to implement an asymmetric keypair in order to grab a public key to store in your server’s backend, allowing you to authenticate future purchases using only the customer’s fingerprint.

Report Suggests that Google Will Fold Chrome OS into Android

Reporst Suggests that Google Will Fold Chrome OS into Android

Multiple sources have told the Wall Street Journal that Google is planning on absorbing Chrome OS into Android and only having one operating system before the end of 2017. Microsoft has been doing something similar when it released Windows 10 that runs on both mobile and desktop device. This means that Chromebooks, which will get a new name, will eventually run Android out of the box.