Bugs

Environment Shake Android SDK 17.2.2 (latest); same issue reproduces on our iOS app. Affects many end users, both platforms. What works Shake.registerUser(<appUserId>) succeeds — the user shows up in the Dashboard. Submitting a new ticket works; its first message is delivered and visible on the Dashboard under that user. Unread-chat-messages listener fires (chat receive channel is connected). What fails When the registered app user sends a REPLY in the in-app chat, the message is never delivered to the server — it does not appear on the Dashboard. In the app's chat screen, the user's own outgoing messages render on the LEFT side (as if incoming/from support) instead of the right. Repro Register user via Shake.registerUser after Shake.start. Submit a ticket → first message arrives on Dashboard under that user. OK. Open that ticket's chat, send a follow-up message. → Message shows locally as incoming (left), never reaches Dashboard. Diagnostics already done (ruled out on our side) Registration confirmed server-side (user visible on Dashboard), and it runs BEFORE chat is opened. The shake-open callback reports the correct user id. Disabling our app's Certificate Transparency enforcement made no difference. Sending a chat reply triggers no app-facing SDK callback, so the send path is entirely internal to the SDK. Attachment: Chat screen shot - on it first message "How come?" sent from the support (shake website) other messages sent from phone user. Our read Looks like the outgoing chat message is stamped with a userId that doesn't match the registered endUserId, so it's treated as incoming and not delivered as the user's own message. Question What determines the author (userId/endUserId) on an outgoing app-user chat reply, and why would it mismatch the registered user? Any known issue in 17.2.2 on the reply/chat path?

Fatal crash — kills the host app during cold start. Present in 17.2.2 (current release). BlurImageView.a(Bitmap, ArrayList) calls addAll() on its second parameter with no null check. When the SDK passes a null blur list, the host app dies. public void a(Bitmap bitmap, ArrayList blurs) { this.a = bitmap; this.j.clear(); this.j.addAll(blurs); // NPE when blurs == null } This is not fixed by upgrading We disassembled classes.jar from the published AARs for 17.2.0, 17.2.1 and 17.2.2. BlurImageView and its caller com.shakebugs.shake.internal.n9 are bytecode-identical across all three releases. The defect is in the current version. Stack trace java.lang.NullPointerException: Attempt to invoke interface method 'java.lang.Object[] java.util.Collection.toArray()' on a null object reference at java.util.ArrayList.addAll ( ArrayList.java:760 ) at com.shakebugs.shake.internal.view.BlurImageView.a (SourceFile:6) at com.shakebugs.shake.internal.n9$c.invokeSuspend (SourceFile:4) ... at com.shakebugs.shake.internal.n9.a (SourceFile:5) at androidx.lifecycle.LiveData.considerNotify ( LiveData.java:134 ) at androidx.lifecycle.LiveData.dispatchingValue ( LiveData.java:147 ) Crashed thread: main. Suspected trigger: process-death restore of the markup screen Not reproduced on demand, but the evidence is consistent: BlurImageView appears in exactly one layout in the AAR — shake_sdk_ticket_mark_fragment.xml, the screenshot markup fragment inside ShakeActivity. Both captured crashes happen on a cold start, ~600ms after session_start, with our app's native bootstrap still in flight. Brand-new process, not a user-initiated bug report. The call arrives through a LiveData observer replaying onto a freshly recreated view. Reading: user had the screenshot-markup screen open, Android killed the process, and on task restore ShakeActivity is recreated. The blur list isn't restored, LiveData replays null, and the unguarded addAll kills the app before anything renders. The reason this is severe despite being rare: it fires during our app's cold start, not during a bug-reporting flow. To the user, the app dies on launch for no visible reason. Environment SDK: com.shakebugs:shake:17.2.0 Devices: Samsung SM-S166V, Samsung SM-S908W (ARM64) Config: blackBoxData=false, activityHistoryData=false, consoleLogs=false, invokeShakeOnShakeDeviceEvent=false; screenshots enabled Volume: 2 users over 90 days in production Related Your iOS repo has a similar screenshot-pipeline crash — shake-ios #45, "Screenshot capture crashes with invalid bounds in SwiftUI view." Requested fix Null-guard the parameter in BlurImageView.a(Bitmap, ArrayList) — treating null as "no blurs" turns a fatal crash into a cosmetic loss of blur regions. Better still would be guarding at the source in n9, and checking whether the markup fragment's blur state should survive process death. Happy to provide full Crashlytics exports, breadcrumb logs, and our Shake.start() configuration.

Fatal crash — kills the host app during cold start. Present in 17.2.2 (current release). BlurImageView.a(Bitmap, ArrayList) calls addAll() on its second parameter with no null check. When the SDK passes a null blur list, the host app dies. public void a(Bitmap bitmap, ArrayList blurs) { this.a = bitmap; this.j.clear(); this.j.addAll(blurs); // NPE when blurs == null } This is not fixed by upgrading We disassembled classes.jar from the published AARs for 17.2.0, 17.2.1 and 17.2.2. BlurImageView and its caller com.shakebugs.shake.internal.n9 are bytecode-identical across all three releases. The defect is in the current version. Stack trace java.lang.NullPointerException: Attempt to invoke interface method 'java.lang.Object[] java.util.Collection.toArray()' on a null object reference at java.util.ArrayList.addAll ( ArrayList.java:760 ) at com.shakebugs.shake.internal.view.BlurImageView.a (SourceFile:6) at com.shakebugs.shake.internal.n9$c.invokeSuspend (SourceFile:4) ... at com.shakebugs.shake.internal.n9.a (SourceFile:5) at androidx.lifecycle.LiveData.considerNotify ( LiveData.java:134 ) at androidx.lifecycle.LiveData.dispatchingValue ( LiveData.java:147 ) Crashed thread: main. Suspected trigger: process-death restore of the markup screen Not reproduced on demand, but the evidence is consistent: BlurImageView appears in exactly one layout in the AAR — shake_sdk_ticket_mark_fragment.xml, the screenshot markup fragment inside ShakeActivity. Both captured crashes happen on a cold start, ~600ms after session_start, with our app's native bootstrap still in flight. Brand-new process, not a user-initiated bug report. The call arrives through a LiveData observer replaying onto a freshly recreated view. Reading: user had the screenshot-markup screen open, Android killed the process, and on task restore ShakeActivity is recreated. The blur list isn't restored, LiveData replays null, and the unguarded addAll kills the app before anything renders. The reason this is severe despite being rare: it fires during our app's cold start, not during a bug-reporting flow. To the user, the app dies on launch for no visible reason. Environment SDK: com.shakebugs:shake:17.2.0 Devices: Samsung SM-S166V, Samsung SM-S908W (ARM64) Config: blackBoxData=false, activityHistoryData=false, consoleLogs=false, invokeShakeOnShakeDeviceEvent=false; screenshots enabled Volume: 2 users over 90 days in production Related Your iOS repo has a similar screenshot-pipeline crash — shake-ios #45, "Screenshot capture crashes with invalid bounds in SwiftUI view." Requested fix Null-guard the parameter in BlurImageView.a(Bitmap, ArrayList) — treating null as "no blurs" turns a fatal crash into a cosmetic loss of blur regions. Better still would be guarding at the source in n9, and checking whether the markup fragment's blur state should survive process death. Happy to provide full Crashlytics exports, breadcrumb logs, and our Shake.start() configuration.

This issue occurs intermittently on app cold start when the user data request is delayed or the session is near expiry. In those cases, Shake creates a report without attaching the signed-in user, even though registration of user ID is performed. After it happens once, later reports may also lose user details even after logout/login or fresh install. Tried: updateUserID() did not fix it. updateUserMetadata(...) did not fix it. setMetadata("user_id", userId) only adds metadata to the ticket, but helped proving the user ID is correctly sent from our side (see attached screenshots).

We've encountered on both Android and iOS devices some instances where the shaking action doesn't do anything, it doesn't trigger the Shakebugs UI to show up in our app. For example, I can 100% reproduce the following test case in our Android app: open the app, wait for all Shake SDK methods to be called by our app: Shake.getReportConfiguration().apply {...} Shake.start(application, apiKey) Shake.setMetadata(...) Shake.registerUser(...) Shake.updateUserMetadata(..) shake the device nothing happens either put the device in sleep (press Screen lock physical button) OR minimize our app & then bring it back into foreground shake the device again ShakeBugs UI appears The expected outcome would be that step 6 should happen directly instead of step 3.

I have multiple issues with the web version for shake. If many requests are pending shake init takes a long time, it's loading and waiting for requests to finish. Therefore the User Experience is really bad with it if the network is slow. Even though Shake waits for all the requests to finish, it sends only requests that was captured BEFORE the button press, making the wait unnecessary and useless. Shake doesn't log with isNetworkRequestsEnabled = true requests like Keycloak init requests and other

After submitting a bug several screens on my app have their bottom safe area adjusted - it looks like for the space needed for the keyboard - even though it is no longer there. This only happens when Shake is dismissed by tapping the 'submit' button, it doesn't happen if I exit Shake with the close/X button.

When reporting a ticket and having a printscreen automatically taken after shaking the device, the screenshot taken becomes blank after typing something in the email or any other field. It happens a bit randomly, but in most of cases.

When running the Leaks tool in Xcode Instruments, Shake shows a memory leak related to "setEnabled". I don't have any access to the source code, but I have tried to remove and update my configurations to see if this has any effect on the leak, but it does not. Attached is a screenshot of a typical profiling session containing the leak, which is triggered immediately after invoking shake at AppDelegate's didFinishLaunchingWithOptions. Using Shake SDK 17.0.2 I can provide a full trace debug file if needed - just email me! :)