Our app contains a MediaBrowserService and uses a whitelist to restrict who can can query the service. It is typically used to permit Android Auto and Android Wear to query our app for audio content. As far as I know, this is still a recommended approach. For example, as shown in this Google sample app: MediaBrowserService sample app
Our app reports the package names that try to query our MediaBrowserService but are NOT on the whitelist. We fairly regularly receive reports that "com.android.bluetooth" tried to call our service and was denied.
I'm perplexed by these reports. We've never seen such calls from this package on our own test devices. My previous attempts to ask the user if they have a Bluetooth device that might be displaying audio information has been met with confusion...so it seems perhaps Android itself is making these calls?
Has anyone else encountered this? This whitelist approach requires validating specific signing certificates. Does com.android.bluetooth have a consistent signing certificate that can be used to add this package to the whitelist?
UPDATE 1:
Looking at the reports we have received from users, this appears to be exclusively a Samsung Android 6.0.1 phenomenon. The first report of it showed up on 3/13/2016 and there has been a steady trickle all summer.
Here's a partial list of the models that have reported this issue. All of them have had Android 6.0.1. Could this be related to their Tizen-based Galaxy Gear watches?
UPDATE 2:
I have finally reproduced the situation on a Galaxy S6 Edge with 6.0.1. Bluetooth on the device simply has to be turned on. If turned on, with nothing even paired or connected, when I start playing audio in our app "com.android.bluetooth" (UID 1002) calls onGetRoot and onLoadChildren on our MediaBrowserService. WHY!? If I allow it, nothing visible changes on the device. I thought I might see some Samsung widget presenting the media info from our app...but I don't.
I stumbled upon an answer, of sorts. For reasons only someone at Samsung probably knows, the MediaBrowserServiceCompat.onGetRoot call by package "com.android.bluetooth" relates to MediaSessionCompat.setMediaButtonReceiver.
If you are using MediaSessionCompat in a manner explained by the documentation for Using media buttons to restart an inactive media session, these Samsung devices are querying MediaBrowserServiceCompat.onGetRoot with the com.android.blueooth package before media button events are sent to the BroadcastReceiver configured by MediaSessionCompat.setMediaButtonReceiver when Android attempts to revive the last active MediaSession.
If the call to onGetRoot returns null because you haven't whitelisted the com.android.bluetooth package, your BroadcastReceiver will NOT receive media button events and the inactive media session won't be revived. You can either fully whitelist the package and return your normal BrowserRoot of real data or return an empty BrowserRoot. For example, new MediaBrowserServiceCompat.BrowserRoot("myroot", null). Samsung doesn't appear to actually use the root data or make subsequent calls to MediaBrowserServive.onLoadChildren so it doesn't seem to matter what you return in response to onGetRoot calls made by com.android.bluetooth, it just can't be null.
Again, this situation seems to be unique to Samsung's 6.0.1 Android builds. I have not encountered any other devices or any other Samsung Android builds that perform this curious call by com.android.bluetooth.