Slides for my talk at Oredev: http://oredev.org/2015/sessions/crash-fast-square-s-approach-to-android-crashes The Square Register Android app has few crashes. Getting there requires a systematic approach: coding defensively, gathering information, measuring impact and improving architecture.;This talk presents our concrete steps towards lowering the crash rate, from the general philosophy to the tools we use, together with real crash examples.

1. Crash Fast
&
Furious
Pierre-Yves Ricau / @Piwai
Run Keeper / morning. End of run, save: crash

3. Source: https://t.co/uH1EqxqAow
* Study that’s available on hp.com
* Stole slide from Doug Sillars

4. Not your fault. Fragmentation, bugs in manufacturer. Lifecycle. Fragments.

5. * “Why do they waste their time on this?”
* “Why don’t they fix the crashes first?”
* Crash: your fault. Even when not your own code is at fault.

6. What’s a crash?

7. Reminder: Android = linux, 1 app = 1 VM = 1 process
Crash: something bad happen, need to kill that process and restart it.

8. 1
2
* Threads: exception handler per thread
* Exceptions bubble up, delegated to exception handlers
* If no handler, goes to static default

9. 1
2
3
* Focus on crashes in Java land
* Uncaught exception delegated to default handler

10. 1
2
3
4
* main: when program starts
* log, dialog, kill.

11. * How many people click “Report”?
* What do most people do?
* Can’t use Play Store Crash reports

12. 1
2
* You can create your own.
* Don’t do that. Client is easy, backend is hard.

13. * Crashlytics: closed source, UI for noobs
* ACRA: OSS client, free, host your backend
* Bugsnag: OSS client, small teams, small API, scaling issues

14. Native Crashes
1
2
* Signal sent to the process, need a signal handler
* Uses Google breakpad
* Fake exception

15. First thing to look at?
=> stack trace

16. * line numbers => checkout correct version of sources
* Smart stacktrace => stupid

17. * Stacktrace: quick fix of simple error
* Who started animation, why?
* Stacktrace on server: each frame is a layer
* Callback => loss of info. Stacktrace not enough.

18. Reproducing
* How can we reproduce the crash?

19. * Associate customer id to crash
* Best is to ask customer what they did.
* Great for alpha / internal testing.

20. * Startup is the worst. Crash after work is second.
* Asking for feedback channels frustration, avoids 1 star reviews.

21. * Custom crash dialog that asks for feedback.
* Good idea: offer a link to contact support
* Emotional connection to customer.

22. 1
2
3
4
* Can’t ask for feedback while crashing: display popup on restart.
* Risky: what if crash on restart. Don’t double restart. Maybe crash dedicated activity + different process.
* Twitter & Fb seem to do that.

23. Static info
* diff UI, diff code path => isTablet helps identify problem
* isTablet: sw600dp
* app version number + SHA version numbers for dev builds

24. * Picture of what the screen look like at time of crash.
* Bitmap? Too big. Upload description of view hierarchy.

25. Current screen
* What the user is looking at
* Current screen

26. 1
2
3
Find all windows: Espresso RootsOracle

27. * Black box.

28. History: high level log
1
2
* Steps of the user + internal state changes
* Look at log, reproduce the steps
* Navigation + Http calls

29. * OkHttp interceptor

30. OOM: Stack trace is useless.

31. squ.re/leakcanary
Detect memory leaks

33. * UI has validation rules
* Bug: somehow not enforced
* Crash time: too late to do something about it.

34. Exception
=
something
unexpected
happened
What do you do when something unexpected happens and the app crashes?
* We somehow got a blank email

35. Defensive programming
* Can’t figure it out.
* Fatal condition, shouldn’t happen. Problem ignored.
* Payments.

36. Offensive programming
Crash Fast
2
1
* Detect problems early
* Complain as loudly as possible
* Quality of code increases
* If you can’t understand, make the problem happen earlier, and ship it.

37. Exception Grouping
* Exceptions thrown by a common Preconditions class might be grouped together in the crash reporting tool.

38. 1
2

39. More assertions = more crashes.
How to keep low impact on customers?

40. Integrations tests
* Writing a feature = writing UI tests
* Espresso
* Run on VMs, no real devices. Parallelized
* 20min total build

41. Smoke testing
* Manual QA
* Testing parties
* Internal and payed external testers

42. Dogfood / Beta
* Internal releases: hard, need use case => lunch.
* Dogfood at sellers
* Betas work better.

43. Staged Rollout
* Test the waters
* Ship to 5%, 10%, evaluate crash rate and do minor dot releases

44. * Raw crash numbers: not useful
* Most important feature: take payments
* Crash per transaction

46. • Reproducing
• Static info
• Flight Recorder
• View hierarchy / state
• Crash Fast
• Staged rollout

47. Questions?
py@squareup.com
@Piwai
* We are hiring. SF, NYC, Canada.