Test the merged manifest
Build tools merge your manifest with library manifests. Read the release output to find the actual exported list. For each activity, service, receiver, and provider, record the caller allowed, input accepted, and permission check. Launch it from a separate test app using forged intent extras. An exported payment screen should fetch state under the signed-in user, not trust an amount or beneficiary supplied by the external intent.
Launch from another test app
Read the merged release manifest and list every exported activity, service, receiver, and provider. For each, note its business reason and required caller permission. From a separate test app, send a forged intent with a fake payment ID and beneficiary. Query public providers directly. Capture the app response and server calls. A component can show a safe error but still make a payment change first, so compare stored state. Recheck the list after library updates because merged exports can change.
Test cases and proof
| Case | Expected result | Proof to keep |
|---|---|---|
| Payment activity exported by mistake | Close it or require permission | Merged manifest |
| Receiver gets forged intent | Reject untrusted action | App state |
| Provider path requests private record | Deny | Provider response |
Call exported components as another app
List exported activities, services, receivers, and providers from the release manifest. From a separate test app, send an intent to each reachable component with a foreign account ID and malformed input. A share activity may accept public text; a transfer or statement provider must enforce permissions and authenticated scope. Save manifest entry, calling UID, intent or URI, response, and stored state. Android’s exported flag controls reachability; a reachable component still needs its own data and action checks. (Android security checklist).
Separate provider reads from provider writes
For a synthetic statement provider, query account A as an allowed caller, then query account B and an unknown path as an untrusted test app. Check bytes returned as well as the exception. Attempt insert, update, delete, and file-open operations too; a read restriction does not prove a write restriction. An intended share activity needs a positive test with valid public text so closing exports does not break its purpose. Retain the calling UID and permission for each test. Validate one-time URI grants separately from permanent provider permissions, including whether a forwarded URI remains usable by an app outside the permitted recipient.
For a required system receiver, document the expected action and sender permission, then test one legitimate event. An exported=false result is appropriate for an internal component but can break a required system entry point. Keep the allowed-call result beside the denial cases so the review proves the intended feature still works.
Test temporary file grants
Use a synthetic receipt URI shared to one chosen test app with a temporary read grant. That recipient may open the receipt under the intended grant. A second app without the grant must fail, including after it receives a copied URI string. Try a sibling file path and a path traversal value; neither may broaden access. Record whether the share exposes one file or a whole directory tree. After the supported grant lifetime ends, try opening the URI again. Keep the app’s FileProvider paths configuration and grant flags with the result. The exported manifest field alone cannot show which private files a URI grant exposes.