我在 Android 市场上有一个开源应用程序。它似乎对我来说工作得很好（有超过 1,000 个活跃安装，我必须假设它对大多数人都有效）。
我最近收到了一份错误报告，其中指出了以下问题：至少三个三星手机用户（Intercept 和 Captivate）。我无法在 ADP2 和模拟器上重现该问题。
为了获得足够的数据来诊断问题，我首先尝试添加日志记录，然后要求用户通过 日志收集器。每次用户尝试发送日志（有四次尝试）时，它都会被截断，我没有获得任何有用的数据。
然后我将 ACRA 添加到项目中以尝试获取信息，但我似乎无法自动检测错误以便发送报告。
由于我没有三星手机，而且我无法在任何可以与调试器连接的地方重现它，所以我基本上没有想法。我剩下的唯一想法是在 UI 中添加一个按钮来生成报告。
还有其他方法可以建议吗？
更新：由于人们要求更多细节：本质上，应用程序从资产中读取文本文件，并将它们（经过一些预处理）放入 ScrollView 中的 TextView 中。 （数据逐渐添加到 SpannableStringBuffer 中，然后传递给 TextView 的 setText() 函数。）根据所选选项，显示的文本在 15k-115k 之间。在存在此问题的手机上，仅显示部分文本。截止点取决于选项，但似乎在 17k-18k 之间。
ACRA 发送所有未捕获异常的报告，并将其放入 Google 表单/电子表格中。我已经从我的模拟器和手机收到了报告，所以我知道结果是有效的。 （实际上，我经常发现从该报告中的堆栈跟踪进行调试比将调试器附加到进程更快。）
手机规格：我已在运行 1.5、1.6、2.1 和 2.2 的模拟器上运行了该应用程序。我的手机是 ADP2（MyTouch 的开发者版本），但我安装了第三方 ROM跳到 Froyo (2.2)。我不知道专门针对三星操作系统构建的模拟器，尽管这在这里会很有帮助。
由于预期的文本长度是恒定的，我应该能够检测它是否被正确读取。我在文本处理结束时添加了检查，但这些检查从未触发，表明问题不在于读取文件。然后我尝试向 onPostCreate 和 onPostResume 添加检查，但这些也没有失败。不过，此时 UI 线程似乎尚未实际运行。
我现在已经完成了 6 个私有 APK 版本，附加到错误跟踪器中的错误。坦率地说，我很惊讶居然还有用户在尝试它们。这个最新版本有一个按钮可以强制报告错误——只有在 UI 线程布置屏幕后才会调用该按钮。希望这能给我足够的可变信息来指引我正确的方向。
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 exercised 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.
发布评论
评论（2）
我们需要更多地了解问题的本质。这是崩溃吗？看起来有些不对劲？等等。
如果是崩溃，您可以添加崩溃处理程序（Thread.setUncaughtExceptionHandler、IIRC），并创建一个格式更好的日志，可以选择将其发送给您。
另外，尝试收集有关手机规格的信息（操作系统、分辨率等）并在调试器中重现该信息。那些三星手机有 Android 2.1 - 你的 Nexus 可能有 2.2？您是否尝试将模拟器设置为使用 2.1？
每当我遇到这些问题时，我都会礼貌地询问那些给我写信的人是否有兴趣帮助我 - 通常有几个人渴望自愿提供帮助。我向他们发送了一个带有特殊测试版本的 APK 文件，该版本具有额外的调试输出，这帮助我缩小了问题范围。
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.
事实证明，该错误是（某些？）三星手机上未记录的默认设置，它将 TextView 小部件的 maxLength 属性限制为 9,000 个字符。显式添加一个“android:maxLength”属性，该属性的值足以包含我最大的文本长度到 TextView 小部件解决了这个问题。
顺便说一句，我相信同样的问题是导致最初报告者的 LogCollector 日志被截断的原因。
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.