Alexa patch fails on 2nd gen Portal+ (QKQ1.210213.001.4051355900018050) – falcon checksum mismatch

[sojufx]

Device / firmware

• Model: Meta Portal+ 2nd gen
• Android version: 10
• Build ID (ro.build.display.id): QKQ1.210213.001.4051355900018050

What I did

1. Downloaded Immortal v1.36 on macOS.
2. Ran provisioning from immortal-1.36/provisioning:

./provision.sh --alexa

Relevant output

==> Reconstructing the patched falcon (bspatch)
  ! Reconstructed falcon checksum mismatch (bad stock or diff) — skipping Alexa.

Firmware props

adb shell getprop ro.build.version.release
# 10
adb shell getprop ro.build.display.id
# QKQ1.210213.001.4051355900018050

Extra attempts

• Sideloaded amazon_alexa.apk:

adb install ~/Downloads/amazon_alexa.apk
adb shell pm list packages | grep alexa
# com.amazon.alexa.multimodal.falcon

• Tried launching:

adb shell am start -n com.amazon.alexa.multimodal.falcon/com.amazon.alexa.multimodal.LaunchActivity

• Activity starts from ADB, but Alexa UI does not appear / is not usable on the Portal.

Current state

• Immortal provisions and runs fine.
• Alexa patch step is skipped due to falcon checksum mismatch on this firmware.
• Sideloaded Alexa alone doesn't work correctly without the patched falcon.

Ask

• Could support be added for firmware QKQ1.210213.001.4051355900018050 on 2nd gen Portal+?
• Happy to provide any extra logs or a falcon dump if needed.

[starbrightlab]

Sadly, we are going to have to pull support for the Alexa restoration for 2nd Gen Portals for now. There are significant differences between android 10 and 9 microphone management policies.

[sojufx]

Thanks for the response. After your reply, I continued investigating to understand the exact blockers. Here's everything I tried and what the logs revealed — in case it helps with a future fix.

---

Additional investigation after your response

Attempt 1 — Sideload APK from Reddit post

Installed a generic amazon_alexa.apk found via Reddit (r/FacebookPortal):

adb install ~/Downloads/amazon_alexa.apk

Installed fine but couldn't grant RECORD_AUDIO — the APK hadn't declared it in its manifest. Confirmed this was the wrong (non-Portal) build.

Attempt 2 — Install as privileged system app

Tried pushing to /system/priv-app/ via ADB:

adb root        # adbd cannot run as root in production builds
adb remount     # failed — read-only filesystem

Blocked by production build lockdown.

Attempt 3 — Firmware dump (cipher / QKQ1.210213.001)

Found the exact firmware dump for the 2nd gen Portal+ (codename: cipher) at dumps.tadiphone.dev. Confirmed firmware match: cipher_prod-user 10 QKQ1.210213.001 4051319600009050.

Downloaded the Portal-native APK directly from the dump:

curl -L "https://dumps.tadiphone.dev/.../system/system/app/amazon_alexa/amazon_alexa.apk" -o amazon_alexa_portal.apk
curl -L "https://dumps.tadiphone.dev/.../system/system/priv-app/aloha_alexammsdkproxy_release/aloha_alexammsdkproxy_release.apk" -o alexammsdkproxy.apk

• amazon_alexa_portal.apk — installed successfully
• aloha_alexammsdkproxy_release.apk — failed: INSTALL_PARSE_FAILED_NO_CERTIFICATES (signature stripped in dump)

Granted permissions:

adb shell pm grant com.amazon.alexa.multimodal.falcon android.permission.ACCESS_FINE_LOCATION
adb shell pm grant com.amazon.alexa.multimodal.falcon android.permission.READ_PHONE_STATE
adb shell appops set com.amazon.alexa.multimodal.falcon RECORD_AUDIO allow

---

Logcat analysis — root causes identified

Ran adb logcat '*:E' | grep -i alexa while launching the Portal-native APK. Key errors:

1. Custom AudioAttributes field missing

SPCH-SIMTtsContract: java.lang.NoSuchFieldException: No field FLAG_ADAPTIVE_VOLUME
in class Landroid/media/AudioAttributes
(declaration of android.media.AudioAttributes appears in framework.jar!classes2.dex)

The APK expects Amazon's custom-modified AudioAttributes with a FLAG_ADAPTIVE_VOLUME field. This field only exists in Amazon's forked Android framework — not in the stock Android 10 build on the Portal when running as a sideloaded app. This is clearly the core Android 10 audio policy incompatibility.

2. Wake word DB schema mismatch

SQLiteException: no such column: modellocalespecificname (code 1 SQLITE_ERROR)
while compiling: SELECT modelname, modelstatus, modellocalespecificname FROM falconWakeWord

The on-device falconWakeWord SQLite table has a different schema than what the firmware-native APK expects. The DB was likely never initialised correctly via the sideload path.

3. CSM not connected (error 1107)

SimClient: onError(1107): (CSM is not connected to Alexa)

CSM (Cloud Speech Manager) is a firmware-level system service — not an APK. It cannot be installed or replaced without root/system access.

4. Alexa settings provider missing

AlexaSettingsManager: getInt:: Given settings: user_setup_complete is not supported
in content://com.amazon.multimodal.settings.provider.alexa/settings

The settings content provider (com.amazon.multimodal.settings.provider.alexa) is a separate system APK, also not installable without system access.

5. Build serial unavailable

Cannot get Build.getSerial. No READ_PHONE_STATE or READ_PRIVILEGED_PHONE_STATE permission

Alexa cannot identify the device to Amazon's servers. READ_PRIVILEGED_PHONE_STATE is not grantable to non-privileged apps.

---

Summary

The Portal-native amazon_alexa.apk (from cipher firmware dump) is the correct APK, but it depends on at least 4 firmware-level components that are either missing or incompatible in a sideloaded context:

Component	Status
FLAG_ADAPTIVE_VOLUME in Amazon framework	Not present in sideload context
CSM (Cloud Speech Manager)	Firmware system service, no APK
com.amazon.multimodal.settings.provider.alexa	Missing system APK, needs root to install
aloha_alexammsdkproxy_release.apk	Signature stripped in dump, can't install

Hoping this detailed breakdown is useful for when you revisit Android 10 support. Happy to run any additional diagnostics if helpful.

[starbrightlab]

Really appreciate you digging this deep and writing it up so clearly, that's a genuinely useful failure log.

Good news: most of what you hit isn't actually the wall for this project, because the our modified code doesn't drive alexa the firmware-native way. A couple of clarifications that might save you time:

We patch falcon (the native alexa) and bring our own wake word, which sidesteps most of your blockers:

• CSM / "not connected" (1107), user_setup_complete provider, Build.getSerial/privileged perms: our patched build connects to Alexa anyway. It binds its own SIM client, registers via the standard amazon.com/code (CBL) flow, and a couple of small smali patches (getCurrentUser→0, getIsAnonymous→FALSE) get it past the identity checks. On Android 9 it reaches ReadyState and answers normally; on Android 10 it also reaches ReadyState — so the cloud/registration side isn't the blocker.
• falconWakeWord schema mismatch: we don't use falcon's native wake word at all. A separate app does the wake-word detection on-device (Vosk) and hands the turn to falcon. So that DB never matters.
• FLAG_ADAPTIVE_VOLUME: nice catch, and yes it confirms the Portal runs an Amazon-forked framework, but that field is TTS playback volume (output side) and it's non-fatal. Not related to capturing audio.
• The one real wall on Android 10 is microphone: the Portal build silences background mic capture for sideloaded apps. Even a foregroundServiceType=microphone foreground service, even as the only capturer. dumpsys audio shows silenced:true for any backgrounded recorder; a foreground app records fine. Android 9 simply predates this (the isClientSilenced mechanism is API 29+), which is the entire reason 9 works and 10 doesn't. So falcon connects on A10 but never actually receives your voice.

If you want to keep poking at the part that's still open, that's the frontier, not the cloud stuff. Since you've got Shizuku on cipher, the interesting probes are:

• adb shell dumpsys audio | grep -i silenced while a mic app is backgrounded (confirms the block), then foreground it (should flip to silenced:false).
• adb shell cmd appops get <pkg> RECORD_AUDIO and whether cmd appops set <pkg> RECORD_AUDIO allow via Shizuku changes the silenced: state at all.
• Whether the privileged hotword audio source behaves differently from the normal mic source
  .
  If any of those move the needle on a 2nd-gen Portal+, that'd be a real lead. Thanks again, this is exactly the kind of report that makes the eventual A10 fix more likely.