A need for Android device compatibility branding

cloud_security.jpg

There always is tension between highly curated platforms like an Apple iPhone and an open system such as Android. The same argument was made to compare an Apple Macintosh with Microsoft Windows. What matters most? A wide range of choices (Windows or Android) or a narrow but predictable behavior (Mac or iPhone)? Must there be a trade-off? Why can’t an open platform also provide predictable behavior? Windows today pretty much has good compatibility across a range of apps (the sole exception probably being high performance games) but that was not always the case. Early days of Windows was fraught with unpredictable behavior ranging from device compatibility to app compatibility. That has mostly disappeared...

I feel that the Android ecosystem can benefit from some of the lessons learned in the early days of Windows, which is now an easy to navigate ecosystem, to understand app compatibility and capabilities. Here’s a spoiler: One can learn from Microsoft with the Multi-Media PC (MPC specifications).

A Concrete Example

I’ll provide a concrete example: I was looking at an app for video recording called FiLMiC Pro. Since it requires specific capabilities in the phone, the makers even created an evaluator app to test whether one’s phone is compatible. I tried to run the evaluator and noticed that the Google Play Store stated that even the evaluator is not compatible with my phone. I use a Motorola phone which has reasonable video capabilities. While not as capable as, let say, a Google Pixel 2, I thought it was sufficient to run the app. But that wasn’t the case, so I contacted FiLMiC’s support. 

What I discovered was that device compatibility is a function of adherence to Android API compliance. It’s not a simple matter of whether one uses a basic smartphone or a flagship phone. In the reply, I learned that while Google Pixel 2 and OnePlus 3T are 100% supported, Samsung devices, even the flagship editions, are not fully supported.

Investigating the API issue has shown to me that capabilities are often split into MUST, MAY, or SHOULD. Therefore, it’s impossible for mere consumers to understand precisely which capabilities are supported by which phone. In the case of FiLMiC Pro, it was an issue of compliance to the Camera API2 interfaces. Furthermore, Camera2 API interfaces has three support levels: legacy, full, and limited.

How can anyone understand that? You buy a phone and expect most apps to work. How can we solve this quandary?

One solution is to require all phones to be at the full level but it does not make sense to support a set of devices ranging from basic to flagship that one expects from the Android ecosystem. The choice of price points is precisely what led to its wide adoption in developing as well as wealthy countries and one cannot force all phones to be full fledged flagships.

Instead we are currently forced to understand which apps to run (VR or a fancy camera app) and then choose the right phone using many methods including reviewing review web sites, application FAQs, vendor websites, and so on. This is all likely to lead to errors. Even today, those who want to get a VR Daydream compatible device need to look up a list of devices on https://vr.google.com/daydream/smartphonevr/phones/ to know which products are compatible.

However, what I do want is a trustworthy indicator of capabilities, much like the old Microsoft MPC label that drew people in with a notion of trust. Nobody talks of MPC today, but back in the day, it was a way for people to choose PCs because it enabled playing CD-ROM apps, for example.

Why can’t Android do that same? It can create a “Video and Image Creators Edition” to list full Camera API2 compliance or it can be as simple as stating the different support level of Camera API2.  While that may map to developers' notions of support levels, I find it rather unsatisfactory from the consumer’s perspective since we’re no longer talking about apps, but APIs, which most people don’t care about.

Until this type of issue is resolved, I can understand how many people are drawn to a well known ecosystem like the iPhones. Does this mean that I will get something like the Google Pixel the next time I upgrade, or even consider switching to an iPhones? It’s hard to tell, and I hope this app compatibility challenge was a one-off. For the time being iPhones present a predictable experience, and while Android has many capabilities, the wealth of choices causes confusion. I hope a set of predictable branding, much like MPC, can create order out of this.

Finally, why am I, as a cloud infrastructure and networking analyst writing about this? I see strong connections to platform capabilities in the cloud as well, with particular emphasis on support for open APIs. That will be a topic for another blog.

Additional background information for those want to delve into details

There are clear definitions of the Android Compatibility Definitions. https://source.android.com/compatibility/cdd so I am not arguing about that. While it is precise, there is not analogue to enable consumers to make an easy choice.

Here’s some background from https://source.android.com/compatibility/android-cdd#7_5_cameras and https://source.android.com/devices/camera/versioning

I copy an excerpt here:

"The android.info.supportedHardwareLevel property that apps can query through the Camera API2 interfaces reports one of the following support levels:

  • LEGACY. These devices expose capabilities to apps through the Camera API2 interfaces that are approximately the same capabilities as those exposed to apps through the Camera API1 interfaces. The legacy frameworks code conceptually translates Camera API2 calls into Camera API1 calls; legacy devices do not support Camera API2 features such as per-frame controls.
  • FULL. These devices support all of major capabilities of Camera API2 and must use Camera HAL 3.2 or later and Android 5.0 or later.
  • LIMITED. These devices support some Camera API2 capabilities (but not all) and must use Camera HAL 3.2 or later."

Here’s what FiLMiC wrote:

"Thank you for writing in. The Evaluator is designed to be incompatible with devices that FiLMiC Pro does not support. That way you don't even have to download the app and run an evaluation in order to determine whether your device is supported.

The Android specification allows for two api's for camera functionality. Camera1 was the earlier spec and contains less capabilities, especially with respect to manual control over the camera settings such as focus and exposure. Camera2 is the newer spec and allows for greater functionality including manual controls. 

FiLMiC Pro requires camera2 compliance so that we can offer support for all of the capabilities that customers expect from FiLMiC Pro.

Unfortunately your device is a camera1 device. It is unlikely that your device will be able to support FiLMiC Pro in the future. We have never seen an instance where a device has been upgraded to support the newer camera2 api once it has been released on the market. 

Here is a fairly up to date list as to where things currently stand on Android:

  • Google Pixel 2 and OnePlus 3T: 100% supported
  • Google Pixel 1: optical stabilization not working, auto focus not working perfectly
  • Galaxy S8 and Note8: no 1080p@60fps, auto focus not working perfectly fine, dropped frames at 4K
  • Galaxy S7: no 1080p@60fps
  • LG Devices: no manual ISO/Shutter but exposure compensation, no 1080p@60fps, auto focus not working perfectly fine
  • Sony devices and the OnePlus5 are not supported due to errors in their camera framework implementation.

In addition please take into account that some models have many different implementations, so they don't work exactly the same way. Also, frustratingly, these "issues" depend on the manufacturers' implementation, because not all of them follow the Android Guidelines for Camera API2.

On the other hand regarding the Samsung devices, we were told at its Developers Conference a few weeks ago that they're working on fixing those issues, but it won't be available for third party apps until 1Q 2018."

 

Topics: Cloud Services & Orchestration