Couldn't find "showallaccessories" entitlement

Issue:

The message, "Couldn't find the com.apple.private.externalaccessory.showallaccessories entitlement" is displayed to the device console upon reaching the first instance of "EAAccessoryManager.SharedAccessoryManager" when run on an iOS 10 device. This issue is exclusively reproducible on iOS 10 devices.

This has been tested with the latest stable and beta channels of Xamarin studio, Xcode 7.3.1, Xcode 8 beta 6, and in combination with the iOS 9.3 and 10.0 SDK's. The action that I've taken to attempt to resolve this issue include adding "Wireless Accessory Configuration" to the entitlements file, in an attempt to include the needed entitlement.


Configuration:

iPad(MGL12LL/A) - iOS 10 beta 8


Reproduction:

1. Include reference to "ExternalAccessory" assembly

2. Create an instance of a "EAAccessoryManager.SharedAccessoryManager"

3. See device console output


Objective-C:

EAAccessoryManager *mgr = [EAAccessoryManager sharedAccessoryManager];

C#:

EAAccessoryManager mgr = EAAccessoryManager.SharedAccessoryManager;


I have created a sample application in Xamarin and Xcode that can be provided upon request for reproductibility purposes.

I'm facing exactly the same issue and I've tried all solutions to solve it too with no luck. I think I will fill in a another radar because this should be an iOS 10 release issue.

Anybody figure this out? This is a real show stopper at my company

Hi Guys,


I had fixed this issue putting in the pList file the name exactly how in the validation is in the code (with or without uppercase).


In iOS 10 I think they are truly locking down down app/external accessory communication. The protocol strings that are specified with the accessory and in the app must match. If one or the other isn't specified, most likely no dice.


In my case, both the accessory and the app were specifying the protocol string but it seems like the the string comparison is case sensitive. My app protocol string was all lower case. I changed it to match the accessory (which had some capital letters in it) and it seems to work now.

Can you give us an example of this? I'm not sure what you're saying should be added to the plist. And what exactly is the code you are using when defining the accessory manager?

I believe the mentioned .plist section is titled "Supported external accessory protocols" and you're expected to put a case-sensitive protocol string in there provided (I'm assuming) by the hardware manufacturer. I'm trying to get a Koamtac Barcode scanner to work, so I've emailed their support and I'm waiting to hear back.

Cuold you please post your radar id, I would like to dupe this.

Did you guys ever resolve your issue? I've tried all of the suggestions in this thread but nothing is helping

It looks like you have two issues.


*Couldn't find the "com.apple.private.externalaccessory.showallaccessories" entitlement


The above is your first issue. I am experiencing the same issue in iOS 10 only. Has anyone figured out a solution to this problem? I cannot find anything on this elsewhere on the internet.

Ditto...any updates from anyone? I'm still dead in the water here, running iOS 10.1.1. I've tried every suggestion I found (both here and on Stack Overflow) with no luck.

I don't believe the supported-protocol string (or case-sensitivity thereof) is the problem for those of us seeing the "couldn't find ... entitlement" log message when they first try to call anything on sharedAccessoryManager. You should still be able to poll the manager for connected devices as well as receive the notifications, right? That was the case last time I worked with this framework (admittedly a couple of years ago) and I don't see anything in the docs about it only returning accessories with matching protocol strings.

I just became aware of this posting and have the following response.


I hate to be the bearer of bad news, but I can explain this issue. Actually, there are 2 changes in iOS 10 leading to similar consequences.


Issue 1. With iOS iOS 10.x a security requirement was mandated that for an application to work with an accessory (to be notified of the attachment or removal of the accessory), the application must demonstrate that it knows something about the accessory. The requirement is now that the application must include the protocolString registered by the accessory, in the UISupportedExternalAccessoryProtocols property in the Info.plist of the application. This demonstrates that the application knows something about the accessory.


When the application has linked with the External Accessories framework but does not have the protocolString registered by an attached accessory, a debug string accidentally left in the iOS 10.0 build fires - resulting in the log statement "Couldn't find the "com.apple.private.externalaccessory.showallaccessories" entitlement". The "com.apple.private.externalaccessory.showallaccessories" entitlement is an internal iOS engineer entitlement and has never been available outside of iOS engineering. For iOS 10.1, the log statement has been removed.


It might seem that the answer is to include the accessory's protocolString in the app's UISupportedExternalAccessoryProtocols property. This will work in a development version of the app. However on submission of the app to App Review, all apps with a UISupportedExternalAccessoryProtocols are checked to see if the application bundle ID has been approved by the accessory vendor. (This is not a new limitaton) If the bundle ID has not been whitelisted, the app is rejected. The solution is to contact the accessory vendor and have them whitelist the app bundle ID with the accessory.


Another issue here is that some accessories - like the Apple Camera adapter do not include a protocolString - these accessories can't be matched.


Both limitations affect applications which want to detect the accessory attachment and obtain the device information from the accessoryInfo structure to notify the user that the accessory has been attached.


Issue 2. iOS 10 was implemented so that the protocolString check is case sensitive. The effect is the same as issue 1, the accessory is not notified of the accessory attachment. This was not a requirement in earlier releases of iOS. If the application was able to open an EASession in iOS 9, I suggest that you verify the case of the protocolString registered by the accessory.


For those of you who would like to request a change to this policy I suggest using the Apple Developer Bug Report Web Page to submit an enahncement request. http://bugreport.apple.com


rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

Clarification on the Enhancement Request comment at the end. The change was implemented for security reasons. If you submit an enhancement request please describe the application utility you are trying to achieve. All bug report as well as enhancement requests are reviewed by the engineering and product managers as they determine which issues to prioritize to address.


rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

Does anyone experienced a problem that accessory does appear on the Picker( by calling ShowBluetoothAccessoryPicker method ) for a few seconds and disappears?

Couldn't find "showallaccessories" entitlement
 
 
Q