FAQ
Android SDK
Q: How to match a crash information to a specific cellphone on the website?
A: There are two ways to get the crash information of your device:
Method 1: filter crash information via uid.
a. Connect your cell phone to computer and find out the value of uid in LogCat, then you can filter crashes by uid on the website.
b. Take the following uid as an example: 69d86f0988d898df246e36071bb02baa
Crash number 950 is what we are looking for.
Method 2: filter crash information via User identifier.
a. User identifier is defined when initializing Crasheye.
(refer to Common APIs: User identifier）
b. If you have your User identifier as UserByCQF, you can search it like this:
All UserByCQF related crashes will be listed on the website.
Android NDK
Q: There are no stack trace of NDK related exceptions but that of Java related exceptions, is there something wrong?
A:Troubleshooting:
1. It can be caused by false initialization. Crasheye NDK initialization: Android
NDK interfacing guideline.
Crasheye.initWithNativeHandle(this, "Your_Appkey"); 2. The way to troubleshoot differs based on game engines, and there should be corresponding logging output in Logcat. Take Cocos2d as an example, you can find initialization logging in Logcat:
Check if there is NDK initialization logging output like the one above. If not, that means the NDK initialization failed and please re-initialize NDK referring to step No.1.
3. Make sure you didn’t obfuscate Crasheye code.
4. If you obfuscate the so files in your application, Crasheye can’t capture NDK-related crashes.
Q: Why NDK exceptions cannot be caught in some devices of Android 5.0 version or later?
A: It is owing to the old version of libCrasheyeNDK.so file. You can solve this problem by updating the .so file to the latest version from official website. （SDK download）
iOS SDK
There is <Error>: + [NSString ksgIsNilOrEmpty:]: unrecognized selector in the logging output after my application interfaced with Crasheye and crashed on startup. What does it mean?
A: Check if you didn’t add –ObjC setting in Linker Flags. (Refer to iOS SDK Integration）
Q: Where are the crash files located?
A: Location: Library/Caches/Crasheye.
Q: Why there is no crash files after a crash?
A: First, please check the logs and see if Crasheye has been initialized correctly. Second, please check whether your device is connected to debugger. No crash file will be created when cell phone is being connected to debugger.
Q: Why there is no records on the website after a crash?
A: Crash files will not be uploaded until the application is restarted.
Unity Plugin
Q: Why the script exceptions are not caught?
A: Troubleshooting: 1. If Try..catch statement is used in the outermost layer of application, exceptions will be caught by try..catch statement instead of Crasheye. 2. Check if Application.RegisterLogCallback function is used anywhere else in your application. If yes, please replace it with Crasheye.SetRegisterLogFunction as instructed in the Help file . 3. Make sure you initialize Crasheye.cs in the entry function of the program.
Q: What are the benefits of using MONO to interface Unity game with Crasheye?
A: Some C# related stack trace of NDK crash will be displayed as follows:
Q: How to use Unity plugin to search NDK stack trace details?
A: Pleas upload the symbol file in Unity plugin, including libmain.so, libunity.so and libmono.so, to Crasheye, Crasheye will automatically re-analysis, wait a moment to view the NDK stack detail;
Symbol Table
Q: What is symbol table? What is it used for?
A: Symbol table maps memory address to function name, file name, and line number. In order to locate the statement which causes app crash, Crasheye uses symbol table to analyze and restore stack trace of the code.
Q: Is a symbol table mandatory? When should we configure a symbol table?
A: It is optional and it will not affect exception reporting. However, we recommend you to configure it. Android( Java & NDK )symbol table configuration guideline iOS symbol table configuration guideline
Q: Why there is no detailed stack trace analysis after crashes while symbol file has been successfully uploaded?
A: Refresh page, See if the uuid in the pop-up notification at the head of the Crash Detail page matches any file in the uploaded files (Settings -> Symbols -> The Uploaded Files).
Q: Does the uploaded symbol file have size limit?
A: The maximum size of a single file is 1G when using the upload tool. There is no limit if you use our website to upload symbol files. Please rest assured.
Q: There is a message “run lipo -info false” when uploading files for iOS app. Is there something wrong?
A: Troubleshooting:
1. Check if you use the correct symbol file upload tool. The symbol file upload tool for iOS application is ***iOS***.jar while the symbol file upload tool is ***Android***.jar.
2. The path of symbol files do not support space. If there is space in the path, please delete it.
Crasheye Platform
Q: Do we need to pay for Crasheye services?
A: It is free for good. Please rest assured.
Q: Does Crasheye collet other information? If so, what data does it collect?
A: All the collected data are related to crashes. Crasheye shows developers the circumstance under which crash arises, and does not collect personal information. Furthermore, the results are only accessible to project members. Regular collected information including: Environment: crash information and stack trace, ROM/RAM, network condition, and system language etc. App information: package name, version, and process name Device information: device model, operating system, and resolution Developers can print out the uploaded logs to check all details.
Q: Is it open to the project which has not been online yet?
A: Yes, it is.
Q: Will there be conflicts if we build Crasheye and another third party SDK at the same time?
A: There might be conflicts in this situation. You can contact with Crasheye or the third party SDK official staff for solutions.
Q: Will there be conflicts if we use Crasheye and another similar SDK at the same time?
A: No. However, we recommend you to initialize Crasheye after initializing other SDKs..
Q: Will Crasheye slow down the application running speed?
A: Barely no influence. Only when application starts, Crasheye checks whether there is crash information to upload or not. Crash information will be compressed and uploaded if needed, and the application will not be affected.
Q: How much is the cellular data usage of Crasheye?
A: Reports can be uploaded only through wifi by configuring a specific interface. Crash files will be saved to local device when the device is not on wifi networks, and the files will be uploaded after the cell phone restores wifi connection.
Q: Will the submission to app store be affected because of interfacing with Crasheye? (iOS)
A: No.
Q: What developer-defined functionality does Crasheye support?
A: Crasheye supports multiple function control interfaces and information collecting API: Android Api Guideline iOS Api Guideline
Q: How to change the login account in Crasheye?
A: If you are the account owner and cannot unbind your account with an app, you should use a business Email account instead of a personal Email account to create apps next time. If you are not the account owner, you can contact with the account owner to unbind it.
Q: How does the interfacing with Crasheye impact the memory usage and CPU usage of the application?
A: Interfacing with Crasheye has no obvious impact on the application. The memory usage increases only 0.86MB and CPU peak stays at 1% after the interfacing.
How we test: We used
Testplus
(a client-side performance testing tool) to test an application at least 3 times before and after interfacing with Crasheye. Each test were more than 30 seconds, and we gathered the statistics to get the average values.
The results are as follows:
| Without Crasheye | With Crasheye | Increase | |
|---|---|---|---|
| Memory | 32.81MB | 33.67MB | 0.86MB |
| CPU Peak | 1% | 1% | 0% |
Testing device: RedMi Note3
Q: We’ve interfaced our application with Crasheye. Why does the website show that Crasheye didn't interface with the application?
A: Troubleshooting: Step1: check if the internet permission is added.
<uses-permission android:name="android.permission.INTERNET"/>Step2: Search this string in Logcat (上报活跃)；
NetSender: Sending data to url: http://rp.crasheye.cn/sessionStep3: Check if the following line is in the search results.
NetSender: Transmitting result {"ret":0,"msg":"","data":{"appkeyvalid":true}}
If the 3 steps above don’t work, please re-interface as instructed in the Help file or contact the official staff. Q: Why did the crash rate of my application exceed 100%?
A: There can be two possible reasons:
1. The app crashed instantly when it started and Crasheye captured the crashes, but the session didn’t successfully start. Because the crash stack trace that was failed to upload were cached and the session were not cached, many crashes and only one session would be uploaded in one report. Under this circumstance, the number of crashes would exceed the number of sessions and thus the crash rate would be over 100%.
2. If Crasheye was initialized in Service in the application, when Service crashed Crasheye would report those crash issues to the server. It would not restart session when restarting Service and the Mainactivity didn’t crash at that time. Under this circumstance, if a number of crashes occurred in Service, the number of crashes would exceed the number of sessions. Therefore, the crash rate that exceeds 100% is normal if you initialize Crasheye in Service.
ps: Why doesn't Crasheye start sessions in Service? As far as I am concerned, Crashes in Service have no negative impact on main activity. Besides, Mainactivity can start Service at any time, and only sessions started by users should be counted in the number of sessions. Therefore, we recommend not to initialize Crasheye in Service.
