Not to be one-upped by the likes of Google, Amazon, or Apple, Samsung introduced its own virtual assistant service called “Bixby” ahead of the release of the Samsung Galaxy S8/S8+. At launch, Bixby was rather incomplete especially since the voice command feature took several weeks to roll out, but Samsung is continuing work on Bixby with a promise of greater functionality, availability, and openness. While we have seen hints at how Samsung might further integrate Bixby with its Samsung Experience UX in the upcoming Galaxy S9, we have recently learned of a totally unintended, yet hilarious, “feature” in Bixby: interfering with an obscure baseball card tracking app.
The open source application, called “Baseball Card Tracker,” is available for free from the Google Play Store. It’s a fairly simple app for a pretty niche audience of users. It doesn’t have a beautiful Material Design interface, but it doesn’t really need to because it gets the job done for its users.
Baseball Card Tracker Lite (Free, Google Play) →
The developer of the application recently upgraded his smartphone to the Samsung Galaxy S8, but was perplexed when he discovered that his simple application would not install on his new phone. Now, a regular user might fire off an angry email at a developer, but a developer would connect to their phone via ADB and collect a logcat to diagnose the problem. So what did he discover?
His Baseball Card Tracker app fails to install on his new Galaxy S8 because it is trying to declare a permission, called bbct.android.lite.permission.READ, which is already owned by a package called com.samsung.android.bixby.agent (also known as Bixby Voice). Let’s break this down some more.
What’s going on?
Every Android application has what is called a “Manifest” which is an XML file that contains a list of activities, receivers, services, and a list of permissions that the app can declare. What we’re concerned with are the permissions defined in the Manifest. An application can either declare which permissions they would like to use (<uses-permission> tag) or they can define their own custom permissions (<permission> tag) that other apps must declare before they can call that app.
For example, if an application wants to read the contacts on your device, the app must declare the android.permission.READ_CONTACTS permission in its Manifest.
<uses-permission android:name="android.permission.READ_CONTACTS"/>
By declaring this permission, an application can then read your device’s contacts database. Note that since this is considered a “dangerous” permission, starting in Android Marshmallow the developer has to request this permission be granted at runtime rather than at installation.
Now consider the case where an application developer might want to implement a custom permission. The popular automation app called Tasker implements a permission called net.dinglisch.android.tasker.PERMISSION_RUN_TASK which other apps must declare in their Manifest before they are allowed to directly run Tasker’s tasks or actions.
<permission android:description="@string/permission_descr_run_tasks" android:label="@string/permission_label_run_task" android:name="net.dinglisch.android.tasker.PERMISSION_RUN_TASKS" android:protectionLevel="normal"/>
The Baseball Card Tracker app in question also implements a custom permission which is named bbct.android.lite.permission.READ. This is done so another app of theirs can declare this permission and then read the card tracking database of the user.
The Problem
The same permission cannot be declared by two different apps. For whatever reason, Samsung’s Bixby Voice application is declaring the same permission that the Baseball Card Tracker app is attempting to declare for itself. However, since Bixby Voice is already pre-installed on the Galaxy S8, this means that the Baseball Card Tracker app cannot use the same permission name.
Samsung Bixby Custom Permissions
Line 9: <permission android:name="com.samsung.android.bixby.agent.permission.READ_LANGUAGE" android:protectionLevel="signatureOrSystem"/>
Line 10: <permission android:name="com.samsung.android.bixby.agent.permission.WRITE_LANGUAGE" android:protectionLevel="signatureOrSystem"/>
Line 11: <permission android:name="com.samsung.android.bixby.agent.permission.ACCESS_SETTING" android:protectionLevel="signatureOrSystem"/>
Line 12: <permission android:name="com.samsung.android.bixby.agent.permission.BIXBY_SERVICE_AVAILABLE_CHANGE" android:protectionLevel="signatureOrSystem"/>
Line 13: <permission android:name="com.samsung.android.bixby.agent.permission.GET_SERVICE_ID" android:protectionLevel="signatureOrSystem"/>
Line 14: <permission android:name="com.samsung.android.bixby.apphome.permission.CONTENT_SYNC" android:protectionLevel="signatureOrSystem"/>
Line 15: <permission android:name="com.samsung.android.bixby.apphome.READ_PERMISSION" android:protectionLevel="signatureOrSystem"/>
Line 16: <permission android:name="com.samsung.android.bixby.apphome.WRITE_PERMISSION" android:protectionLevel="signatureOrSystem"/>
Line 17: <permission android:name="com.samsung.android.bixby.apphome.permission.VIEW" android:protectionLevel="signatureOrSystem"/>
Line 82: <permission android:name="com.samsung.android.bixby.permission.WAKEUP_LAUNCH_BIXBY" android:protectionLevel="signatureOrSystem"/>
Line 83: <permission android:name="com.samsung.android.bixby.ACCESS_SERVICE" android:protectionLevel="signatureOrSystem"/>
Line 84: <permission android:name="com.samsung.android.bixby.agent.permission.RECEIVE_BIXBY_VIEW_STATE" android:protectionLevel="signatureOrSystem"/>
Line 85: <permission android:name="com.samsung.android.bixby.agent.permission.READ_LEARNING" android:protectionLevel="signatureOrSystem"/>
Line 86: <permission android:name="com.samsung.android.bixby.agent.permission.WRITE_LEARNING" android:protectionLevel="signatureOrSystem"/>
Line 87: <permission android:name="bbct.android.lite.permission.READ"/>
Line 88: <permission android:name="com.samsung.android.bixby.agent.permission.TEXT_TEST" android:protectionLevel="signatureOrSystem"/>
Line 89: <permission android:name="com.samsung.android.bixby.agent.permission.LAUNCH_BIXBY_VOICE" android:protectionLevel="signatureOrSystem"/>
Line 90: <permission android:name="com.samsung.android.bixby.agent.permission.BIXBY_SIMULATOR" android:protectionLevel="signatureOrSystem"/>
Line 91: <permission android:name="com.samsung.android.bixby.permission.BIXBY_DICTATION" android:protectionLevel="signatureOrSystem"/>
Line 92: <permission android:name="com.samsung.android.bixby.agent.permission.BIXBY_ALARM" android:protectionLevel="signatureOrSystem"/>
Line 93: <permission android:name="com.samsung.android.bixby.agent.permission.READ_APPCHOOSER" android:protectionLevel="signatureOrSystem"/>
Line 94: <permission android:name="com.samsung.android.bixby.agent.permission.WRITE_APPCHOOSER" android:protectionLevel="signatureOrSystem"/>
Line 95: <permission android:name="com.samsung.android.bixby.permission.WAKEUP_SUGGEST_SENSITIVE" android:protectionLevel="signatureOrSystem"/>
Line 96: <permission android:name="com.samsung.android.bixby.agent.permission.BIND_AGENT"/>
Line 97: <permission android:name="com.samsung.android.bixby.agent.permission.READ_PERMISSION"/>
Line 131: <permission android:name="com.samsung.android.bixby.bridge.provision.READ_PERMISSION" android:protectionLevel="signatureOrSystem"/>
Line 132: <permission android:name="com.samsung.android.bixby.bridge.provision.WRITE_PERMISSION" android:protectionLevel="signatureOrSystem"/>
Line 160: <permission android:description="@string/permission_description_em" android:label="Bixby Agent Service Access Permission" android:name="com.samsung.android.bixby.agent.permission.BIXBY_AGENT" android:protectionLevel="signatureOrSystem"/>
Line 161: <permission android:description="@string/permission_description_es" android:label="@string/permission_label_es" android:name="com.samsung.android.bixby.agent.permission.APP_SERVICE" android:protectionLevel="normal"/>
What makes this all the more confusing is why the Bixby app is declaring this permission at all! If you decompile the app and take a look at all of the custom permissions that Bixby declares, all of them except for one follow the “com.samsung.android.bixby” naming convention. That exception is of course the poor developer’s Baseball card app.
Commonsware (who first pointed out his hilarious mishap) seems to think the cause is that some developers at Samsung copied code snippets from Stack Overflow. The developer of the app in question posted snippets of his code back in 2013, but has since edited it to genericize the post. We’re unlikely to find out an exact reason why this interference happened, however. It’s possible, but highly unlikely, that it was a total coincidence.
What now?
This ultimately has absolutely no effect on any average user. Sure, it might affect the few users of the app who own a Samsung Galaxy S8, S8+, Note8, or who wish to own the upcoming Galaxy S9/S9+, but the fix is relatively simple. For the developer, he would need to rename the permission in his Manifest (or get rid of it entirely) so his app no longer “interferes” with Samsung Bixby. Of course, it isn’t his fault that this is happening in the first place, but he has little recourse in the matter.
Commonsware argues that this little mishap is a great example for why developers need to check their Manifest before shipping an app. I recommend you read his blog post for more details on that, but I just wanted to share this ultimately inconsequential story because of its absurdity. The poor developer!
from xda-developers http://ift.tt/2Ec2t3g
via IFTTT
Aucun commentaire:
Enregistrer un commentaire