Implement play-services-constellation

[opstic]

This is PR 1 of 3 towards RCS support.
Related PRs: #3360, #3361
Related issue: #2994

Collectively these changes enable Google Messages to verify the phone number via UPI and retrieve the provisioning document.

In my testing, setup progresses through verification, provisioning and reaches a connected state in Google Messages.
The remaining failure occurs during Tachyon registration. One possible cause is that the final DroidGuard tachyon_registration challenge is not being satisfied correctly in my test environment.

Testing from people with environments that pass DroidGuard/Play Integrity would be appreciated, especially with logs/network captures if possible. Many thanks!

Description

This PR implements the Constellation service, including:

• verifyPhoneNumberV1
• verifyPhoneNumberSingleUse
• verifyPhoneNumber
• getIidToken
• getPnvCapabilities

getIidToken and verifyPhoneNumber appear to be the main APIs Google Messages would call.

Most of the verification paths are hopefully implemented correctly, only the TS.43 path was tested.
Flashcall is excluded for now as it's implementation in GMS requires a hidden API in Android SDK.

The gRPC proto definitions and client implementation are also used by play-services-asterism (PR #3360)

Screenshots

[mar-v-in]

It will take a while for this to be reviewed, but I'm happy to finally see someone actually tackling the issue instead of having an LLM generate bullshit. 👏

[ale5000-git]

@opstic
There is an error in the build:
error: Field verifications in com.google.android.gms.constellation.VerifyPhoneNumberResponse has unsupported type @org.jetbrains.annotations.NotNull com.google.android.gms.constellation.PhoneNumberVerification in @org.jetbrains.annotations.NotNull com.google.android.gms.constellation.PhoneNumberVerification[].

[mar-v-in]

@opstic We generally try to sort things into two modules:

• A library module, which includes all code needed to connect to the service, that is aidl, parcelables, potential client code, constants/enums and is pure Java (no Kotlin).
• An implementation module, typically called -core, that has the relevant services and actual logic implementations. Here we often use Kotlin.

The error @ale5000-git mentioned is probably due to having safe parcelable classes in Kotlin (which was never supported or tested), meaning they have automatically generated annotations that shouldn't be there. The Kotlin code also somewhat looks like it was automatically converted from Java (which is not always 100% safe, as seen here).

For this API specifically, because it is an internal API of Google, you can also just add it to the play-services-api module which is the catchall for all APIs that don't have a corresponding official Google client library (meaning they don't show up in this list). The service side should then go in the play-services-core module.

[opstic]

@mar-v-in
I've debugged and found that the field.listItemType on that specific field resolves to annotated names, which would fail the getTypeElement call, and thus fail isParcelable, isInterface and come out unsupported.
This doesn't happen on my Windows host where it has it's full name of com.google.android.gms.constellation.PhoneNumberVerification without the annotation so it gets resolved correctly

The @JvmField were workarounds to avoid safe-parcel-processor using reflection to access the fields, I'll be converting these into Java then.

Also I'll restructure a bit to fit the sorting better.

[mar-v-in]

@opstic The issue is that it sees the type as @org.jetbrains.annotations.NotNull com.google.android.gms.constellation.PhoneNumberVerification due to the additional annotation on the type. The Java preprocessor for safe parcelables only supports field annotations, not type annotations, but the Kotlin to JVM compiler seems to add the @org.jetbrains.annotations.NotNull annotation to the type. Not sure why this is different on your system than the CI build. I'm not sure if there is an easy way to make Kotlin compiler not add those, but even easier would be to just continue with API classes being in pure Java, because then you can just not have the annotation on the type and also use the Android version of the NonNull annotation rather than the Jetbrains/Kotlin variant.

[opstic]

@mar-v-in
The code is quite large and shoving it into play-services-core doesn't look too well to me, can I just do something like play-services-droidguard where there's a core folder inside that handles the service logic?
oops didn't read what you said carefully enough, I'll sort it out with play-services-constellation and play-services-constellation-core then