MuntashirAkon
Crash upon opening any app's details: `java.lang.RuntimeException: Service couldn't be found`
Please check before submitting an issue
- [x] I know what my device, OS and App Manager versions are
- [x] I know how to take logs
- [x] I know how to reproduce the issue which may not be specific to my device
Describe the bug
On some devices, AM crashes before the details view is fully loaded.
To Reproduce
- Open AM v4.0.2 (442) in ADB mode
- Open the AM's details view of any app, e. g. by tapping it in AM's main app list, or from the debloater by tapping the circular 'i' in the app's commentary sheet.
Expected behavior
The tapped app's details should be shown, and interactable.
Screenshots
Logs
AppManager_v4-0-2_crash-upon-opening-app-details-from-main-list_20250425.txt
Device info
- Device: Boox Ultra
- OS Version: Android 11
- App Manager Version: 4.0.2 (442) F-Droid
- Mode: ADB
Additional context
- I hadn't visited any app details in AM in a while, then the crash happened on the first attempt.
- The particular app that triggered this AM crash for the first time was the one shown in the screnshot. All subsequent attempts to view the details of the same app, or any other app, also made AM crash.
- I never encountered this "AM crash upon opening app details" before v4.0.2 (although I might have skipped versions, occasionally), and the system is not in any apparently unusual state.
It's a highly unusual issue. Does your system support telephony (SIM cards)?
I think it does support SIM cards, although there is none inserted (and has never been). Has anything changed in 4.0.2 (or maybe in 4.0.0 or 4.0.1 already) that suddenly turns the absence of a SIM card into a problem?
Has anything changed in 4.0.2 (or maybe in 4.0.0 or 4.0.1 already) that suddenly turns the absence of a SIM card into a problem?
Previously, we didn't enforce this checking. Now we do.
Has anything changed in 4.0.2 (or maybe in 4.0.0 or 4.0.1 already) that suddenly turns the absence of a SIM card into a problem?
Previously, we didn't enforce this checking. Now we do.
And what would be the solution, for example, for those of us using a tablet without a SIM card? I have an old tablet running Android 11, rooted of course. I remember that some time ago your app worked fine for me, but after some update it started crashing—what can I do to keep the app from breaking? I've created this thread >> https://github.com/MuntashirAkon/AppManager/issues/1729
One thing I should mention about my tablet is that it runs a PHH GSI ROM, and some features are broken because it’s a Huawei—you know how the kernel and many components are closed-source, so it behaves oddly
Three months and three minor versions in, AppManager is still mostly (*) unusable on this device.
Previously, we didn't enforce this checking. Now we do.
Please allow me to ask the obvious question: What's the point of enforcing a check for the presence of telephony (or an actual SIM card) that
- if it succeeds, just lets the app continue as it did without the check
- if it fails, introduces a reproducible crash that didn't happen without the check?
(*) Some components, e. g. the installer, still appear to work.
What's the point of enforcing a check for the presence of telephony (or an actual SIM card) that
- if it succeeds, just lets the app continue as it did without the check
- if it fails, introduces a reproducible crash that didn't happen without the check?
Because I follow what the AOSP does. If you have a device with telephony features enabled, I expect it to have the associated APIs (e.g., isub service in this case) for it. If you do not have those enabled, that's in inappropriate behavior, and the only logical way to address it would be figuring out what is wrong in first place.
For example, @Milor123 is saying that it's a known issue with PHH GSI ROMs (I think somebody else has also said the same thing before). Naturally, I'd want to know why it was necessary to have those features enabled while removing all the associated APIs, before I can decide how to deal with the situation. I do not have any animosity towards Huawei or anything: I follow certain procedure to keep things sane and the project maintainable.
@GfEW, @Milor123: Can you check if this commit fixes your issue: e2a376d68f702365d411a73bfa7c54979fa3d187? You can find the latest debug builds here: https://github.com/MuntashirAkon/AMInsecureDebugBuilds (make sure to download the latest one).
@GfEW, @Milor123: Can you check if this commit fixes your issue: e2a376d? You can find the latest debug builds here: https://github.com/MuntashirAkon/AMInsecureDebugBuilds (make sure to download the latest one).
Excellent, brother, it finally works!!! 😄 I tried this version on my tablet
I finally managed to get into the menu to modify the apps without it crashing Thank you very much man ❤️
@GfEW, @Milor123: Can you check if this commit fixes your issue: e2a376d? You can find the latest debug builds here: https://github.com/MuntashirAkon/AMInsecureDebugBuilds (make sure to download the latest one).
Thank you for your time and efforts.
-
~I haven't been able to infer in 15 minutes which of the debug builds corresponds to e2a376d, and it was close to giving up, especially considering the risks laid out in the readme. I, for one, have overcome the hurdle, but should you experience little return on invitations to test, it might help to give non-tech users who are willing to engage in testing some generic guidance as to which debug build to choose.~ Ugh, I must have
your hint "download the latest one". Sorry, my bad.overlooked
I vaguely remember seeing, but mistaking it for the ubiquitous "please test in latest version" phrase many devs keep on repeating (as if repetitions improved clarity) while failing to specify which exact "latest version" is meant or how/where to obtain it (e. g. F-Droid, github, "master", "debug builds" etc. @_@). -
I ended up testing AppManager_v4.0.5-DEBUG#3042.apk on the device where this issue was encountered. According to the guide, ADB can only be used by either the release or the debug build, so I proceeded as follows to best replicate the original situation: 2.1. Set the existing AppManager's operation mode to "No root". 2.2. Launched AM.DEBUG, and there, enabled "ADB over TCP". 2.3. In the main apps listing without any filter, I tapped at various apps. 2.4. Result: The details of every tapped app were shown and interactable without any crash.
-
On a side note, the way back was all but smooth: 3.1. Uninstalled AM.DEBUG, expecting the ADB slot to be freed automatically. 3.2. Switched AppManager's operation mode to "Auto" again, expecting it would settle at "ADB over TCP" like before. 3.3. AppManager got stuck at the spinning waiting circle, for minutes and hours. 3.4. Disconnecting and reconnecting ADB didn't help. 3.5. Reinstalling AM.DEBUG, setting it to "No root", then uninstalling it again didn't help. 3.6. Killing AppManager didn't help - it was responsive when relaunched and indicated "No root" mode, but got stuck waiting again as soon as set to "Auto". 3.7. Killing it again and setting it to "ADB over TCP" right away didn't help, either. 3.8. At the end, I even resorted to revoking all existing debugging authorizations - something that, due to the lack of granularity, I'd rather avoided -, to no avail. 3.9. Only over night, things have finally resettled somehow, and AppManager is able to use "ADB over TCP" again. --> Should AM.DEBUG be set back to "No root" before uninstall? If that's the recommended procedure, the AM.DEBUG guide would, in addition to the disclaimers and warnings, certainly profit from providing that hint.
FYI, the solution to most problems is a simple reboot that most people also tend to ignore.
FYI, the solution to most problems is a simple reboot that most people also tend to ignore.
FYI, I'm well aware of that, but since I've yet to find a way to preserve running termux sessions across reboots, that's about the last thing I'd want to try.
@MuntashirAkon Do you have any insight regarding the question Should AM.DEBUG be set back to "No root" before uninstall? Knowing how to prevent those complications would really help with further testing.
Should AM.DEBUG be set back to "No root" before uninstall?
Yes. The reason multiple instances of App Manager does not work with ADB is the use of port 60001 for the remote server. So, you need to ensure the server is not running before uninstalling AM Debug. The port is fixed due to historical reasons. It may be changed in the future.
. So, you need to ensure the server is not running before uninstalling AM Debug.
Great to know, thank you. Getting to know it beforehand would be even better, please see https://github.com/MuntashirAkon/AMInsecureDebugBuilds/pull/1.