feat: Implement Constellation service for RCS phone verification

[trasnake87]

Summary

Implements the Constellation service (GMS Service ID 155) for phone number verification, which is required for RCS provisioning in Google Messages.

This builds on @benwaffle's excellent research and partial implementation from the constellation branch. Key improvements:

• Fix DroidGuard field: Set droidguard_result (proto field 2, marked Required) instead of only droidguard_token (field 1, optional). This is likely the cause of the "invalid argument" error from SyncRequest.
• Complete ProceedRequest flow: After SyncResponse returns PENDING with a TS43 challenge, extract the server-provided entitlement URL, perform EAP-AKA auth, acquire a temporary token, and send ProceedRequest with the token.
• Remove @RequiresApi(VANILLA_ICE_CREAM): The code doesn't use any Android 15-specific APIs. Added runtime version checks for API 33+ telephony calls instead.
• Use server-provided TS43 URL: Instead of the hardcoded entitlement-server.example.com placeholder, extract the entitlement URL from the Ts43Challenge in the SyncResponse.

What this enables

The Constellation service was previously a DummyService returning API_DISABLED, which caused Google Messages to get stuck at the VerifyMsisdnState during RCS provisioning. This implementation provides:

1. verifyPhoneNumber - Full SyncRequest → TS43 → ProceedRequest flow
2. getIidToken - IID token generation with ECDSA signature
3. Phone number verification via carrier TS43 entitlement servers

Architecture

Google Messages → Constellation AIDL → ConstellationApiServiceImpl
  → SyncRequest (gRPC to phonedeviceverification-pa.googleapis.com)
  ← SyncResponse with TS43 Challenge (entitlement URL, app ID, realm)
  → EAP-AKA auth with carrier entitlement server
  → AcquireTemporaryToken ODSA operation
  → ProceedRequest with temporary token
  ← ProceedResponse with VERIFIED state

Module structure

• play-services-constellation/ - AIDL interfaces and parcelable types
• play-services-constellation/core/ - Service implementation + TS43 entitlement library
• play-services-core-proto/phonenumberverification.proto - Wire protobuf schema
• play-services-core/.../ConstellationService.kt - Service wrapper

Testing status

• Build: compiles successfully on assembleVtmDefaultRelease
• Runtime: Not yet tested on a device with a SIM card
• The DroidGuard field fix needs verification against the API to confirm it resolves the "invalid argument" error

Known limitations

• TS43 auth requires a real SIM card with carrier support for EAP-AKA
• Non-TS43 challenge types (MT SMS, MO SMS, FlashCall) are not implemented
• No caching of verification results yet
• ClientAuth (client key signing) is not yet enabled

Addresses #2994

🤖 Generated with Claude Code

[mar-v-in]

So what you want to say is: You took work from @benwaffle, shoveled it into Claude Code and then didn't even actually test any of it?

[trasnake87]

Fair question. To clarify:

1. benwaffle's work is credited and acknowledged. The PR description explicitly states this builds on @benwaffle's research and partial implementation from the constellation branch. That research was invaluable — 6 months of deep investigation into the Constellation protocol. However, no PR was ever submitted from that work.

2. This isn't a straight copy. The PR adds specific fixes on top of that foundation:

   • Setting droidguard_result (proto field 2, Required) instead of only droidguard_token (field 1, optional) — this is likely the root cause of the "invalid argument" error from SyncRequest
   • Removing @RequiresApi(VANILLA_ICE_CREAM) since no Android 15 APIs are actually used, with runtime version checks for API 33+ telephony calls instead
   • Using the server-provided TS43 URL from SyncResponse rather than the hardcoded entitlement-server.example.com placeholder
   • Completing the ProceedRequest flow after TS43 challenge

3. Build verification: The project compiles successfully on assembleVtmDefaultRelease and all existing tests pass. Runtime testing on a device with a SIM card is the logical next step, and I've noted that in the PR description.

I'd welcome specific technical feedback on the implementation — are there issues with the DroidGuard field approach, the TS43 flow, the proto schema, or anything else? That would help move this forward toward something mergeable.

[mar-v-in]

How do you know what is likely the root cause of the "invalid argument" error from SyncRequest without trying?

If @benwaffle deemed his code unfit for inclusion in microG and therefor decided not to create a PR, what makes you believe your code is fit for inclusion if you didn't even test it?