Preserve host caller identity in Phenotype broker requests

[davidwkr]

ProviderInstaller's fallback can supply a GmsCore package context to code running in a client app. In an Android 17 downstream ROM capture, Wallet fell back after com.google.android.gms.providerinstaller.dynamite could not load; ProviderInstaller's Phenotype registration then failed with SecurityException: Unknown calling package name 'com.google.android.gms'.

This draft proposes correcting the client identity at the Phenotype service connection. For broker transaction 46 and service ID 51, the wrapper replaces a claimed GmsCore package with the host application's package. It checks the host context UID, excludes GmsCore and cross-user bindings, and requires the expected service action, package and Binder descriptor. Receiver-side UID/package validation is unchanged.

The Parcel helper retains callback Binder references, unknown fields and trailing data. Unsupported or malformed requests pass through unchanged. Existing Play Integrity connection handling takes precedence.

Evidence and validation

• Inspected the installed Wallet 26.33.969972112, Play services 26.29.32 and GmsCompatLib version 102, together with the downstream framework. Wallet's fallback explicitly creates and passes a GmsCore package context; the broker client derives the calling-package field from its context.
• Compiled the new helper/wrapper and standalone tests. Passed 56 assertions on the device using Android's real Parcel, Binder and BinderWrapper, including identity substitution, shorter/longer strings, Binder preservation, malformed inputs, pass-through paths and connection lifecycle callbacks.
• git diff --check passes. A reproducible test runner is included under lib/tests/providerinstaller.

Remaining work / scope questions

• This was observed on a modified VoltageOS Android 17 device with app hooks enabled, not an unmodified GrapheneOS installation. Upstream reproducibility and attribution remain unverified.
• No full platform/Soong build or signed-library deployment has been performed. The tests use local Binder transactions; cross-process behavior and the actual app binding path still need validation.
• Resolved intents without the explicit package/action are currently passed through. The tested application must be checked to ensure its live binding reaches the wrapper.
• The wrapper targets matching Phenotype requests from host apps, not only ProviderInstaller call stacks. Maintainer feedback on scope and the preferred integration point would be useful.
• This does not establish a fix for Wallet device eligibility or attestation. ProviderInstaller's cryptographic provider fallback already completed in the observed capture.

Opening as a draft for design review before platform integration and end-to-end testing.