Closed 1000283 closed 3 years ago
Debug files are put to Android bundle (.aab), you can generate it with signBundle.sh
When you upload the bundle to Play Store, it keeps debug files and prints verbose stack traces when a crash on the user side occurs.
On Tue, 9 Mar 2021, 14:02 1000283, @.***> wrote:
Even if i run build.sh debug the generated apk always has all .so stripped, so no debugging symbols, even if the originals are not stripped. The gradle strip task always runs. Moreover, with debug, signing fails due to zipexception so i can't install the apk.
How can i reliably buid an apk with not stripped .so libs in it?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pelya/commandergenius/issues/127, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABF5QD4TE3IH7ADSSESW6TTCYE57ANCNFSM4Y3OHSZQ .
Thanks for replying. I'm not interested in the Play Store (maybe later).
This .aab that is generated seems like a trimmed down / pre-packaging version of the .apk, and is not recognized by Android Studio.
Also, if i file base/lib/x86/*.so
, for example, all files are still stripped.
I don't tihnk i can just adb install
the .aab onto a device as-is, right? Do i need to run something like aapt
over the contents so i can get a debug apk i can install onto a device?
Maybe mv manifest/* .
mv dex/* .
, then sign and zip?
No, you cannot install .aab directly, .apk is generated from it by Play Store, individually for each device.
.apk is always stripped as much as possible. You will need to save your non-steipped .so files separately, ndk-gdb can load them fine from the obj directory, and you can pass them to addr2line or ndk-stack to decode stack trace address from adb logs.
On Tue, 9 Mar 2021, 19:37 1000283, @.***> wrote:
Thanks for replying. I'm not interested in the Play Store (maybe later).
This .aab that is generated seems like a trimmed down / pre-packaging version of the .apk, and is not recognized by Android Studio. Also, if i file base/lib/x86/*.so, for example, all files are still stripped.
I don't tihnk i can just adb install the .aab onto a device as-is, right? Do i need to run something like aapt over the contents so i can get a debug apk i can install onto a device?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pelya/commandergenius/issues/127#issuecomment-794211371, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABF5QGS4OAHUZS67CBAJL3TCZMGJANCNFSM4Y3OHSZQ .
The stack trace pertains to the stripped/release version of the lib.
I got useful information with $NDK/prebuilt/linux-x86_64/bin/gdb $PWD/project/obj/local/arm64-v8a/libapplication.so -ex "list *0x004c5bb7" -ex "list *0x004966c7"
, because the version in obj/local
is the only one that's non-stripped/debug.
I'm not versed on the ELF file format; is the information provided by gdb on the non-stripped version of the lib accurate? I.e. does it match the stripped version the stack trace provides?
Yes, it's the same library, so it provides the same information in gdb, but stripped version won't print line numbers
On Wed, 10 Mar 2021, 12:27 1000283, @.***> wrote:
The stack trace pertains to the stripped/release version of the lib.
I got useful information with $NDK/prebuilt/linux-x86_64/bin/gdb $PWD/project/obj/local/arm64-v8a/libapplication.so -ex "list 0x004c5bb7" -ex "list 0x004966c7" , because the version in obj/local is the only one that's non-stripped/debug.
I'm not versed on the ELF file format; is the information provided by gdb on the non-stripped version of the lib accurate? I.e. does it match the stripped version the stack trace provides?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pelya/commandergenius/issues/127#issuecomment-795211150, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABF5QBD3UDFFZLESWPXV63TC5CP3ANCNFSM4Y3OHSZQ .
A slight heads-up.
I find it odd that the path is .../arm/... as this is running on an arm64 device (with litters the logs with logs of error messages of other components - such as NFC not connecting).
The Cortex-A53 is an armv8-a CPU, which means it also runs 32bits.
After adb pull
ing the libs from /data/app/com.my.app/lib/arm
(there were no other directories at this level), file
told me these are all ELF 32-bit LSB shared object, ARM, EABI5 version 1, so in fact armeabi-v7a.
The output that gdb and ndk-stack were giving me was rather confusing as it didn't seem to match the stack trace from logcat. It wasn't until i switched the lib to the arm32 version that it began making sense.
For completeness:
$NDK/prebuilt/linux-x86_64/bin/gdb $PWD/project/obj/local/armeabi-v7a/libapplication.so \
-ex "list *0x00079924" \
-ex "list *0x000798ed" \
..
$NDK/ndk-stack -sym $PWD/project/obj/local/armeabi-v7a -i /my/logcat.txt > /my/logcat.dump
...and not arm64-v8a (in my case).
Even if i run
build.sh debug
the generated apk always has all .so stripped, so no debugging symbols, even if the originals are not stripped. The gradle strip task always runs. Moreover, with debug, signing fails due to zipexception so i can't install the apk. (Sometimes i can get around this by unzipping the apk,rm META-INF/CERT.* META-INF/MANIFEST.MF
, rezipping and resigning but it doesn't always work.)e.g., with debug:
...without debug:
If i edit
./project/app/build-template.gradle
and add tobuildTypes
:Then i get this:
But still stripped even
project/app/build/outputs/apk/debug/app-debug.apk
How can i reliably buid an apk with not stripped .so libs in it?Regardless of configuration, tweaks, edits and what not, whenever i get a crash, this is it:
From the log the app seems to run fine until this. The previous lines are usually these:
Something related with video, yet on my app. When i get something useful out of Android Studio it tells me, on a debug run:
SIGBUS (signal SIGBUS: illegal alignment)
I find it odd that the path is
.../arm/...
as this is running on an arm64 device (with litters the logs with logs of error messages of other components - such as NFC not connecting).