11

As an Android developer, the target market I create apps for is very fragmented. While I can specify certain requirements - e.g. my app only supports Android version x.x or above, sometimes errors may occur that are only evident on one specific phone model.

Are there any strategies to handle device-specific errors, without buying the phone in question? We maintain a suite of phones for testing, but can't afford to go out and buy a new phone when 2 or 3 users report that there's a bug that only occurs for their model of phone.

I'm sure other Android developers have encountered similar issues in the past, and I'm curious what cost-effective strategies are available to help squish device-specific bugs.

Update to add a few details:

  • I use Bugsense to capture bug reports, so whenever exceptions are thrown I will know the model of the phone, the stack trace, the number of times it has happened to my users, and a few other details.
  • The users may be located in different countries, so I can't assume I'll ever be able to borrow their phone.

Imagine a scenario like this: 100 users have installed the app, but three people complained that a button doesn't work properly when pressed. None of the models of phone I have for testing experience the problem. There doesn't appear to be an emulator for the problem phone model.

StackExchange What The Heck
  • 328
  • 1
  • 3
  • 14
  • 2
    Our local incubator teamed up with a local cell phone company to create a [mobile handset library](https://www.nwoinnovation.ca/article/-1005.asp) to solve exactly this problem - you may be able to find something similar in your area (or suggest it to some appropriate people). – Hannele Mar 28 '14 at 13:29
  • You stood up for your question and asked it to be reopened. Please make sure you give as much thought to choosing an answer. – JeffO Apr 04 '14 at 16:59
  • for the reference: [meta discussion of this question](http://meta.programmers.stackexchange.com/questions/6566/how-to-re-word-or-fix-my-question-so-it-can-be-answered "How to re-word or 'fix' my question so it can be answered") – gnat Apr 28 '14 at 11:39

2 Answers2

10

Years ago, I used to run into the same problem developing software for Palm devices. There are a couple of obvious strategies:

  • Having users help with the testing - have a beta testing program, have your app give good information on errors, and have a good way to report bugs.
  • Using device-specific emulators

Both are quite limiting, though. There is no surefire substitute for having the actual device.

One interesting thing I came across is AppThwack, a company that lets you remotely test hundreds of real Android devices. I have no experience with this personally, but it looks promising (it's also a strong indication that there's no easy, cheap answer to your problem).

  • 1
    +1 for AppThwack. They have tons of devices and you can direct your testing at certain device pools. You can instruct the instrumentation to take screenshots and you get crash logs for each device. It's a pretty good substitute for not having every known device on hand (= – David Cowden Mar 24 '14 at 17:26
  • +1 for "best testing program", I had one for my battery-tracking Android app. When I sent it to a user who was getting bizarre results, and got the debug output, it was an extremely WTF moment: He'd somehow screwed up his phone such that Android itself was reporting 60% battery one minute, 40% the next, 80% the next, and it just kept jumping around. Can't do anything at that point in the app to fix it, they needed to fix their phone. – Izkata Mar 30 '14 at 07:05
-1

Unfortunately there is no easy answer to this problem.

to refine @dan1111 answer Having users help with the testing for android

  • add many log statements in you android-app that log important context information à la
    • now opening database "/data/data/my.namespace.com/databases/myDatabase.db" or
    • now calling webservice "my.server.com/loadingOrder(id=22)"
  • ask the user to install alogcat on the device that can read the local debug-log and instruct him how to set filter to track the source of the problem and send you the log.
Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
k3b
  • 7,488
  • 1
  • 18
  • 31
  • what's the point of installing alogcat, while OP says they've got something like that already: "use Bugsense to capture bug reports, so whenever exceptions are thrown I will know the model of the phone, the stack trace, the number of times it has happened to my users, and a few other details..." – gnat Mar 27 '14 at 05:59