Skip to main content

8 Common Shake SDK Setup Misconfigurations

A quick troubleshooting guide to the most frequent hurdles developers face when integrating Shake for the first time.

Written by Shake Typing
Updated this week

1. Using a "REST API" key instead of an "App API" key

The Problem: On your dashboard, you see two types of keys: App API key and REST API. If you use the REST API key in your mobile app, you are exposing a key that has power to read your private data.

The Fix: For your Shake.start() code, you must exclusively use the key labeled SDK (App API) This key is "write-only," meaning it can only send bug reports and cannot be used to peek at your dashboard data.

  • Action: Go to your Shake Dashboard, click on your specific App then click the App settings. Scroll down to API keys and click Add new, and pick SDK. Just make sure the SDK (App API) tab is selected (not REST API) before you copy the string.

2. Using the same API Key for Internal and Production builds

The Problem: Your dashboard becomes a mess of test data and real bug reports, making it impossible to stay organized.

The Fix: Each app in Shake is a separate container. You should have one "App" for Development and another for Production.

  • Action: Create a new app for each environment to get a unique App API key for each.

3. "It works on the Emulator, but not on a real device"

The Problem: The "Shake" gesture triggers easily in the simulator, but your physical phone feels like you have to break it to get a response.

The Fix: The default sensitivity (600) is often too high for the sensors on physical devices.

4. Network Blockers (Android Permission / iOS ATS)

The Problem: The SDK initializes, but tickets never arrive at the dashboard.
​The Fix:

  • On Android: You likely forgot the INTERNET permission. Without it, the OS kills any attempt to "call home."

    • Action: Add <uses-permission android:name="android.permission.INTERNET" /> to your AndroidManifest.xml.

    • Read more: Android Installation

  • On iOS: You might be hitting App Transport Security (ATS). If your network logs or custom endpoints use non-secure (HTTP) connections, iOS will block them silently.

    • Action: Ensure your app and any custom endpoints use HTTPS. If you must use HTTP, you need to add an exception to your Info.plist.

    • Read more: iOS Installation

5. Late Initialization in the App Lifecycle

The Problem: Shake misses "cold start" crashes (crashes during launch) because the SDK wasn't "awake" yet.

The Fix: You must initialize Shake at the earliest possible entry point for both platforms.

  • Action (Android): Call Shake.start() in the onCreate method of your Application class.

  • Action (iOS): Call Shake.start() in the didFinishLaunchingWithOptions of your AppDelegate.

  • Read more: Android Installation

  • Read more: iOS Installation

6. Code Stripping & Obfuscation (Android R8 / iOS Bitcode)

The Problem: The app works in Debug but crashes or doesn't show the Shake UI in the final production build because the compiler "cleaned up" the code too aggressively.

The Fix:

  • Android: R8/ProGuard deletes Shake classes. You must add -keep rules.

  • iOS: While less common since Xcode 14, aggressive optimization or dead-code stripping can occasionally affect third-party binaries.

  • Action: Ensure your build process includes the necessary "keep" rules or configuration for the Shake SDK.

  • Read more: Android Installation

  • Read more: iOS Installation

7. Missing Screenshots (Android FLAG_SECURE / iOS Screen Shield)

The Problem: Bug reports arrive, but the screenshot is a solid black or blurred rectangle.

The Fix:

  • Android: You have FLAG_SECURE on the Activity. This blocks all screenshots.

  • iOS: iOS doesn't have a global "Flag Secure," but if you use isSecureTextEntry on a field or have a "Screen Shield" privacy overlay (like for banking apps), the screenshot will be blanked out.

  • Action: Instead of blocking the whole screen, use Private Views to hide only the sensitive fields (like passwords or CC numbers) so the rest of the bug report is still useful.

  • Read more: Private views (Android)

  • Read more: Private views (iOS)

8. Unreadable Crash Reports (Android Mapping / iOS dSYMs)

The Problem: You see a crash, but it's just meaningless code like at a.b.c(SourceFile:1) or 0x0000000104....

The Fix:

  • Android: You need to upload your mapping.txt file produced by R8/ProGuard.

  • iOS: You need to upload your dSYM files produced by Xcode.

  • Action: Automate the upload of these "translation" files so every crash report on your dashboard is readable.

  • Read more: Android Crash Reports

  • Read more: iOS Symbolication

Did this answer your question?