When testing on MagicPod's Android cloud devices, how your app is handled internally depends on the upload format (.apk / .aab).
- .apk upload: The app is installed as-is, with no re-signing. The original signing certificate is preserved.
- .aab upload: MagicPod converts the bundle into an installable APK using
bundletool, and re-signs the resulting APK with a fixed signing key bundled with MagicPod. This key is shared across all users and organizations.
As a result, the signing SHA-1 of an app tested via .aab differs from the original app's SHA-1 (and from the SHA-1 you'd get uploading the same app as .apk). If any feature depends on the signing certificate fingerprint, it may behave differently only when tested via .aab.
Examples of affected features:
- A Google Maps (or other Google API) key restricted by SHA-1 fingerprint in Google Cloud Console will not match, so the feature may fail to work when tested via
.aab. - Any in-app logic that verifies the signing certificate (e.g. certificate pinning) may be affected the same way.
Workarounds:
- Prepare a separate .apk build for uploading to MagicPod. Since
.apkfiles are installed with no re-signing, the original signature — and anything that depends on it — is preserved. You can keep publishing via.aabfor the store while producing a separate.apkjust for MagicPod testing. - Contact MagicPod support. Depending on the case, we may be able to share the SHA-1 fingerprint of the fixed re-signing key (note that this value may change without notice).