READ_PHONE_STATE permission added when using SDK tools 26.0.2

Unity Engine
,
1

I’ve updated Android SDK tools to 26.0.2, and now game builds ask for READ_PHONE_STATE permission (and READ_EXTERNAL_STORAGE also). Switching back to 25.2.3 solves the problem. But, I would like to use latest SDK tools.

This issue is also listed in Unity Issue Tracker: Unity Issue Tracker - [Android] READ_PHONE_STATE permission is added in the AndroidManifest.xml file using latest (26.0.2) SDK

Do you know how can we fix it?

EDIT: The issue has been solved after I added
to everyplay manifest.xml file

3 Likes
Remove permission access phone in game (Android)
Auto Add read_phone_state since Android SDK 26
2

this worked for me. Thanks for sharing

3

Worked for me as well.
Thanks

4

Plugins with manifests where targetSdkVersion is missing will cause this undesired behavior. The correct fix is to add this entry to the manifest - @pep_dj is correct.

1 Like
5

I fix my project,
For all AndroidManifest.xml in the Asset folder

I added it and built it with UnityCloudBuild.

But, the READ_PHONE_STATE permission remained.

Can you give me some advice?

6

@Yury-Habets : What if multiple manifest files specify different SDK Targets?
Isn’t it dependent on main root manifest file? Please suggest.

Thanks,
Ayyappa

7

@Yury-Habets I have been unable to resolve the unwanted addition of READ_PHONE_STATE in Cloud Builds. I cannot reproduce the introduction of that permission locally. I have ensured that I have buildToolsVersion of 26.0.1 in my locally exported build.gradle file. So, my first concern is that Cloud Build is doing something differently than I am locally. I’m using 5.3.6p1 both locally and on Cloud Build.

I’ve also made sure that every AndroidManifest has specified a minSdkVersion in the uses-sdk block of at least 9. My understanding from the documentation (Manifest.permission  |  Android Developers) (though it is slightly ambiguous) is that if minSdkVersion is specified greater than 3, the READ_PHONE_STATE will not be implicitly added. I have introduced targetSdkVersion when it was missing in my loose AndroidManifest files, but many of the google AARs contain AndroidManifest files inside them that only specify a minSdkVersion.

Can you help me to determine why Cloud Build is introducing this permission?

8

If the google AARs are missing targetSdkVersion - that’s bad. Can you please tell me which ones?
In that case, it has probably nothing to do with the cloud build. Pinging @dannyd in case this is something known.

9

Just to reiterate, my local gradle builds do not introduce the READ_PHONE_STATE permission, but the Cloud Builds do.

All these AARs in my project have a minSdkVersion but not a targetSdkVersion:

10

I just saw this thread, which references an issue about a res folder adding READ_PHONE_STATE (if I understand the issue correctly). Unity Issue Tracker - The storage and phone permissions are shown, when Android folder has a subfolder "res"

I do have a few files in Assets/Plugins/Android/res.

11

This issue was fixed in all Unity versions starting 17.1 (in one of the patch releases), 5.6 patch release pending.

12

@Yury-Habets Any word on the 5.6 patch release with this fix?
Thanks

13

5.6.4p1 should be the one.

1 Like
14

Hi @Yury-Habets , I’ve just seen that 5.6.4p1 has been released but there doesn’t seem to be an obvious entry in the changelog referencing this bug, do you know if it made it in?

15

Yes it should be there - looks like I missed to add the release note entry.

16

Great thanks, will give it a go.

17

This is still happening in 2017.1.2p2

Adding

To each manifest in my project fixed it.

1 Like
18

@Aurigan please read carefully - the fix I’ve been talking of is about having Assets/Plugins/Android/res folder present. In this case, we generate an Android library, and it was missing targetSdkVersion in the manifest. I fixed that.

However, if you have any plugins (libraries) added with NO targetSdkVersion in the manifest - you automatically get the dangerous permission in question. The only fix for this issue is to fix your plugins’ manifests.

19

@Yury-Habets Hi, the issue for me came from including the IronSource Ad SDK. While I could fix this by adding a target SDK version myself after some wasted minutes or hours of my day I view this as something that Unity could do for me … especially given that there’s a minimum and target API already set in Player Settings …

20

@Aurigan no - this is what the plugin author must do - claim the minimum and target SDK levels he is expecting his plugin to work with. We can’t decide it for him.