-
Notifications
You must be signed in to change notification settings - Fork 21
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
Android 13, cannot start service #14
Comments
IllegalStateException is right..
code trace...
|
also interesting is how your observations are very likely the underlying cause for issue #11.. They report that the service needs to be restarted (ex: start/stop/start).. Does this workaround also "fix" your issue? |
Thank you for the fast reply :) My phone behaves the same with the GPS mock location app Private Location (com.wesaphzt.privatelocation). Check out wesaphzt/privatelocation#43 (comment) for the logs. The service does not start either, but is caused by a With your app selected in Developer Options, the app crashes as soon as I click on Start. When I open the app again, the button available is Start, not Stop. Clicking on it crashes the app. One maybe interesting thing is that sometimes, after clicking the Start button, the app crashes but there is the popup "Mock My GPS click to open" at the top of my screen for a few seconds. When your app is not selected in the Developer Settings, it does not crash at all after starting the service, but Google Maps still shows my true location. Same behavior with Private Location. Could it be an Android bug? Your app works well on my Android 11. |
I wouldn't say that it's an Android bug.. because the app works fine on all versions of AOSP (including Android 13) on every device that I've ever tested. I'm more inclined to say that there's something unusual about the Pixel, because I've only ever received inexplicable error reports about app crashes from users who have it installed on various versions of a Pixel. I don't own one.. so I haven't been able to diagnose. I was hoping that other (more popular) apps that have similar behavior could diagnose and fix the problem.. for themselves.. but also applicable here. I haven't looked in a while.. maybe that has already happened.. idk.. I'll check. |
|
Yes, some of the log is exactly the same. Strangely, the app works well with CalyxOS on the Pixel 6 Pro. If I find an emulator for Pixel phones, I will try both apps. Let me know if you want me to test a version of your app on my Pixel 6a before releasing it publicly. |
That would be super helpful! If.. my summary of the AOSP source is correct, then a super janky workaround would be to:
|
OK. v2.2.1 (this commit) tests this workaround. All it does is add a retry counter when attempting to add a provider.. and if it fails this number of times.. then it quietly stops trying to mock that particular provider. Currently, the retry count is set to I'd really appreciate it if you could test whether (or not) it has any effect on your ability to use the app on your Pixel device. |
It works! Thank you so much :)
Speaking of providers, could this problem be from my phone lacking Google Play Services? I remember that Google made a |
seriously?.. that worked?! 😃 On the one hand, looking at the AOSP code.. it kinda makes sense that it would. On the other hand, the cause for this error happening (only on Pixels) is still inexplicable.. and this workaround is (for lack of a better word).. dumb. Well.. I'm very glad it's now working on Pixel! To answer your question about Google Play Services.. definitely not related. My code doesn't use that at all. It only uses what is available from AOSP. When mocking is enabled and working.. Google's |
If I get it right, all that changed is that the mock code is run at most 3 times instead of just once? |
you got it right.. well, thanks for providing the stack trace from logcat.. |
I have no idea how you thought of this fix by reading the log, but I'm not sure I want to know x) I don't think I have anything else to add at this point. I will link this issue to Private Location and Fake Traveler, they look similar. |
@warren-bank Non-Pixel phones rarely update to the latest AOSP releases. There are monthly and quarterly releases of AOSP, not only yearly. They don't increment the main user-facing version number but the current release as of April is essentially 13.2.1 (first monthly update of QPR2) while other vendors are on the initial 13.0.0. April release of Android 13 QPR2 is the only actively developed release of Android. Android 11, 12 and 13 receive backports of a subset of the security patches, which are listed in the Android Security Bulletins. Most vendors don't bother actively shipping the monthly/quarterly releases and just stick to the one they started with for a long time or even for the whole release cycle. You're comparing devices running an old version of Android 13 to current Android 13. |
@thestinger Hi. Since you're so much more familiar with the AOSP code base, so I'll defer to you and ask if you can figure out why the Pixel 6+ is throwing this IllegalStateException? In the 2nd comment in this issue, I added an expandable "code trace" section that refers to AOSP code at the tag: android13-platform-release. Is there a better (more recent) tag that I should be looking at.. to see what has changed? My interpretation of the code in this tag is given in my comment.. and I can't see how Maybe the code in a different tag will call Any insight would be appreciated. Your expertise is always welcome. update: Would the android13-qpr2-s1-release tag correspond to v13.2.1 that you mentioned? |
That's not a correct tag for the OS. Bear in mind that tags are made across the entire source tree for everything built from AOSP including platform-tools, the SDK API declarations, etc. The latest Android release for April is android-13.0.0_r38, which is essentially Android 13.2.1 but they don't update the user facing version for each quarterly and monthly release. Android 11, 12 and 13 receive a subset of security patches backported. There are not actively developed LTS release branches of the OS. The only maintained version of the OS is Android 13 QPR2 which was first released in March 2023 and now has an initial monthly release for April. |
update: got it.. I'll compare this code and maybe it'll give some added insight. thanks for the tag.. I hate to admit it, but I can't figure out AOSP tagging.. at all |
The android13-qpr2-release branch corresponds to QPR2 (Quarterly Platform Release 2), i.e. what is essentially 13.2.x. The latest generic tag is android-13.0.0_r38 for TQ2A.230405.003. There are often device/carrier specific releases for Pixels shipping certain changes early and you're looking at an old branch for one of those. |
@warren-bank android13-release was the initial Android 13 stable branch. It hasn't been maintained since Android 13 QPR1 was released in December, which is android13-qpr1-release. That hasn't been maintained since Android 13 QPR2 was released in March which is android13-qpr2-release. Those are branches, not tags, and they receive monthly releases until the next quarterly or yearly release which replaces them. There are no LTS branches, only a single actively maintained branch. Bear in mind that there are device/carrier specific branches/tags shipping some changes early. Also bear in mind that there are many other things built from the overall AOSP sources such as the SDK, emulator, platform tools, kernels and so on. It's not correct to build the OS from a branch/tag existing to provide some component like platform-tools or vice versa. |
anecdotally, the user who opened this issue says that this minor update works on his Pixel 6a.. |
The reason you think there's Pixel specific behavior is just because other devices aren't shipping current Android 13 but rather a release from months ago with a subset of backported security patches applied combined with their own substantial changes and perhaps certain backports. |
Would that also hold true for LineageOS nightly releases? |
It depends on the device and how far behind they are at a given moment. After all, it takes them half a year to migrate to new yearly releases. They do follow along with the monthly and quarterly releases when they're on the latest yearly release, with potentially days or in some cases weeks of delay. |
You should be able to replicate the issue on up-to-date LineageOS 20 as long as the release for the device you test is up-to-date enough. |
well.. I feel that I've taken up enough of your time. I really appreciate being able to pick your brain. I'll dig into the more current code.. and see what I see. On the up-side.. Thanks again 😃 |
just a quick update (for anybody interested in tracing the cause for the error).. code trace...
|
just a quick update.. related issues: related pull requests: |
No, that's not correct.
This change fixed an Android app compatibility issue where not having a network location provider (which is meant to be supported) reduces app compatibility unnecessarily: https://github.com/GrapheneOS/platform_frameworks_base/pull/380 This extends app compatibility further. Some apps using the network location provider weren't happy with the initial change alone and while it extended app compatibility, it also broke a smaller subset of apps which were already working: https://github.com/GrapheneOS/platform_frameworks_base/pull/387 If your app doesn't work without these changes, it doesn't work on AOSP without Play services or another network location provider included in the OS. AOSP doesn't have network location included, which is not a bug and apps are not meant to break. |
I apologize Daniel. |
Our changes may have fixed this issue but if that's the case, it was caused by an AOSP issue where it's unnecessarily harsh to apps which try to use network location when there isn't network location available. |
No need to apologize. |
GrapheneOS user, on Pixel 6a, not rooted
The text was updated successfully, but these errors were encountered: