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
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.
from xda-developers » xda-developers | New Standards: Diving into the 6.0 Compatibility Definition Document http://ift.tt/1GBiqQn
via IFTTT
Aucun commentaire:
Enregistrer un commentaire