Fix #2851: [BOUNTY] Support Play Integrity over remote DroidGuard + Server/Guide [$85]

[indra112f]

Automated implementation prepared by CoreMesh Task Forge for #2851.

Human approval was required before submission. The code, repository validation, maintainer-facing explanation, and independent review were validated before this PR was opened.

What changed

• RemoteHandleImpl.kt adds opt-in v1 init/snapshot/close HTTP transport through existing Network mode, retaining the legacy snapshot endpoint for URLs without the protocol fragment.
• RemoteSession.kt serializes lifecycle calls, retains session identity across snapshots, validates IDs, and closes previous sessions before reinitialization.
• server/session_server.py provides a CPython reference transport with a persistent-handle backend interface, bounded session capacity, expiry, cleanup and error handling. No Android backend is included.
• Added Kotlin lifecycle tests, shared Python protocol cases with in-memory HTTP and loopback runners, and REMOTE_DROIDGUARD_SETUP.md describing the protocol, runtime and integration limits.

How it works

• A configured URL ending in #droidguard-session-v1 selects the experimental protocol. The fragment is removed and POST requests target /init, /snapshot, and /close beneath the configured base.
• Init transmits source package, flow and supported primitive request metadata as form fields; the server creates one backend handle and returns an opaque ID. Repeated snapshots transmit that ID and prefixed string inputs, returning URL-safe Base64 bytes.
• The reference server requires an explicitly supplied Python backend factory. The factory owns real DroidGuard initialization and returns a persistent object with snapshot/close methods. Tests supply stateful test handles only.
• Session failures do not trigger legacy fallback or initialize replacement handles. Close clears local state even on transport failure; the server expires abandoned sessions on subsequent valid requests and closes handles at shutdown.

Verification

• Ran python3 -m unittest discover -s play-services-droidguard/server -v: five tests completed successfully. They exercise the actual HTTP handler/parser using in-memory socket streams, verifying multi-step state, binary output, metadata and Unicode form encoding, isolation, cleanup, expiry, capacity, malformed forms and backend failures.
• Attempted the loopback versions of these cases: this sandbox denies TCP socket creation with PermissionError. The explicit integration runner is python3 play-services-droidguard/server/integration_session_server.py -v; real network operation remains unverified here.
• Attempted ./gradlew :play-services-droidguard-core:testDebugUnitTest: Gradle could not start because Java is unavailable. Kotlin tests cover same-session reuse, reinitialization, locally idempotent close, invalid IDs and failure behavior; compilation and execution remain unverified.
• git diff --check completed without whitespace errors. No real Android devices or Play Integrity verdicts were tested.

Demo evidence

Not required for this task.

Scope and risk

This is a local transport prototype, not a complete solution to issue #2851. The supported reference runtime is CPython 3.8+ with an external persistent-handle backend. A verified Android backend, stock-phone setup, passing Play Integrity verdicts, and root/bypass maintenance are not implemented. The guide explicitly states these limitations rather than claiming Termux can invoke DroidGuard automatically. The reference server binds to loopback and has no built-in authentication/TLS; deployment requires an access-controlled HTTPS proxy and a verified backend. Session mode rejects nonprimitive request fields and does not transport Parcelable/file-descriptor init replies. Primitive metadata is textual and backend adapters must restore known types. Legacy endpoint selection, Embedded mode and the existing guardWithRequest service TODO remain unchanged. Client logging of snapshot/request contents was removed and legacy HTTP connections now disconnect after use. Kotlin/Android compilation and actual network/device behavior require follow-up verification.

Task Forge validation

• Configured repository validation gate: git diff --check && python3 /taskforge-scripts/repository_validate.py --auto — PASS
• Independent technical review — PASS
• Change footprint: 10 files changed, 562 insertions(+), 15 deletions(-)

Bounty submission

Submitted for bounty consideration under issue #2851.

Preferred payout route

Payout route (if awarded): Base USDC → 0x9dFD2Ee86182f92464b50809C6702B999a0Cd54f

If the sponsor or bounty venue supports on-chain settlement:

• Network: Base mainnet (chain ID 8453)
• Asset: USDC
• Address: 0x9dFD2Ee86182f92464b50809C6702B999a0Cd54f

The venue's payout, identity, tax, KYC, and eligibility rules take precedence. No payment is presumed until the sponsor explicitly awards it.