Exported Android components create additional entry points. Separate tests are needed to establish that controls on the main screen also protect these paths.
Evaluation approach
Compare manifest export settings with actual component behavior. Assess caller identity and input validation separately for critical operations.
Application example
Use a controlled test to verify that another application cannot trigger a service intended only for internal use.
Limits and considerations
An authorization defect in an exported component can remain exploitable while RASP is active.
The contract of an exported component
When another application can invoke a component, address the origin and authority of incoming data. Disabling unnecessary external access is a starting point. Necessary access also requires permission, input and operation boundaries.
Check exports in the final package because manifests can merge during a build. Adding an SDK can introduce unexpected components. A running protection product does not narrow their functional authority; the invoked service still needs its own checks.
Checks and decisions
- Inventory the manifest
- Define required permissions
- Test unauthorized calls
Inventory the final manifest and document why each exported component is needed.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.