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 |
|---|---|---|
8b29d287f5
Legacy behavior will return success results to multiple startTethering calls of the same type, even though the link layer can only support one of those requests at a time (other than tethered AP + LOHS). For B+, clean up this behavior by only allowing the amount of requests that the link layer can concurrently support. To do this, we'll introduce the concept of "fuzzy-matching" such that if a new request fuzzy-matches an existing request (either pending or serving), this indicates that the link layer cannot support the new request concurrently, and we'll fail the new request with TETHER_ERROR_DUPLICATE_REQUEST. To keep track of serving requests, we'll store the request and it's IpServer in RequestTracker when we call IpServer.enable(), and we'll remove it (indexed by IpServer) when 1) Calling IpServer.onStop() 2) Calling IpServer.unwanted() 3) We detect an IpServer transition to AvailableState with error code Note: This was originally merged as aosp/3529632 but was reverted due to a crash when reading aconfig flags at boot. That issue has been fixed here. Reverted changes: /q/submissionid:3541662-revert-3527440-JRJJTQBUFC Bug: 216524590 Test: atest TetheringTest RequestTrackerTest TetheringManagerTest Change-Id: I87a1ed31927cda27d3b7fdd7c823b8f828f8d777 |
||
| bpf | ||
| clatd | ||
| common | ||
| framework | ||
| framework-t | ||
| nearby | ||
| networksecurity | ||
| remoteauth | ||
| service | ||
| service-b | ||
| service-t | ||
| staticlibs | ||
| tests | ||
| Tethering | ||
| thread | ||
| tools | ||
| .gitignore | ||
| OWNERS | ||
| OWNERS_core_networking | ||
| OWNERS_core_networking_xts | ||
| PREUPLOAD.cfg | ||
| TEST_MAPPING | ||