New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
debug always stripped, never signed #127
Comments
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
<#127>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABF5QD4TE3IH7ADSSESW6TTCYE57ANCNFSM4Y3OHSZQ>
.
|
Thanks for replying. This .aab that is generated seems like a trimmed down / pre-packaging version of the .apk, and is not recognized by Android Studio. I don't tihnk i can just Maybe |
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
<#127 (comment)>,
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 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
<#127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABF5QBD3UDFFZLESWPXV63TC5CP3ANCNFSM4Y3OHSZQ>
.
|
A slight heads-up.
The Cortex-A53 is an armv8-a CPU, which means it also runs 32bits. After 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:
...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).The text was updated successfully, but these errors were encountered: