1. Principles we apply

Three principles govern every permission declaration in the STF Capital mobile application. Each was formally adopted at the architectural design stage and is reviewed before every new feature is shipped.

1. Necessity. We request a permission only when there is a concrete feature in the shipping app that cannot function without it. Speculative permissions (“we might need it later”) are never declared.
2. Least privilege. Where Android offers a less sensitive alternative for the same feature we prefer it. For example, we use the modern READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions on Android 13+ instead of the blanket READ_EXTERNAL_STORAGE.
3. Graceful degradation. If you deny a permission we request, the feature that needed it tells you so in a calm, non-nagging message and continues to offer whatever else the app can still do. You will not be locked out of the application because you declined a permission.

2. At a glance

The table below lists every permission declared in the application’s AndroidManifest.xml. Dangerous permissions require a runtime prompt; Normal permissions are granted at install time; Optional entries are feature declarations rather than permissions.

Permission	Type	Feature that uses it
INTERNET	Normal	Talking to the Supabase backend; delivering push notifications
ACCESS_NETWORK_STATE	Normal	Detecting online/offline state to queue work gracefully
CAMERA	Dangerous	Photographing supporting documents and optional profile photo
READ_MEDIA_IMAGES	Dangerous	Selecting document images from your photo library (Android 13+)
READ_MEDIA_VIDEO	Dangerous	Selecting supporting video files (Android 13+)
READ_EXTERNAL_STORAGE	Dangerous	Document selection on Android 12 and below only
WRITE_EXTERNAL_STORAGE	Dangerous	Cached exports on Android 12 and below only
USE_BIOMETRIC	Dangerous	Fingerprint/face unlock after opt-in
POST_NOTIFICATIONS	Dangerous	Push and local notifications (Android 13+)
VIBRATE	Normal	Haptic feedback on notifications
RECEIVE_BOOT_COMPLETED	Normal	Restoring scheduled notifications after reboot
SCHEDULE_EXACT_ALARM	Normal	Precise timing of local notifications

3. Network & connectivity

3.1  INTERNET

Why. Every meaningful action — signing in, reading your application list, uploading a document, receiving a clarification from your advisor — requires a network call to Supabase or to Google’s Firebase Cloud Messaging servers.

How we scope it. Traffic is forced over TLS 1.3. Cleartext HTTP is disabled at OS level through network_security_config.xml and android:usesCleartextTraffic="false".

3.2  ACCESS_NETWORK_STATE

Why. The connectivity_plus plugin uses this to tell the app whether you are on Wi-Fi, mobile data or offline, so we can queue uploads, show an offline banner and retry automatically.

What we do not do. This permission does not give the app visibility into SSID, MAC address or IP address of your network.

4. Camera — CAMERA

Why. Two places in the app capture a camera image: the Documents upload flow (photographing a KYC document) and the Profile Photo flow. Both are triggered only by an explicit “Use camera” tap; no background capture occurs.

How. The system camera intent is launched via the image_picker Flutter plugin — STF Capital does not read the raw camera sensor stream.

If you decline. The “Use camera” option is hidden; library uploads continue to work.

5. Media & files

5.1  READ_MEDIA_IMAGES and READ_MEDIA_VIDEO (Android 13+)

Modern per-type permissions for the photo picker. Only requested for the upload feature; audio and arbitrary MIME types are not requested.

5.2  READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE (Android 12 and below)

Both carry android:maxSdkVersion="32", so Android does not grant them on API 33+. Legacy permissions active only on devices that need them.

5.3  File validation and size limits

• Max size 15 MB per file.
• Accepted types: PDF, PNG, JPG, JPEG, WEBP, DOC, DOCX, XLS, XLSX.
• Files are inspected by magic-byte verification before upload.

6. Biometric authentication

Permissions: USE_BIOMETRIC on Android 9+ and USE_FINGERPRINT for the legacy API on older devices.

• Biometrics are strictly opt-in via the Biometric Setup screen.
• The biometric template never leaves your device. The comparison happens inside the device’s secure element and returns only a pass/fail signal.
• Falls back to PIN or password if the sensor is disabled.

7. Notifications — POST_NOTIFICATIONS

Notifications cover: application-status changes, advisor clarifications or deal documents, and admin work-queue reminders. Routed through FCM to a single device token per signed-in device.

Notification previews never expose sensitive amounts or products on the lock screen.

If you decline. Status updates still reach the app in real-time through a websocket subscription; you simply won’t receive OS-level alerts.

8. Boot & scheduling

8.1  RECEIVE_BOOT_COMPLETED

Re-registers scheduled local notifications after device reboot. Does not auto-launch the application.

8.2  SCHEDULE_EXACT_ALARM

Allows the notifications plugin to schedule reminders at an exact wall-clock moment. Used sparingly, never for marketing.

9. Vibration — VIBRATE

If you select “Vibrate” notification mode on the Profile screen, a short vibration pattern accompanies alerts. Silent or Sound modes never vibrate.

10. What we deliberately do not request

• Location — neither coarse nor fine nor background.
• Contacts, calendar, SMS, phone state, microphone, body sensors.
• Bluetooth scanning, accessibility services, device administrator.
• Install other packages or query installed applications.

11. Runtime prompt experience

1. Pre-prompt. A short in-app sheet explains what the permission enables. Buttons: “Continue” or “Not now”.
2. System prompt. If you tap “Continue”, Android takes over with its own dialog — the only prompt that can actually grant the permission.

If you decline, we don’t nag. Next time you invoke a feature that needs it, we show a calm hint explaining how to enable it in Settings.

12. Revoking a permission you previously granted

1. Open the Android Settings app.
2. Tap Apps → STF Capital.
3. Tap Permissions and toggle off.

Android 12+ also auto-revokes permissions for apps you haven’t used in a while — we transparently re-request with the same explanatory pre-prompt on next use.

13. How the permissions differ by Android version

Android version	Runtime prompts
Android 7.0 – 12	CAMERA, READ/WRITE_EXTERNAL_STORAGE, USE_BIOMETRIC
Android 13 (API 33)	CAMERA, READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, POST_NOTIFICATIONS, USE_BIOMETRIC
Android 14+ (API 34+)	Same as Android 13; SCHEDULE_EXACT_ALARM restricted per Google policy

14. Google Play Permissions Review alignment

Google Play policy	Our justification
Camera must be user-initiated	Only on explicit “Use camera” tap. No background capture.
Media permissions narrowly scoped	READ_MEDIA_IMAGES and READ_MEDIA_VIDEO only, not audio.
Biometric must be opt-in	Strictly opt-in via Biometric Setup screen.
Notifications must have rationale	Pre-prompt shows rationale before the system dialog.
No tracking / advertising	Confirmed in the Privacy Policy.

15. What happens if you decline

Declined permission	Effect
CAMERA	“Use camera” hidden; library uploads still work.
READ_MEDIA_*	Library picker empty; camera uploads still work.
POST_NOTIFICATIONS	No OS alerts; state visible when you open the app.
USE_BIOMETRIC	Biometric unlock not offered; PIN/password continues.
ACCESS_NETWORK_STATE	No offline banner; retries happen on a fixed interval.

16. A note on iOS

The iOS build follows the same principles but through Apple’s NSUsageDescription keys — NSCameraUsageDescription, NSPhotoLibraryUsageDescription, NSFaceIDUsageDescription and the system notification authorisation prompt. Same “necessity, least privilege, graceful degradation” principles apply.

17. Questions about a specific permission

Write to inquiries@stfcapital.org with the subject “Permissions Query”. We welcome scrutiny — it makes the app better.