Hello, I was looking at the appication and I noticed that it wants to have a lot of permissions. I was wondering if there is a way to remove the permisisons from the application? Now if I remove them manually from intermediate/android/apk, the building recreates the manifest. If I make the file read-only, the building stops.
I would prefer to remove pretty much every single permission required by the manifest, because to be honest if I see random application requiring a lot permissions that is most likely instant delete for me for an application or I my self would not even install it to begin with, so I assume there are other people who think the same way as me.
on 4.7git you can modify the source file located at …\Engine\Source\Programs\UnrealBuildTool\Android\UEDeployAndroid.cs the XML should be around line 650 - making changes here is a little project dependent cause it require to build the UnrealBuildTool at any changes… on previus version you could manually edit the AndroidManifest.xml on [PROJECT]\Build\Android
Please notice, binary dependency in “Engine\Binaries\Android” seems also tied with this configuration file (UEDeployAndroid.cs).
Thank you. I managed to compile the unrealbuildtool and I added few lines of code to just read the permissions from a text file. At least it looks like it can run by removing everything except the write to external storage-permission.
I don’t think this is possible. I recently had to add my custom stuff to the UEDeployAndroid.cs GenerateManifest functions, too, to get what I wanted. A lot of guys are having this issue and complaining about it. Let’s hope 4.8 will have some changes…
Basically what I did was just make the UEDeployAndroid.cs to load the permissions from a text-file at a certain location, so it wasn’t exactly a project specific, but at least I can change the file according to project that I am using. I guess with some simple programming it would be possibly to make the cs-file to read from project specific folder, which permissions to give by reading the text-file then generating the manifest from that. Maybe it is not a best way to go, but at least that should be one way to deal with the auto-generation. Of course the problem comes from having to constantly build your own building tool on every update…
Required for AdMob:
android.permission.INTERNET
android.permission.ACCESS_NETWORK_STATE
OBB download from Google Play Store (working on for 4.8):
com.android.vending.CHECK_LICENSE
android.permission.INTERNET
android.permission.WAKE_LOCK
android.permission.ACCESS_NETWORK_STATE
android.permission.ACCESS_WIFI_STATE
These are also currently included, but I think they can be dropped:
android.permission.READ_PHONE_STATE
android.permission.GET_ACCOUNTS
android.permission.MODIFY_AUDIO_SETTINGS
I guess the way you’ve categorized there would be nice. Like if there would be tickable checkboxes from the unreal editor for example I would do something of minimum requirements, where no extra stuff would be included, then I would untick everything. Then if I would want to use force feedback and admob, I could clheck those or something along the lines of that.
If for example something that doesn’t use any of the following permissions, but still shows them: internet, blling and use of external storage, it might scare away some people from even wanting to download the game. If I could remove the permissions for example billing and internet, the game looks a bit safer to download.
I suppose exposing more fields to the Android configuration is 1 solution.
Though there will always be that odd use case where someone wants to modify something that’s not exposed there (like myself, I want to be able to change the android application label)
Would it not be nice to have a: “Use Static AndroidManifest.xml” checkbox that allows us to build from an AndroidManifest.xml file on a project specific basis? (Like in 4.6.1 and prior)
It would be rather painful for adding it via Editor or UEDeployAndroid.cs. For now I disabled generation and I’m simply copying the Manifest.xml from Game/Build/Android. There should be such an option for users that prefers modifying Manifest by themselves rather than using generator.
By the way, iOS is suffering from the same problem with generating plist files.
After peeking through the source code for the manifest generation, it looks like there is an undocumented way to append things to your AndroidManifest.xml file.
You need to create another file called “ManifestRequirementsAdditions.txt” in your projects target build folder. For example, in my Build/Android/ManifestRequirementsAdditions.txt:
Side note: this is great if you are like me and want to package out a bunch of different APKs in order to have smaller file sizes (instead of one huge APK + OBB with all of the texture compression formats). For more info on that:
Again just a simple way to manually edit the manifest.xml like it was pre 4.7 i believe was still the best option. I still can’t set an build android app to be optimized for tablets because everything is automatically generated and there’s no way to override / add it yourself with the current system.
[QUOTE=KillerSneak;549446]
Again just a simple way to manually edit the manifest.xml like it was pre 4.7 i believe was still the best option. I still can’t set an build android app to be optimized for tablets because everything is automatically generated and there’s no way to override / add it yourself with the current system.
Are you unable to add <support-screens> to your Game’s Build/Android/ManifestRequirementsAdditions.txt or Build/Android/ManifestRequirementsOverride.txt? That should work as far as I know. I’ve used that method for adding <supports-gl-texture>.
I need help with ManifestRequirementsOverride.txt. I’m currently not too far from creating final shipping build of my game’s demo, but the override causes some strange troubles. When I leave only android.permission.WRITE_EXTERNAL_STORAGE in it assembled build has terrible resolution problems (game runs in some very small resolution on any android device). But without the override game works just perfectly.
Absence of which of remaining permissions can possibly prevent detection of device’s native resolution?