when I import the GameSparks SDK for Unity3D and generate an Android APK the APK starts to require the permission "READ_PHONE_STATE" which is not acceptable for me. Has anyone seen this problem? Is there a workaround for this or why does GameSparks need this permission?
Reproduction is pretty easy: Create empty Unity 5.3.2 project, import GameSparks SDK, set some random numbers in settings, create APK and run "aapt.exe d permissions <apk name>" to list the permissions needed.
Does this only happen with the GameSparks SDK imported into the project ? What version of the SDK are you using ? I haven't heard of this before and from searching around it seems to be something Unity themselves have added. We'll look into this some more for you and get back to you, in the meantime I did find this post on the Unity forums which may be of use to you.
This happens because you have DeviceId = SystemInfo.deviceUniqueIdentifier; in PlatformBase.cs. We replace this with an id of our own each time we update GameSparks. We currently don't use the DeviceAuthenticationRequest, so the DeviceId isn't that important for us. Any other SystemInfo.deviceUniqueIdentifier also adds the permission.
More importantly... In my tests (with a somewhat older version of Unity), in Android 6, if the user doesn't give that permission, SystemInfo.deviceUniqueIdentifier; will just return 00000. This would cause problems if you're using DeviceAuthenticationRequest. I don't know what happens when using Unity 5.3 though.
What do you use instead of SystemInfo.deviceUniqueIdentifier? - A lot of people with Android 6 say no to the READ_PHONE_STATE permission request (or even worse, don't download the app in the first place because a game asking for phone permissions looks dodgy), so using DeviceAuthenticationRequest no longer works.
Yes, using SystemInfo.deviceUniqueIdentifier isn't a good idea at all. Even before 6.0, it just returned "0" for some devices in some cases, so we had some users connecting to the same account.
You can look into this:
You'll need to store the returned value somewhere, and use that for subsequent calls (so this is a bit of a security issue to consider)
You might also want to have a backup in case Guid.NewGuid doesn't work correctly on some rare devices, because I think that also depends on some values that it needs to get from Android, though not requiring any permissions (e.g. you can use a combination of timestamps and device type, etc.)
Thanks! I've decided to use what Google's recommendation, Settings.Secure.ANDROID_ID from here - it's still not perfect, but it doesn't require any permissions and seems like a good alternative.
In case this is useful to anyone, I'm using the following to replace DeviceId = SystemInfo.deviceUniqueIdentifier.ToString();in PlatformBase
AndroidJavaClass androidUnityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer"); AndroidJavaObject unityPlayerActivity = androidUnityPlayer.GetStatic<AndroidJavaObject>("currentActivity"); AndroidJavaObject unityPlayerResolver = unityPlayerActivity.Call<AndroidJavaObject>("getContentResolver"); AndroidJavaClass androidSettingsSecure = new AndroidJavaClass("android.provider.Settings$Secure"); DeviceId = androidSettingsSecure.CallStatic<string>("getString", unityPlayerResolver, "android_id");
Most mobile game developers can relate here I guess.
It would be nice to have this build in the SDK.
Yes, it would be very nice when we wouldn't need the READ_PHONE_STATE permissions. Any news on this?
Sound like we are going to have a lot more problems when unity 5.4 comes out:
It would be nice to get some feedback from the GS developer team. Is this problem something you will address in future?
If this is now marked as solved, does that mean the latest version of the API has been changed, or that the OP found a hacky work around so the problem is going to be ignored now?
This really needs a solution, and this thread really needs some communication.
I'm not sure how this thread got marked as solved but I'm happy to look into this some more. If you have any specific questions you'd like addressed just let me know.
Excellent, thanks. Good to know it's still on the radar.
Apologies for being a bit aggro about it. Having a bad week and this was starting to feel like the icing on the angry cake.