How can I debug a seemingly hardware-dependent issue with my Android app without access to the hardware?

I have an open-source application on the Android market. It seems to work fine for me (with over 1,000 active installs, I have to presume that it works for most people).

I recently got a bug report that indicated a problem for at least three users on Samsung phones (Intercept and Captivate). I have been unable to reproduce the problem on my ADP2 and on the emulator.

In order to get enough data to diagnose the problem, I first tried to add logging and then I asked users to submit logs via Log Collector. Each time a user tried to send the log (there were four attempts), it was truncated and I did not get any useful data.

I then added ACRA to the project in an attempt to get information, but I don't seem to be able to automatically detect the bug in order to send a report.

Since I don't have a Samsung phone and I can't reproduce it on anything where I could connect with the debugger, I am mostly out of ideas. The only idea I have left is to add a button to the UI to generate a report.

Are there any other approaches to suggest?

Update: since people are asking for more specifics: essentially, the app reads in text files from the assets and puts them (with some preprocessing) into a TextView in a ScrollView. (The data is prgressively added to a SpannableStringBuffer and then that is passed to TextView's setText() function.) Depending on the options chosen, the text displayed is between 15k-115k. On phones with this issue, only part of the text is displayed. The cutoff point depends on the options, but seems to be somewhere between 17k-18k.

ACRA sends a report for all uncaught exceptions and puts them into a Google Form/Spreadsheet. I've gotten reports from my emulator and from my phone, so I know that end works. (Actually, I've often found it faster to debug from the stack trace in that report than to attach the debugger to the process.)

Phone specs: I have exerci开发者_JS百科sed the app on emulators running 1.5, 1.6, 2.1, and 2.2. My phone is ADP2 (the developer version of the MyTouch), but I've installed a third-party ROM to jump up to Froyo (2.2). I am unaware of an emulator specifically for the Samsung OS build, although that would be quite helpful here.

Since the expected text length is constant, I should be able to detect if it is read correctly or not. I added checks at the end of my text processing, but those never triggered, indicating that the problem was not with reading the file. I then tried adding checks to onPostCreate and onPostResume, but those did not fail either. It seems that the UI thread had not yet actually run at that point, though.

I've now done 6 private APK versions attached to the bug in the bug tracker. I frankly am surprised that any users are still trying them. This latest version has a button to force a bug report - that will only be called after the UI thread has laid out the screen. Hopefully that will give me enough variable information to point me in the right direction.

We'd need to know more about the nature of the problem. Is it a crash? Something doesn't look right? Etc.

If it's a crash, you could add a crash handler (Thread.setUncaughtExceptionHandler, IIRC) and have that create a better-formatted log that can optionally be sent to you.

Also, try to collect information about the specs of the phones (OS, resolution, etc) and repro that in the debugger. Those Samsung phones have Android 2.1 - your Nexus probably has 2.2? Did you try setting the emulator up to use 2.1?

Whenever I had these issues, I politely asked those who wrote me if they were interested in helping me - and there were typically several people who were eager to volunteer. I sent them an APK file with a special test version that had additional debug output, and that helped me narrow down the problem.

The bug turns out to be an undocumented default on (some?) Samsung phones that limits the maxLength attribute of a TextView widget to 9,000 characters. Explicitly adding an "android:maxLength" attribute with a value large enough to contain my largest text length to the TextView widget solved the problem.

Incidentally, I believe that this same issue is what caused the LogCollector logs from the initial reporters to be truncated.