1# TrustTests framework tests 2 3These tests test the "trust" part of the platform primarily implemented via TrustManagerService in 4the system server and TrustAgentService in system apps. 5 6Tests are separated into separate files based on major groupings. When creating new tests, find a 7_closely_ matching existing test file or create a new test file. Prefer many test files over large 8test files. 9 10Each test file has its own trust agent. To create a new trust agent: 11 121. Create a new class extending from `BaseTrustAgentService` class in your test file 132. Add a new `<service>` stanza to `AndroidManifest.xml` in this directory for the new agent 14 following the pattern fo the existing agents. 15 16To run: 17 18```atest TrustTests``` 19 20## Testing approach: 21 221. Test the agent service as a black box; avoid inspecting internal state of the service or 23 modifying the system code outside of this directory. 242. The primary interface to the system is through these three points: 25 1. `TrustAgentService`, your agent created by the `TrustAgentRule` and accessible via 26 the `agent` property of the rule. 27 1. Call command methods (e.g. `grantTrust`) directly on the agent 28 2. Listen to events (e.g. `onUserRequestedUnlock`) by implementing the method in 29 your test's agent class and tracking invocations. See `UserUnlockRequestTest` for an 30 example. 31 2. `TrustManager` which is the interface the rest of the system (e.g. SystemUI) has to the 32 service. 33 1. Through this API, simulate system events that the service cares about 34 (e.g. `reportUnlockAttempt`). 35 3. `TrustListener` which is the interface the rest of the system (e.g. SystemUI) uses to receive 36 events from the service. 37 1. Through this, verify behavior that affects the rest of the system. For example, 38 see `LockStateTrackingRule`. 393. To re-use code between tests, prefer creating new rules alongside the existing rules or adding 40 functionality to a _closely_ matching existing rule. 41