No description. Add one?
- Java 78%
- Kotlin 11.8%
- AIDL 4.4%
- C++ 3.7%
- C 1.5%
- Other 0.5%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
366c525b15
NetworkAgents send NetworkCapabilities to ConnectivityService but there are limits to what exactly they can send. Going forward, some of these checks will have to happen on the handler thread, which is already the case when an agent updates its capabilities, but not upon registration. This patches moves the sanitization on the handler thread, after the network monitor is created for a network agent. Before this patch, upon registration of a new agent, the binder thread would copy and sanitize the capabilities, then store them in nai.networkCapabilities. It would store the original caps from the agent in the NAI, mix in what is known from the network info, process the LinkProperties, and then proceed to create the network monitor, but not yet store the NAI in the internal structures because its registration is not finalized, so other methods should not see it yet. After the monitor is created in the network stack process, the NAI is stored in the internal structures which publishes it for all methods to see. After that is done, the NAI calls to the network monitor to warn it that it's registered, what its capabilities are, and that it's time to start validation if applicable. With this patch, the validation no longer happens on the binder thread. Instead, the binder thread stores the capabilities and link properties as is, before sanitization, in the NAI. This is fine because no other method can access these until the registration completes upon notification that the monitor has been created ; this agent is only stored in the network monitor callbacks in a self-destructing object precisely to make sure that's the case. When the monitor is created and CS receives notification of the same, it will sanitize the capabilities before adding the NAI to the internal structures, to protect the invariant that the un-sanitized capabilities inside the NAI can't ever be seen by any other method. After that's done, it will call to the monitor to start validation as usual. Test: FrameworksNetTests CtsNetTestsCases Change-Id: I7d43ef0e25955e0349903b4801b9dfd8c3c92586 |
||
| bpf_progs | ||
| framework | ||
| framework-t | ||
| service | ||
| service-t | ||
| tests | ||
| Tethering | ||
| .gitignore | ||
| OWNERS | ||
| OWNERS_core_networking | ||
| OWNERS_core_networking_xts | ||
| PREUPLOAD.cfg | ||
| TEST_MAPPING | ||