OpenBubbles recognizes genuine Mac activation data, but pressing Use this Device returns to the same screen with a Rust panic before Apple Account sign-in.
Environment
- Official Google Play installation: versionName 1.15.0, versionCode 20002229
- Android 16 / API 36 ARM64 Google Play emulator on Apple Silicon
- Genuine physical Mac activation data from official notarized Mac Hardware Info 1.2.0
Reproduction
- Complete onboarding permissions and choose self-hosted activation.
- Copy fresh activation data from the physical Mac helper into the Android client.
- Confirm the client recognizes the Mac and shows My Device / Use this Device.
- Press Use this Device.
Actual result
Brief processing, then the same device screen. No Apple Account authentication has occurred.
PanicException(called `Option::unwrap()` on a `None` value)
HwInpState.connect
package:bluebubbles/app/layouts/setup/pages/rustpush/hw_inp.dart:1021
awaiting setupPush
Sanitized immediate sequence: APS Activating → keystore destroys activation key → imports activation key → wrapped ASN.1 prepared → panic. No -59 error code was found in the captured process-log window. This does not establish import success or identify the failing Rust line.
Troubleshooting
- Restarted only the app process, preserving app data.
- Repeated with freshly copied genuine Mac data.
- Slowed code entry until My Device recognition. An exact full-field equality check was inconclusive after the UI transition; device recognition, not byte equality, is what was verified.
- Failure reproduced after recognition of the fresh code.
Independent emulator capability checks
Two isolated instrumentation tests in a separate app UID passed:
- RSA-1024 PKCS#8 wrapped import, imported public-key equality, and SHA1withRSA signing/verification.
- AES-256 wrapped import with GCM / 128-bit minimum MAC, followed by encryption/decryption verification.
Both used random disposable keys, RSA-2048 OAEP SHA-256 transport wrapping with MGF1 SHA-1, and removed their aliases afterward. The algorithm choices match the inspected public OpenBubbles implementation.
These tests do not exercise OpenBubbles' ASN.1 encoder, Rust/FFI bridge, private app state, or exact installed binary. They only show the emulator supports these tested operations.
Related reports and questions
Possibly related to #185, #254 and PR #184, but the exact error differs; I have not established the same root cause. This occurs before sign-in, unlike #87.
- Is this Android 16 ARM64 emulator configuration supported when using genuine physical Mac activation data?
- Is there a released Android fix or supported workaround?
- Which minimal sanitized diagnostics would identify the failing Rust line without disclosing activation material?
Public source inspection used the default rustpush branch and rustpush dependency a7fab473e7a33325a760635285db2860de8e1cb0; source-to-Play-binary parity is unverified. The GitHub latest release's Linux asset does not establish Android build parity.
No account identifiers, phone numbers, Mac serial, activation code, wrapped-key payload or raw logs are attached.
OpenBubbles recognizes genuine Mac activation data, but pressing Use this Device returns to the same screen with a Rust panic before Apple Account sign-in.
Environment
Reproduction
Actual result
Brief processing, then the same device screen. No Apple Account authentication has occurred.
Sanitized immediate sequence: APS Activating → keystore destroys activation key → imports activation key → wrapped ASN.1 prepared → panic. No -59 error code was found in the captured process-log window. This does not establish import success or identify the failing Rust line.
Troubleshooting
Independent emulator capability checks
Two isolated instrumentation tests in a separate app UID passed:
Both used random disposable keys, RSA-2048 OAEP SHA-256 transport wrapping with MGF1 SHA-1, and removed their aliases afterward. The algorithm choices match the inspected public OpenBubbles implementation.
These tests do not exercise OpenBubbles' ASN.1 encoder, Rust/FFI bridge, private app state, or exact installed binary. They only show the emulator supports these tested operations.
Related reports and questions
Possibly related to #185, #254 and PR #184, but the exact error differs; I have not established the same root cause. This occurs before sign-in, unlike #87.
Public source inspection used the default rustpush branch and rustpush dependency a7fab473e7a33325a760635285db2860de8e1cb0; source-to-Play-binary parity is unverified. The GitHub latest release's Linux asset does not establish Android build parity.
No account identifiers, phone numbers, Mac serial, activation code, wrapped-key payload or raw logs are attached.