How to Avoid Delivering a Crash-Prone Android App

512
Bugsnag
Bugsnag automatically detects errors in your mobile, front-end, and back-end applications. It gives your team the tools to fix things fast. 3,500 engineering teams such as Square, Shopify, and Airbnb use Bugsnag.

‍This blog post is by James Smith, CEO & co-founder of Bugsnag. It has been adapted from a popular conference talk given at DroidCon SF, AnDevCon, and various other company conferences. Learn about the common reasons Android apps crash and key takeaways for how to avoid them.


Whether you’ve recently launched an Android app or are in the process of building one, every Android developer quickly discovers a fundamental truth: crashes are your worst enemy. Not only are they harder to prevent in native Android apps than in iOS, but crashes are also more likely to occur.

Before we dive into six reasons why these failures happen and how to defend against them, let’s start with some basics about bugs and user behavior.

Know thy enemy

Do you know the dirty little secret of software development? It’s a simple, if rather unfortunate, truth: you cannot fix every bug. No matter how much you try, bugs will always exist.

What you can control is identifying the most harmful issues and collaborating to fix them as quickly as possible. Not surprisingly, crashes qualify. They matter a great deal, and here are two reasons you want to minimize their occurrence:

  1. Users are quick to abandon apps, even when they perform flawlessly. One in five users abandons an app after only one use. Before you say, “Well, that’s not too horrible,” keep in mind that the first use is only the initial hurdle. The average app loses 77 percent of its daily active users within three days of installation, 90 percent after 30 days, and more than 95 percent within the first three months. Tough audience.
  2. You’ve got stiff competition. Whether you know it or not, an alternative to your app exists in the Android app store. With 2.6 million apps available as of December 2018, users can easily find a replacement if yours disappoints. When consumers have options, the pressure is on you to deliver a quality product, and a substantial part of that promise is stability.

Crashes are cause for a break-up

Given those scary user retention numbers, it’s imperative that your app makes a strong impression from the get-go and then continue to provide a crash-free experience. Users have a very low tolerance for crashes, and a full 84 percent will abandon your app completely if they experience two crashes.

If you still have your doubts about the seriousness of a crashing app, peruse the comments section in Google’s Play Store on a couple of low-ranking apps. What you’ll discover quickly is that crashy apps make for cringe-worthy fodder (although this feedback is obviously not-so-fun for the app developer).

In short, trust goes out the window when an app crashes, and along with trust is the app’s reputation. A crash is a death knell and demonstrates why you must care about production monitoring from the very beginning.

Pro tip: Adopt a stability monitoring tool like Bugsnag to set stability goals, get a handle on bugs, and rank them by impact.

Six reasons Android apps are crash-prone and what to do about it

As you likely know, building client-side software means your apps are running in an environment that’s out of your control. While server-side you can determine hardware, operating system, and which version of your app is live, none of that holds true client-side.

Think of client-side as the Wild West. Roughness, lawlessness, and disorderly behavior prevail. As befits this environment, there are six reasons why your Android apps are crash-prone. Thankfully, there are (usually) steps you can take to address the challenges.

Reason #1: Fragmented hardware

Unlike iOS hardware, which Apple keeps on a notoriously tight leash, Android devices multiply like rabbits. In fact, more than 24,000 unique Android devices were counted in 2015, which was six times as many as three years before in 2012. The situation has only intensified in the last three years, so it’s safe to say that Android app developers are dealing with an incredibly fragmented hardware environment where many old versions are still in use, including phones from 2009.

Yup, phones from ten years ago are still in use. And, yes, that is scary.

What that means is that your app needs to run on devices with different CPU architectures, varying CPU and memory constraints, and that lack hardware features you might naturally expect (camera, Bluetooth). Because Android devices are often found in emerging markets and developing countries, there are many versions out there that cost less, have cheaper components and CPU, and have low amounts of memory. How do you handle these scenarios?

Actionable defenses: You have a couple options that can help safeguard you from disappointing a user.

  1. Detect features pre-download. Use the element in your app manifest to filter your app so that it doesn’t show up for users whose devices do not meet your hardware and software requirements. For example, if a device doesn’t have a camera, then you won’t show up in that user’s app store options.
  2. Detect features at runtime. If the feature or hardware need is non-essential to your app, then you can push off the decision until runtime. In other words, if the user attempts to use the camera but there’s none available, the app can check and then tell the user they don’t have it available. This scenario is a much better user experience than a crash.

Reason #2: Rooted devices

It’s much easier to gain root access to the Android operating system, which leads some advanced (and sometimes not-so-advanced) users to tweak their phones and tablets in unpredictable ways. When various subsystems and settings change, the components your app relies upon may be inaccessible. For example, rooted devices may block access to certain permissions at runtime, which inevitably leads to crashes.

Actionable defense: Your best defense is to detect rooted devices at runtime. It is possible to use root detection techniques and thereby restrict access to certain features and functionality within your app. Alternatively, some companies stop the app from working at all on rooted devices to avoid the dreaded crashes.

Reason #3: Multiple Android versions

What’s the only thing more frightening than how many different Android devices are being used? That would be the number of operating systems currently in use. While Android lists thirteen platforms with more than 0.1% usage, it’s striking to note that the Marshmallow platform from 2015 is the second most widely used version (21.3%) behind the current Oreo platform (21.5%). Even though Marshmallow is over three years old, it’s still going strong, as are the two platforms that preceded it (2014 Lollipop at 17.9% usage, 2013 KitKat at 7.6% usage).

Needless to say, people in Androidland do not upgrade (and sometimes can’t do so even if they want to due to carrier settings), so it’s guaranteed that your app will run on multiple platforms. The question is, how many? The Android developer website recommends supporting 90% of active devices, but targeting your app to the latest version.

Actionable defenses: Once again, there are several best practices you can follow.

  1. Specify supported versions in manifest. By identifying what the minimum version of Android is that you support in the manifest file, you can prevent your app from showing up in the Android store for any users with prior versions.
  2. Detect version at runtime. If the API call is non-essential to your app, then you can push off the decision until runtime. For example, you can check for either a feature or the platform version at runtime and then disable particular features depending on the environment.
  3. Use the Android Support Library. How would you like to make it seamless to support multiple API versions without sacrificing new features? When you embed the Support Library into your app, you can leverage it as a compatibility layer to older Android versions. That means less code to build and happier users who are supported appropriately in whatever version they use. In short, you don’t have to wait for your customers to upgrade, which is a reason to rejoice.

Reason #4: Vendor modifications

Well, this reason is terrifying: phone manufacturers can make modifications to core parts of the Android operating system. Not surprisingly, when core parts are edited, it can lead to crashes in your app. One example came about when HTC shipped their own version of GSON as part of their Android fork, which was super buggy and caused major issues with apps. The result? Crashes, of course.

Actionable defense: Sadly, there’s not much you can do about these types of crashes. Your only line of defense is to use a stability monitoring tool like Bugsnag so you can at least see what the problem is when this type of crash happens. Otherwise, the best we can say is…

¯\_(ツ)_/¯

Reason #5: Multiple live app versions

Here’s a frustrating fact of client-side applications: customers do not update apps immediately. While it’s getting better these days with Android’s automatic updates, there’s still the potential that multiple different versions of your app can be live at the same time. You need to make sure the language they are speaking is the same language your service is speaking.

Actionable defense: Thankfully, this defense is relatively straightforward: version your APIs from day one. Any app that accesses network services must be backward compatible.

Reason #6: Out of memory errors

Our final crash reason happens to be the bane of developers’ existence, and even a stacktrace for the error won’t be helpful for solving the issue. An out of memory error is thrown when there is no memory left for your app to use. Keep in mind though, the last memory allocation that triggered the error is not necessarily what caused the memory leak, which is why the stacktrace won’t help you. Instead, prior memory allocations added up, and it was only the last one that reached the threshold. Think of it as the straw that broke the camel’s back.

Actionable defense: There’s a tool called LeakCanary that was built by the team at Square. It detects memory allocations and can spot when this scenario is occurring. LeakCanary has been billed as a memory leak detection library for Android (and you’ll be happy to know there’s a Bugsnag integration for it as well!).

Don’t let crashes get you down

The heartening news is that you’re not alone. Crashes happen to every app. In fact, in our experience, even high-quality applications crash between 0.1-1% of the time, and that’s okay.

Crashes are a part of software life, but they don’t have to ruin your app’s chance at long-term existence. Come prepared, put up defenses like the ones described above, and never fly blind in production. Use a stability monitoring tool like Bugsnag to make sure you know your bugs and can stop the ones that make you crash-prone.

Now go forth and conquer Androidland with your crash-resistant app!

Bugsnag
Bugsnag automatically detects errors in your mobile, front-end, and back-end applications. It gives your team the tools to fix things fast. 3,500 engineering teams such as Square, Shopify, and Airbnb use Bugsnag.
Tools mentioned in article
Open jobs at Bugsnag
Front End Software Engineer
San Francisco, CA
Bugsnag gives engineering teams the tools and workflow they need to focus more on shipping software and less on fixing bugs. We help teams take a proactive approach to software quality, translating their errors into action. Thousands of companies like Square, GitHub, Shopify, and Pandora use Bugsnag as a daily dashboard to ship web, mobile, and desktop apps that can evolve with the pace of their business. Our front-end dashboard application and static sites are some the main ways our customers interact with Bugsnag. Our team is growing and we're taking on bold, new challenges everyday. We'd love to see what we can do next with your help.
  • React — our main customer-facing dashboards are built using React
  • Reflux.js — we follow the Flux architecture for data flow in our dashboard
  • Ruby on Rails — our dashboard APIs are powered by Rails
  • Sass — clean, componentized CSS built with Sass/scss is used on all of our sites
  • D3.js — we use d3 to graph error data in our dashboard
  • ES6 with babel — we're JavaScript fans who like to be able to test out the latest JS features
  • Webpack — we're using the Webpack module bundler for our dashboard assets
  • Many more — we're a polyglot company, detecting errors on every platform
  • Implement user interfaces and features in Bugsnag’s products and marketing properties
  • Create elegant, reusable front-end components that work within complex web applications
  • Collaborate with product designers, marketers, and other software engineers to deliver great user-facing products and experiences
  • A passion for building compelling user-facing products and beautiful websites
  • Strong HTML/CSS experience, including concepts like layout, specificity, cross browser compatibility, and accessibility
  • JavaScript experience, including concepts like asynchronous programming, closures, types, and ES6. Experience with React a strong plus.
  • Experience working with native browser APIs and optimizing front end performance
  • A willingness to dive into new technologies and solve unfamiliar problems as the need arises
  • Ruby/Rails development experience is a plus
  • At least 1-2 years of professional experience writing production-ready front end code
  • We value ownership, learning, and personal development.
  • We're building a strong culture of transparency and honesty.
  • We have a beautiful office in downtown San Francisco.
  • We have a safe and inclusive work environment.
  • We offer great benefits: lunch on us every day, medical, dental, vision, 401k matching, commuter stipend, annual conference attendance, and your choice of Apple hardware.
  • Senior Platforms Engineer
    San Francisco, CA
    We are looking for a new platforms engineer to help deliver an amazing experience to our customers while contributing back to the open source community. Our open source libraries support detecting crashes and capturing diagnostic data in several programming languages and frameworks. This position involves working with a variety of programming languages and development environments to build new features, help customers troubleshoot problems, review contributions to our open source libraries, and generally make developers’ lives easier.
  • You will develop and document new features in our open source libraries to expand the development platforms supported by Bugsnag.
  • You will test and update libraries to work with the evolving software ecosystem, such as the web frameworks, analytics SDKs and other libraries customers may be using at the same time as a Bugsnag integration.
  • You will troubleshoot issues reported by customers via GitHub issues, improving documentation based on common patterns.
  • You will go to software development conferences to keep up with best practices and new technologies, answer customer questions, and receive feedback on using the product and libraries.
  • You will build tools to make support and maintenance easier, like automating common tasks and interactions.
  • You love working in multiple different technologies and programming languages.
  • You can spend a few weeks learning a new platform, and feel proficient in helping others to troubleshoot installation instructions and syntax errors.
  • You have a personable, empathetic and professional manner when dealing with customers.
  • You have experience in C, Objective-C, Ruby, or React Native are a plus.
  • We value ownership, learning and personal development
  • We have a strong culture of transparency and honesty
  • We have a safe and inclusive work environment
  • Pick your own hardware (Thunderbolt display, top-end MacBook Pro, whatever you need)
  • Great benefits (medical, dental, vision, 401k, commuter stipend, conference attendance)
  • Lunch on us every day
  • Platforms Engineer
    San Francisco, CA
    Bugsnag helps teams focus on building better software by providing automated crash monitoring for web, mobile, desktop, and server apps. Currently, half of a typical developer’s time is spent finding and fixing bugs; we aim to bring that number as close to zero as possible by automating the entire monitoring process and allowing developers to focus their time on feature development. To do this, we give our users instant visibility into where their code is not executing as expected, we then measure these errors, collect all related data, and give our users the information they need to understand which software issues really matter and need fixing. Launched in February 2013, Bugsnag processes hundreds of millions of crashes per day for over thousands of developers at companies like Airbnb, Lyft, Square, and Shopify. Headquartered in San Francisco, California we have a small team of 28 employees and growing! We are looking for a new platforms engineer to help deliver an amazing experience to our customers while contributing back to the open source community. Our open source libraries support detecting crashes and capturing diagnostic data in several programming languages and frameworks. This position involves working with a variety of programming languages and development environments to build new features, help customers troubleshoot problems, review contributions to our open source libraries, and generally make developers’ lives easier.
  • You will develop and document new features in our open source libraries to expand the development platforms supported by Bugsnag.
  • You will test and update libraries to work with the evolving software ecosystem, such as the web frameworks, analytics SDKs and other libraries customers may be using at the same time as a Bugsnag integration.
  • You will troubleshoot issues reported by customers via GitHub issues, improving documentation based on common patterns.
  • You will go to software development conferences to keep up with best practices and new technologies, answer customer questions, and receive feedback on using the product and libraries.
  • You will build tools to make support and maintenance easier, like automating common tasks and interactions.
  • You love working in multiple different technologies and programming languages.
  • You can spend a few weeks learning a new platform, and feel proficient in helping others to troubleshoot installation instructions and syntax errors.
  • You have a personable, empathetic and professional manner when dealing with customers.
  • You have experience in C, Objective-C, Ruby, or React Native are a plus.
  • We value ownership, learning and personal development
  • We have a strong culture of transparency and honesty
  • We have a safe and inclusive work environment
  • Pick your own hardware (Thunderbolt display, top-end MacBook Pro, whatever you need)
  • Great benefits (medical, dental, vision, 401k, commuter stipend, conference attendance)
  • Lunch on us every day
  • Platforms Engineer, Front-end
    Bath, UK
    We are looking for a software engineer to help deliver an amazing experience to our customers while contributing back to the open source community. Our open source libraries support detecting crashes and capturing diagnostic data in several programming languages and frameworks. This position involves working with browser based development environments to build new features, help customers troubleshoot problems, review contributions to our open source libraries, and generally make developers’ lives easier.
  • You will help maintain the Bugsnag libraries for browser javascript
  • You will test and update libraries to work with the evolving software ecosystem, such as front-end frameworks (Angular, React, Ember etc), analytics SDKs, and other libraries customers may be using at the same time as a Bugsnag integration
  • You will develop and document new features in our open source libraries to expand the development platforms supported by Bugsnag
  • You will troubleshoot issues reported by customers via GitHub issues, improving documentation based on common patterns
  • You will go to software development conferences to keep up with best practices and new technologies, answer customer questions, and receive feedback on using the product and libraries
  • You will improve the end to end experience of using our javascript library to monitor some of the biggest websites in the world
  • You love working in multiple technologies and programming languages
  • You have experience in developing in Javascript
  • You have a personable, empathetic and professional manner when dealing with customers
  • You have a minimum of 3 years of experience as a software engineer
  • Experience with various front-end frameworks and build systems a plus
  • Experience with node.js a plus
  • We value ownership, learning, and personal development.
  • We're building a strong culture of transparency and honesty.
  • We have offices in downtown San Francisco and central Bath.
  • We have a safe and inclusive work environment.
  • We offer great benefits: lunch on us every day, pension contributions, private medical insurance, company sponsored tech conference attendance, and your choice of Apple hardware.
  • We offer all new Bath hires a trip out to San Francisco to meet the team.
  • Verified by
    Sr. PMM
    Co-founder and CEO
    Senior Growth Marketing Manager
    You may also like