What specific risk does a hardcoded API key in APK BuildConfig present, and what is the proper server-side mitigation for Google Maps Android API keys?

• A.The developer should split the key into two halves held in separate BuildConfig fields, recombining them at runtime inside a native method, because jadx never resolves a value assembled across the JNI boundary and the DEX strings each show only half the credential; the reconstruction cost puts the key beyond a casual decompile, and the Cloud Console restriction becomes unnecessary once the halves are separated
• B.The key belongs in the Android Keystore, imported at first launch and referenced by alias thereafter, because the TEE never releases raw bytes to the application process and a decompiler therefore recovers an alias string rather than the credential; all Maps SDK calls then read the key through a Keystore handle the hardware gates
• C.The key belongs in network_security_config.xml, because the platform parses that file at runtime and never inlines its contents into the DEX, leaving jadx with a resource reference rather than a credential; the Maps SDK reads the value through the network security configuration, and no Cloud Console restriction is required