Fragmentation has been a contentious issue in Android quite literally since the mobile operating system was announced.
Apart from being a cudgel for trolls to use in online flame-wars, the diversity that comes with fragmentation is now largely seen as a net positive for consumers of Android devices. After all, we’re given so much freedom in choosing the kind of device with the kind of software we want that it’s hard for the average consumer to care about fragmentation. Visualizing the incredible variety of Android devices produces a beautiful mosaic of Android’s diverse representation.
An Example of Android Device Fragmentation based on App Installations of OpenSignal’s app. Source: OpenSignal
But hardware and software fragmentation doesn’t make for a happy software developer. In fact, quite the opposite. Developing an app across so many different hardware and software configurations can prove to be a major nuisance when debugging. OEMs can make major or subtle changes that need to be accounted for when developing an app, but there’s really no easy way for the individual developer to ensure that their app will work universally. While the average consumer has long since forgotten about the fragmentation debate, the issue still haunts Android app developers and there’s seemingly nothing to do about it except suck it up and deal with the errors as they appear.
The Sorry State of Fragmentation
One OEM in particular receives a large portion of hate for the headaches they cause when developing an app — Samsung. Developers have been ranting about Samsung for years now, some even writing such scathing pieces as “There is a Special Place for Samsung in Android Hell” which describes a particularly frustrating bug stemming from Samsung devices and the support appcompat library. I would like to draw attention to one paragraph in particular from Mr. Ambri’s rant, which excellently outlines why developers still care about fragmentation:
If you are an Android developer, your hatred for Samsung devices is probably boundless. More than an average user, for whom Samsung is synonymous with silly Touchwiz and excessive bloatware, you despise Samsung because you don’t have a choice. Because of Samsung’s massive market share, you simply cannot choose not to support Samsung devices. And that’s what hurts the most; the fact that this choice is taken away from you!
This is not a rant from the olden years of Android’s existence either – this post was published in the middle of December last year. I will be upfront and state that I’m not sure if this issue has been officially fixed yet, however, Mr. Ambri has provided a fix in his post for anyone who stumbles across his rant via a Google search for the bug. All you have to do is use ProGuard with the following single line of code:
# Samsung ruining all nice things
-keep class !android.support.v7.view.menu.**,
!android.support.design.internal.NavigationMenu,
!android.support.design.internal.NavigationMenuPresenter,
!android.support.design.internal.NavigationSubMenu,
android.support.** {*;}
That’s not so bad, now is it? The problem, though, is that this fix was pulled off of Stack Overflow. Don’t get me wrong, Stack Overflow is a great website. But it’s not really an ideal source for discovering fixes for your apps. Finding something on Stack Overflow often involves diving deep through links after many trial-and-error Google searches. Sometimes you’ll even find another user mention the same bug you’ve been having, but without a fix in sight. Or even more frustrating are the times when you find a thread where the original poster has claimed to have found a fix but they’ve long since abandoned their thread without instructing others how to fix the issue.
Source: XKCD
An Example of a Subtle Fragmentation Issue
I’m not a developer myself, but I am familiar enough with the capabilities of Android after years of tinkering in Tasker that I’ve started pseudo-programming my own solutions to problems I’ve faced. And when I can’t figure something out, I Google it, just like everyone else does. While I was in the process of writing up my previous article about digging around your phone’s Settings app for hidden activities, I came across a rather odd bug that I could not explain. A bug unique to Huawei devices.
Whenever I tried to start certain activities (such as the “Testing” menu that contains app usage statistics) within the Settings app, I would always be met with a permission error. In particular, the app I was using to start the activity was lacking the permission huawei.android.permission.HW_SIGNATURE_OR_SYSTEM. No other device I tested required any unique permissions to launch these Settings activities, only phones running Huawei’s version of Android (EMUI). An analysis of com.android.settings revealed that certain activities within the Settings app was indeed under a protection level that required either the signature or system permission.
Unfortunately for me, this means that only apps installed under /system or apps signed with the same signature as the Settings app would be able to open these activities using the method I was attempting. When I Google searched this error for an answer, I (you guessed it) came across a Stack Overflow thread. The developer posting his problem came across the same issue that I did (although, his was in the process of actually developing an app). His problem came about when he attempted to run the following code:
Intent mainIntent = new Intent(Intent.ACTION_MAIN, null);
mainIntent.addCategory(Intent.CATEGORY_LAUNCHER);
Intent pickIntent = new Intent(Intent.ACTION_PICK_ACTIVITY);
pickIntent.putExtra(Intent.EXTRA_TITLE, "Pick App to Play in");
pickIntent.putExtra(Intent.EXTRA_INTENT, mainIntent);
this.startActivityForResult(pickIntent, REQUEST_PICK_APPLICATION);
Judging by the strings in the intent and the developer’s web page, he was likely trying to allow the user to pick a third-party app to play some media in. The fix, provided by veteran developer CommonsWare, was quite simple: use Intent.CreateChooser instead of ACTION_PICK_ACTIVITY. However, why should we need to implement this fix? Why is Huawei requiring this permission in the first place? Why did we need to find an answer on StackOverflow by using a very specific Google search?
The Paradox of Choice
To find an answer, CommonsWare filed a bug report on the Android bug tracker requesting that Google look into the issue. In particular, the developer requested that Google bar undocumented permission requirements from restraining third-party apps from accessing ACTION_PICK_ACTIVITY. By writing in these requirements in CTS, Huawei would be forced to comply with these changes.
To be honest, though, this bug itself really isn’t a big deal. Even though no other app I’ve tried (such as Tasker) was able to get around this permission requirement and launch certain activities within the Settings app, I wasn’t exactly disappointed by the outcome. But when I remembered the rant by Mr. Ambri, I realized that small changes such as these must be very frustrating to deal with, especially because as tiny as they might be, they undoubtedly add up, sometimes enough to cause a headache. One tiny change to the Settings app could result in an undeserved negative review against a developer. One tiny change that is rather poorly documented and required me to scour the Internet for a Stack Overflow thread. How many other small bugs are there on other devices?
Increased competition in the mobile space has proven to be great for the consumer, but after seeing how these subtle changes across so many different product lines can affect developers, I’ve grown to appreciate the developer view towards fragmentation. It isn’t that the choice itself is the problem, but rather that the community isn’t doing enough to catalogue these issues. As Mr. Ambri suggested in his article, perhaps Android developers need their own version of caniuse.com or sdkcritic.com to collect all of the obscure bugs into one database. The only other alternative is getting OEMs to either properly document these changes or stop making them in the first place, but good luck with that.
Feature Image Credits: OpenSignal
0 comments:
Post a Comment