Open frama99 opened 10 months ago
iBotPeaches
commented
10 months ago Sounds like you've done what I was going to ask and isolated the disassembly to the resources. Skipping disassembly of resources and launching resulted in no issue.
Odd however the error isn't a common one that references a missing resource. Its almost like the sources are trying to reference a resource that is no longer available.
frama99
commented
10 months ago I read previous tickets and thought it would be a good idea to do these tests immediately :-) Besides that I had some hope that --no-src would solve the problem and still allow access to AndroidManifest.xml. But unfortunately it is just the other way around. De/re-compiling the sources seems to work fine, but the resources cause the trouble. Maybe you have a chance and time to look deeper into this problem. Many thanks. - Please let me know if I can help in any way.
iBotPeaches
commented
10 months ago I disassembled, rebuilt, disassembled and then compared. Source changes are the lost of default values, but I'm guessing the jvm/something knows default values of unset scalars.
The resources difference appear to be ordering of attributes.
So honestly not sure at the moment.
frama99
commented
10 months ago I repeated your steps (disassemble, rebuild, disassemble) and can confirm your findings. The smail-files are identical, except some default values. The missing default assignments seem to be no problem since the missing values are the defaults anyway, so nothing changes there.
I carefully compared all resources xml files as well and again can confirm that only the ordering changes between disassemble-1 and disassemble-2 versions, with one exception: In case of "res/layout/otp_verification_dialog.xml" there is an additional backslash escape sequence "\ ", thus n2:digits="\ 0123456789" vs. n2:digits=" 0123456789". But again this is not a problem since backslash something in XML should be just the character escaped by the backslash. Anyway this resource has nothing to do with the problem.
Hence I assume that the problem is introduced already by the first disassemble step and can not be detected with this method.
Just to make sure that it is not a version specific problem I tried the same procedure (disassemble, rebuild, install) with the latest Cromite version v120.0.6099.230-068d09a1ed328898da892e800eec492d8dfcbb3e, with same result (crash with similar stack trace):
01-22 09:27:37.387 10747 10747 W System.err: java.lang.NullPointerException: Attempt to invoke virtual method 'int android.content.res.ColorStateList.getDefaultColor()' on a null object reference
01-22 09:27:37.387 10747 10747 W System.err: at org.chromium.chrome.browser.toolbar.top.ToolbarPhone.n(chromium-ChromePublic.apk-stable-609923004:217)
01-22 09:27:37.387 10747 10747 W System.err: at BG1.h(chromium-ChromePublic.apk-stable-609923004:160)
01-22 09:27:37.387 10747 10747 W System.err: at DS1.a(chromium-ChromePublic.apk-stable-609923004:8)
01-22 09:27:37.387 10747 10747 W System.err: at AT.a(chromium-ChromePublic.apk-stable-609923004:13)
01-22 09:27:37.387 10747 10747 W System.err: at org.chromium.ui.resources.ResourceManager.resourceRequested(chromium-ChromePublic.apk-stable-609923004:10)
01-22 09:27:37.387 10747 10747 W System.err: at J.N.MHqlwRYg(Native Method)
01-22 09:27:37.387 10747 10747 W System.err: at zI1.f(chromium-ChromePublic.apk-stable-609923004:113)
01-22 09:27:37.387 10747 10747 W System.err: at Zz.onResult(chromium-ChromePublic.apk-stable-609923004:12)
01-22 09:27:37.387 10747 10747 W System.err: at ZG0.n(chromium-ChromePublic.apk-stable-609923004:34)
01-22 09:27:37.387 10747 10747 W System.err: at org.chromium.chrome.browser.compositor.CompositorView.onCompositorLayout(chromium-ChromePublic.apk-stable-609923004:335)
01-22 09:27:37.387 10747 10747 W System.err: at android.os.MessageQueue.nativePollOnce(Native Method)
01-22 09:27:37.387 10747 10747 W System.err: at android.os.MessageQueue.next(MessageQueue.java:335)
01-22 09:27:37.387 10747 10747 W System.err: at android.os.Looper.loopOnce(Looper.java:162)
01-22 09:27:37.387 10747 10747 W System.err: at android.os.Looper.loop(Looper.java:294)
01-22 09:27:37.387 10747 10747 W System.err: at android.app.ActivityThread.main(ActivityThread.java:8279)
01-22 09:27:37.387 10747 10747 W System.err: at java.lang.reflect.Method.invoke(Native Method)
01-22 09:27:37.387 10747 10747 W System.err: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
01-22 09:27:37.387 10747 10747 W System.err: at com.android.internal.os.ExecInit.main(ExecInit.java:49)
01-22 09:27:37.387 10747 10747 W System.err: at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)
01-22 09:27:37.387 10747 10747 W System.err: at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:359)
01-22 09:27:37.388 10747 10747 F chromium: [FATAL:jni_android.cc(290)] Please include Java exception stack in crash reportOne possible next step is probably to build Cromite and then immediately compare the involved resources, thus the primary and the first disassembled one. I did download the sources from Cromite web page, but unfortunately it's not that simple. Those contain only patches/diffs to Chromium. Chromium is really huge and the build instructions of Cromite are still a TODO ... so difficult.
Finally I downloaded Chromium sources and did compare some content of xml resource files (with focus on toolbar and color) - as far as this is possible without compiling the code. Up to now I did not find any good clue what resource might causes the null pointer exception.
frama99
commented
10 months ago Sorry. Click accident.
aminought
commented
8 months ago Got the same problem for Vivaldi Snapshot. Any progress?
iBotPeaches
commented
8 months ago I have not. If you preform the same test I did in this comment you can see if its just as confusing or provides additional context.
Information
apktool -version) - 2.9.2java --version) - openjdk version "21.0.1" 2023-10-17No modifications were made to the APK file. The re-compiled APK crashes while clicking through the initialization wizard questions, right before the app home screen is displayed. Most likely the app does not have any protection. So the app works fine without any crash when zipaliging and signing the original APK directly.
All tests were done with Wi-Fi offline.
Thank you so much for the huge effort you put into this project. Apktool is an amazing development tool.
Stacktrace/Logcat
Steps to Reproduce
apktool d# with--no-srcthe app still crashes, but with--no-src --no-resor only with--no-resthe app works wellapktool bzipalign 4apksigner ...sign with some key.After installing and starting the app, two setup wizard steps are displayed:
When performing only
zipalign 4andapksigner ...with the original APK and installing that, the app does not crash.After decompiling the APK with `-no-src' and re-compiling that, the app still crashes (same position, same stack trace).
After decompiling the APK with
--no-src --no-resor only with--no-resand re-compiling that, the app doe not crash anymore. But in this case one has no access to AndroidManifest.xml anymore, unfortunately.APK
https://github.com/uazo/cromite/releases => v120.0.6099.199-672a5061d34744482fcdd58ee4c9a5cf24acbd4b => arm64_ChromePublic.apk
Questions to ask before submission
apktool d,apktool bwithout changing anything? yes