Crash analysis on Android
For crashes on native (Android) and Unity (Android), refer to the following instructions.
Obtaining crash locations during development
When debugging native Android programs in Android Studio, you need to change Debugger - Debug type to Dual (Java + Native) in the Configuration settings.

The information required for debugging in Android Studio is shown in the figure below.

Enter bt in lldb to obtain the crash reason and call stack, as shown below:
(lldb) bt
* thread #16, name = 'samples.helloar', stop reason = signal SIGSEGV: invalid address (fault address: 0x9c40)
* frame #0: 0x0000004922f3a1d8 libEasyAR.so`___lldb_unnamed_symbol3056$$libEasyAR.so + 6088
frame #1: 0x0000004922f38568 libEasyAR.so`___lldb_unnamed_symbol3054$$libEasyAR.so + 288
frame #2: 0x0000004922f347f8 libEasyAR.so`___lldb_unnamed_symbol2876$$libEasyAR.so + 332
frame #3: 0x00000049be2390c8 libc.so`__pthread_start(void*) + 40
frame #4: 0x00000049be1f04f8 libc.so`__start_thread + 72
When the call stack contains content related to libEasyAR.so, it may indicate the crash is related to EasyAR; if not present, there is a higher probability the crash is unrelated to EasyAR.
Enter image dump sections libEasyAR.so in lldb to obtain the loading address of the .text section in the dynamic library, as shown below:
(lldb) image dump sections libEasyAR.so
...
SectID Type Load Address Perm File Off. File Size Flags Section Name
...
0x00000010 code [0x0000004922e30cfc-0x0000004923654558) r-x 0x00256cfc 0x0082385c 0x00000006 libEasyAR.so..text
...
Get the crash location after release
After release, crashes may still occur.
If a reproducible crash occurs, you can try using the Profile/Debug tool that comes with Android Studio. Then follow the same steps as during development to obtain the crash location.

If the crash is difficult to reproduce, you can use some crash reporting libraries to intercept the crash information and report it to the server. However, it is important to note that the crash information must include both the code stack trace and the module load address. Since Android introduced ASLR (address space layout randomization) starting from version 4.0, the load address of dynamic library modules may vary each time the application runs, causing the code addresses to change dynamically. Only by knowing the relative value between the code address in the stack trace and the module load address can you determine where the crash occurred.
When the code stack trace contains content related to libEasyAR.so, it may indicate that the crash is related to EasyAR; if it does not, there is a high probability that the crash is unrelated to EasyAR.
Other crash-related information
Version numbers of EasyAR Sense and EasyAR Sense Unity Plugin
e.g., 4.7.0.11800-cf8e24e30
Community edition/enterprise edition
CPU architecture
aarch64/armeabi-v7a