RCS: Constellation, Asterism, and DroidGuard Tachyon fixes for Google Messages (#2994)

[Gurjotharika]

Summary

• Implements the GMS services Google Messages uses for RCS: Constellation (svc 155, phone-number verification via phonedeviceverification-pa.googleapis.com) and Asterism (svc 199, RCS ToS/consent). These were previously bound to DummyService.
• Adds DroidGuard/Tachyon parity so registration tokens are not rejected for cache-path and parcel-loss differences vs stock GMS (app_dg_cache/, uppercase VM keys, named DgVmClassLoader, keep DroidGuardResultsRequest when the VM PFD is null, populate hasAccount).
• Stops provisioning from aborting on empty IID tokens, regenerated EC keys that still look acked, or a blank SIM number when Messages supplies a phoneNumberHint. Phone/SMS permissions and Messages/IMS phenotype flags needed for UPI/MLS are included. No root or Magisk.

The Constellation/Asterism protocol implementation is based on the public Apache-2.0 work in #3359 / #3360 (@opstic). DroidGuard /proc/self/maps findings follow #3385 (@Lyapsus) and #3644 (@br413). This PR rebases that stack onto current master and adds the remaining provisioning/Tachyon safety fixes.

Fixes #2994

Test plan

• ./gradlew :play-services-constellation-core:testDebugUnitTest
• ./gradlew :play-services-droidguard:testDebugUnitTest
• Build and install play-services-core as a privileged/system microG (locked bootloader, no root)
• Grant Phone + SMS (and privileged phone state / ICC auth where the ROM exposes it)
• pm clear com.google.android.apps.messaging and clear DG cache, then open a current Google Messages
• Confirm setup leaves "Setting up..." and reaches RCS Connected
• Send and receive an RCS message (E2EE if the peer supports it)
• Confirm logcat has no Tachyon PERMISSION_DENIED

Device E2E still needs a microG ROM + SIM. This environment had no JDK/Android SDK, so unit tests were not executed here.

Related

• Bounty: [BOUNTY] RCS Support [14999$] #2994
• Base implementation: Implement play-services-constellation #3359, Implement play-services-asterism #3360
• DroidGuard analysis: Implement Constellation + Asterism services for RCS on Google Messages #3385, RCS: DroidGuard tachyon fixes, phone-number fallback, and unit tests (#2994) #3644

[paulcakeface]

I spotted a remaining ordering issue in the public-key acknowledgement path here.

runVerificationFlow() reads ConstellationStateStore.isPublicKeyAcked(context) to determine includeClientAuth before the stored EC key material is validated.

If the stored key is corrupt while is_public_key_acked=true, includeClientAuth can therefore be captured as true. RequestHeader subsequently calls signIidToken(), which causes getOrCreateKeyPair() to regenerate the key and reset the acknowledgement — but the current request will still include ClientAuth using that newly generated key which the server has never acknowledged.

I reproduced this against the #3359 implementation previously and added regression coverage here:

paulcakeface@325f147

The important part is validating/regenerating the stored key before isPublicKeyAcked() returns the acknowledgement state. The regression test covers both corrupt-key/stale-ack and valid-key/acknowledged cases.

Happy for the fix/test to be cherry-picked or adapted for this branch.