[BOUNTY #2851] Reuse remote DroidGuard sessions across snapshots

[woahwhattheheck]

Summary

Reuse remote DroidGuard state across the existing init / repeated snapshot / close lifecycle, centralize the HTTP transport, and return completed callback results before potentially slow remote cleanup. The protocol now also has an operator-enabled Android provider and authenticated host adapter that retain actual Embedded core handles.

Response transport source: 7a45ad14d102e89c1ba7082887908efa9246737b. Request-bound source: f826c8ed1540ac8969140c340f7c211ad83e68c2. The executed validation pins and their source scope are recorded below.

• guardWithRequest uses the existing bounded executor, returns its callback result, and closes its handle in a finally boundary, including callback failure.
• Remote initialization stays pending until setup finishes. A snapshot observes the matching initialization generation, and closing a handle prevents late setup from reopening it.
• HTTP request encoding, timeouts, non-success responses, and connection cleanup are shared.
• Legacy single-request fallback remains available when session setup is unavailable.
• Completed success/fallback results are delivered before waiting for the remote close response; cleanup remains on the same executor worker.

Native server and public client

The operator setup guide documents the new default-disabled provider and Python host adapter. The provider checks DUMP permission and the actual local caller UID before decoding or changing Binder identity. It requires Embedded mode, checks native readiness, retains one core handle for repeated snapshots, and closes failed initialization and late results. The ordinary service broker is unchanged.

Session capacity includes pending initialization and cleanup. Operation deadlines, idle expiry, and bounded queues limit retained work. A duplicate operation for a busy session is rejected before occupying a global worker, preserving progress for another session. The adapter selects an explicit ADB device, authenticates the existing base-URL token query, and carries exact JSON envelopes instead of treating content-command diagnostics as result bytes.

The HTTP action/form protocol is adapted from GautamKumarOffical's PR #3575, source 9d9a8d37e1f4b70997ba1868d2c196261dfd7d0f; its Apache notice and source credit are retained.

The public RemoteDroidGuardHandleClient exposes the existing Task/handle lifecycle. At 02f6c0f0, initial executor rejection becomes a failed Task, and getResults uses one accepted worker for begin/snapshot/result/close. Per-session HTTP serialization from 04fbd911 remains in place.

Executed validation and source pins

HTTP response boundary and current Android execution

At 7a45ad14, RemoteDroidGuardHttpClient reads responses through an 8,192-byte buffer with a 262,144-byte limit. Its maintained regression rejects an oversized response and still verifies connection cleanup.

Run 37229223484 checked out product 2de4887ea7ffd27ec86256f3ccbd48e3e46a8baf / tree f23fccdf238d29c8a515381de40e06f586958565, then applied exactly the two retained response-bound postimages. The scope guard passed. The production HTTP blob is 730ea3d34bb44f25d13070aa2a44fc59dde24ce0, and the maintained test blob is 0e1887b51bc57cfe8224e3f19f5aa1c9ad476355; both are now exact readbacks from the existing PR at 7a45ad14.

The three selected classes produced 12 actual JUnit XML tests, 0 failures, errors or skips: initialization 5, session 4, HTTP client 3. :play-services-droidguard-core:testDebugUnitTest and assembleVtmDefaultDebug completed with Gradle exit 0 in 186.811 seconds. The runner's own JDK jdk.httpserver module supplied an evidence-scoped unit-test classpath JAR through a Gradle init script.

The downloaded VtmDefaultDebug APK is com.google.android.gms-252432000.apk, 107,332,090 bytes, SHA-256 f4981a147e7b05d71669d48e2983c3673fd810e021768b20d71cfcdafa0cc1d6. These results and that APK belong to 2de4887e plus the stated exact two-file response patch. Device Play Integrity and the Dott unlock-and-ride outcome remain pending.

Request admission and adapter concurrency

At f826c8ed, the client rejects an over-limit encoded request target, form body or field count before opening the HTTP connection. The bounds are 8,192 bytes for the request target, 32,768 bytes for the form body, 128 query fields and 256 form fields. The already-landed 262,144-byte response limit and connection cleanup remain in place.

The actual Kotlin/JDK test replay completed 10/10 cases, including the exact 8 KiB target, 32 KiB body, 128/256 field boundaries and an accepted exact 256 KiB response. Controlled runs removing the target, field and response guards failed their intended cases. These are the focused production-client checks for those postimages.

At 0e8369b0, the Python adapter protocol test executes the maintained HTTP adapter and ContentBridge with a disposable subprocess at the Android content-command boundary. Python 3.12.10 completed its one concurrent acceptance scenario; a forced-sequential control failed the assertion that the independent B session progresses while A is blocked. Six content-command calls were retained. The adapter source is unchanged in that test forward.

Native server at 911188d3

The complete changed provider, store, and core handle compiled with Kotlin 2.2.21 for JVM 1.8. Six focused scenarios passed using retained JDK 17 / Robolectric 4.12.2 / Android API 29: failed native setup closes once without an ID; owner isolation and idle expiry; caller/input admission; independent-session progress under a held snapshot; one core handle across two snapshots; and cleanup of initialization completing after its deadline.

Those runs execute the actual core handle, HandleProxy, GuardCallback, and Android Binder/Bundle/JSON behavior with a recording VM/factory and controlled local preferences. The provider was manually attached using retained resources. Installed manifest/component behavior, Google VM/JNI, an Android device, and a new APK were not exercised.

The production Python HTTP/subprocess adapter completed ten requests and seven content-command fixtures covering lifecycle, byte preservation, authentication, invalid input, and provider errors. This verifies the transport implementation at an explicit fixture boundary, not a connected device. The setup guide records the exact source blobs and limits.

Session serialization and client dispatch

At 04fbd911, the actual Kotlin session/HTTP classes against a latched loopback server reproduced snapshot/snapshot and snapshot/close overlap before the change and prevented both afterward; a separate session completed while the first was held. Its maintained four-case session class passed. Source and execution scope.

At 02f6c0f0, the complete public client/session/HTTP code ran with the actual retained microG TaskImpl and existing loopback server. The original three interop cases plus two rejection regressions passed 5/5; the preceding source failed the two new cases. One worker admission and result-before-close ordering were asserted. These focused results are separate from the earlier integrated APK below.

Integrated Android run at 7a648d5f plus the retained test patch

Run 37193312230, job 111409876131, succeeded after checking out product 7a648d5fe5f073c61ef7b202aef4c74dd329f4be / tree 24896870026d0edb04989c9627b4a1dc0586670d.

The checkout applied only the retained session lifecycle test patch v2 (SHA-256 497af7ad875d46645c85eff4f2d02711678dc0513fbf70f4359ccc7636b7fc24; test blob f300e7fad7a6a9649d6c591f36a701b6bf7ee80b). No production file changed in the execution checkout.

The three selected classes produced 12 actual XML tests, 0 failures, errors, or skips:

Class	Cases
RemoteDroidGuardInitializationTest	5
RemoteDroidGuardSessionTest with v2 patch	5
RemoteDroidGuardHttpClientTest	2

:play-services-droidguard-core:testDebugUnitTest and assembleVtmDefaultDebug completed with Gradle exit 0. The unit task executed. Toolchain: Gradle 8.13, OpenJDK 17.0.20.1, Android API 35 / build-tools 35.0.0.

• Integrated report and command
• APK and execution evidence — artifact 11300192593
• APK: com.google.android.gms-252432000.apk, 107,313,927 bytes; SHA-256 d40be530096efce543222918b062abfe2310e1508fddb0393c2603ed302e5749.

That APK belongs to the 7a648d5f production source. The session test extension was transient validation input; the report records it separately.

Later callback-order repair at 4fec1b39

The callback-order report records execution of the complete original/repaired production service and the remote handle, initialization, session, HTTP, and fallback classes against a real loopback HTTP server with disposable Android/AIDL/context/preference collaborators.

Two ordering cases failed before the repair and passed afterward; the two existing callback-failure/rejected-executor controls remained passing. The ordering assertions use latches and still verify one callback, one close, and expected result bytes.

With a deliberately delayed 300 ms close response, the recorded callback-latency median across three samples changed from 391.153 ms to 42.407 ms. These are observations from that controlled loopback scenario. Cleanup still occupies the executor worker; this is callback ordering/latency evidence, not a sustained-throughput measurement.

The current callback change has that focused production-class replay. The integrated APK and 12-case Gradle result above are for its preceding source pin.

Earlier source results retained

The original 3f10ba2b transport/session change passed its four focused offline Gradle tests and compiled the module/AIDL. The 7a648d5f initialization follow-up separately passed five maintained JVM checks and four stubbed production-handle loopback scenarios. Those earlier counts overlap with subsequent selections and are not added together.

Device acceptance

Real remote-server/device Play Integrity behavior and an actual Dott unlock-and-ride video remain pending. The linked software checks do not contain that field result.

Refs #2851.

Original-author conditional bounty / compensation request

I, @woahwhattheheck (GitHub ID 293286387), submit and affirmatively claim the original DroidGuard transport, lifecycle, request-admission, Android provider and client integration work recorded in this PR for any applicable issue/bounty compensation. Please identify the corresponding eligible BountyHub or sponsor program, acceptance criteria, payable amount and payout registration route before treating this original contribution as uncompensated work. Third-party protocol/source credit to GautamKumarOffical PR #3575 is explicitly retained; this request covers my own integration and changes, not someone else's original implementation.

Neither BountyHub listing eligibility nor portal registration for #2851 is verified by this update. The attached unit/Gradle results retain their exact historical source pins; actual device/Play Integrity/Dott unlock-and-ride acceptance remains outstanding. This metadata update changes no source, tests, PR head or evidence.

[woahwhattheheck]

To align the remote-session lifecycle with the intended Play Integrity call sequence: this change keeps one remote session alive across repeated snapshot() calls on a retained DroidGuardHandle. In this tree, getResults() and service guardWithRequest() each open a handle, take one snapshot, and close it.

Can you confirm whether the required multi-step sequence reuses one handle for multiple snapshots, or expects state to persist across separate one-shot getResults()/guardWithRequest() calls? This PR covers the retained-handle sequence; it does not demonstrate the real server/device or end-to-end Dott flow.

[D3SOX]

Did you read the bounty note?

This is probably a general issue with Firebase SMS authentication. For the bounty to be released the Dott app should work to unlock and ride the scooters.

Can you show a video where it works?

[tokenjunkielabs]

Thanks for clarifying the bounty's acceptance criterion. PR #3841 implements the remote session transport path and includes four focused local session/transport tests. It has not been exercised with Dott unlocking or riding against a real server/device, so I cannot provide a video demonstrating that outcome. The PR body records this limit; end-to-end Dott behavior remains unverified.

[woahwhattheheck]

/claim #2851

I claim the applicable allocation from the advertised $85 USD bounty for my contribution in this PR, payable to the original contributor @woahwhattheheck. The contribution and remaining acceptance requirements are documented in the existing PR; this claim preserves the original contributors' attribution. Please confirm eligibility and the award upon acceptance, payment method, and payout date.