APPSINITYPermissions
Appsinity does not review your manifest. It records what you declare, and players read the declaration next to the permission prompt their device actually shows. Any mismatch between the two becomes a support conversation.
Open Appsinity StudioWhat Studio reads from a build
Build metadata extraction runs on uploaded Android builds and reads a small, fixed set of facts from the binary: the package name, the version code, the version name and the SDK range from uses-sdk. It does not read permissions, components, native libraries or signing identity into your listing.
| Fact | Extracted? | Consequence |
|---|---|---|
| Package name | Yes | Identifies the build on the listing |
| Version code | Yes | Used for release ordering |
| Version name | Yes | Displayed as the release version |
| minSdk / targetSdk | Yes | Compatibility hints |
| Declared permissions | No | You declare collection instead |
| Exported components | No | Not surfaced anywhere |
| Certificate identity | No | Signing is handled separately |
Pairings players notice
Each common permission has an obvious data-safety expectation. Getting these wrong is the most frequent cause of a bad first week of reviews.
| Permission requested | Category it implies | Declare |
|---|---|---|
| READ_CONTACTS / WRITE_CONTACTS | Contacts | collectsContacts |
| ACCESS_FINE_LOCATION / COARSE_LOCATION | Location | collectsLocation |
| READ_PHONE_STATE | Device info, Phone | collectsDeviceInfo, collectsPhone |
| READ_MEDIA_IMAGES / VIDEO / AUDIO | Media files | collectsMediaFiles |
| CAMERA | Media files | collectsMediaFiles when frames are stored or sent |
| MICROPHONE | Media files | collectsMediaFiles when audio leaves the device |
| POST_NOTIFICATIONS | None | No category, but expect a prompt |
| INTERNET with an analytics SDK | Analytics, Device info | collectsAnalytics, collectsDeviceInfo |
| BILLING | Payment info | collectsPaymentInfo |
| Account manager access | Email, Personal info | collectsEmail, collectsPersonalInfo |
Web builds
A web game has no manifest, so the browser's own prompts carry the burden: geolocation, notifications, camera and microphone are all user-gated per origin. Declare the equivalent categories if the code touches them, and note that the analytics event your listing counts is an open rather than an install, see Web game builds.
Windows builds
A Windows release is delivered as a ZIP or installer through the Desktop client, and Windows has no per-app permission model to declare. The honest signals are your data-safety rows plus the listing description, and the platform prints a device warning when an Android-only title is opened from a Windows, macOS or Linux machine.
Good hygiene, stated as advice
- Request at use, not at launch. Ask for a permission when the feature that needs it is invoked.
- Drop what you no longer use. Every leftover permission is a mismatch waiting to be noticed.
- Match the declaration to the code path. If a flag disables contact sync in shipping builds, do not declare Contacts as collected.
- Say why in the long description. One sentence per unusual permission is the cheapest review defence available.
Frequently asked questions
Does Appsinity reject a build for too many permissions?
No. Nothing at upload time inspects permissions. The consequence of an unjustified request is player reaction and, if the declaration disagrees with the manifest, a policy problem.
My SDK adds permissions I did not write. Do I still declare them?
Yes. Merged manifest permissions from libraries are your responsibility to declare; check the merged manifest in your build output, not your source.
Is there a permissions field in Studio?
No. The listing surface for this is the eleven data-safety categories plus the long description.
Where do I state that nothing leaves the device?
In the disclosure text, and by leaving the collection switches on not collected. Off-device and on-device storage are different claims.
Developer publishing support: [email protected]
General support: [email protected]
Partnerships: [email protected]