Google offers the ability to allow them the ability to manage the signing key you use to sign your application. In general, this will not cause any issues with the HYPR Android SDK, as long as the same signing key that was used before the opt-in process is still used to sign the app after the opt-in process. The process for opting in an existing key is laid out in Google's documentation. As the process does not require a change to the signing key already used, this means both new apps and existing apps can use the same signing key for releases without any issues.
What If I Am Creating a New Signing Key For a New App?
If this is a new application that hasn't previously been signed, allowing Google to generate a new signing key for the signing process and manage that key will not cause any new issues. If you make use of facetIDs you will be able to access the facetID of the app after it is signed through the ADB logs. This key will also be needed to generate ADP/TEE libraries which must be requested from support. Google's documentation provides information on accessing the generated signing key.
What if I Use a New or Different Signing Key on an Existing App?
Google does provide the option of using a new key or replacing the key if the need arises. Using a new signing key WILL result in problems for users of the app. Because the signing key is used in generating the facetID of the app, a change to the signing key means a change to the facetID. When the facetID no longer matches what exists on the server an error will be thrown that is captured in the hyprStatusResult object and can be seen as:
DisplayText: Operation Failed. Please try again or contact your support for more detail.
DevErrorCode: 7 - TRUSTED_FACET_ID
DevExtraInfo: processTrustedFacet TrustedFacets is not valid and does not contain this facetId or has incorrect version
Note: In versions 5.0 and up the error code is 4011
If you see an error related to this, there is most likely a mismatch in facetIDs that should be resolved by having the appropriate person add the new facetID to the server. The ADB logs of the app also contain the facetID being used and this is what should be added.
If you are making use of ADP and the TEE libraries you will also run into problems in the case of a signing key change. The ADP libraries are built and signed with a given signing key which, when changed, will cause a failure at crypto initialization. In the case of a signing key change for ADP libraries, you are required to contact HYPR support so that a new valid license can be created with the new signing key.
It is perfectly fine to allow Google to manage existing keys by using their opt-in offering. As long as the same signing key is used, there will be no issues or conflicts. However, in the case of using a new signing key there are cases where problems will surface. For this reason HYPR recommends that you avoid using new or different keys to sign apps that have already been signed.