I have no idea what cratermoon is intending to talk about, but the usual way to solve this problem is attestation. At a high level, the client device has the secret, but it is embedded in a secure enclave that makes it difficult to extract. You then build a chain of trust from that secret that attests that the binary being run is the official one.
Android (at least with the standard Google services) seems to provide an implentation of this through the play integrety API [0]. I'm not familiar with the internals of that system, but I have worked on this type of system for a much more constrained use-case.
If I were designing this, my first pass at a napkin design would be:
* Devices running the app must have a TPM. This TPM is loaded with a private key that is intended to remain highly secret. Corresponding public key is well known.
* During boot, "everything" is measured into the TPM's Platform Configuration Registers (PCRs). To measure something into a PCR, you update the PCR value as: PCR[n] = hash(PCR[n] || measured_value).
* The TPM does not (in this use-case) have a notion of what the "correct" values of the PCRs are. However, it can use the secret key to sign the PCRs values. Forging this signature would require either breaking the underlying crypto, hacking the TPM, or learning the secret key contained within the TPM. To prevent replay attacks, the TPM includes a nonce sent by the server.
* The device sends the server a list of what firmware/kernel/OS it is running (everything that was measured into the TPM). The server determines what the PCR values for the claimed configuration should be, and validates the signature that the TPM generated
* You now know that the OS is "trusted", and can now trust the OS to verify that the app is signed by a given public certificate and is running in a sufficiently secure environment.
[0] https://developer.android.com/google/play/integrity