-
-
Notifications
You must be signed in to change notification settings - Fork 13
-
-
Notifications
You must be signed in to change notification settings - Fork 13
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
App not compatible with Android 12 #89
Comments
This will prevent updating on Google Play starting November 1st, 2022 and completely block new installs on Google Play starting November 1st, 2023 as per https://support.google.com/googleplay/android-developer/answer/11926878. #34 might be the best fix. |
Hey I think I can help you with this issue, can you assign this to me ? |
Sure, good luck! I've gotten fairly stuck with this issue myself so hopefully you'll fare better :) |
Hey @TheLastProject I ran the app and tested in Android 13 but the app is not crashing.Tried for both background and foreground mode as well. Its working well :) |
The problem is that it's running in compatibility mode ( |
Cool got it !! |
Hey, I tried converting the foreground service into work manager due to the foreground service restrictions on android 12, but workmanager comes with certain conditions to be satisfied for the system to allow it to keep running, ex: battery level, charging status etc.. which won't be suitable for our case in which the work needs to run indefinitely and keep listening to incoming calls. And as you mentioned implementing the IncallService will be a good idea, but then that needs the app to be converted to a dialler app. which must fully implement the InCallService API and provide both an incoming call UI, as well as an ongoing call UI. Im not sure if that's what you wanted to do. @TheLastProject |
So there's no way to start a workmanager when the Having to build a full new UI seems like quite overkill and like it will just make the app worse for everyone. If you feel like it you're free to try and I'll take a look and mark it hacktoberfest-accepted if the code is decent, but I'm not quite sure if I'll release it (maybe just keep it ready until it's about to get kicked out of Google Play and release it on F-Droid as a non-recommended version) I guess Google has really actively killed the one API that made apps like this useful :( |
@TheLastProject We can start the work manager immediately once we receive the broadcast which is working fine while the app is in the foreground (tested in android 13 as well 😃), but the problem is once the app goes into the background according to the documentation On devices running Android 9 (API level 28) or higher, apps running in the background have the following restrictions: Sensors that use the continuous reporting mode, such as accelerometers and gyroscopes, don't receive events. So we are not receiving on-change events if the app is in the background. I tried setting up the workManager with setForeground method, but that as well didn't work :( will see if its possible to get sensor events inside a workManager while app being in the background and raise a PR if it works |
If moving to the foreground doesn't work, I guess it would be possible to keep a "Raise To Answer is watching for phone calls" notification visible 24/7 and explain users when they tap it why it exists. It sucks both UI-wise and battery usage-wise (because now Raise To Answer has to run 24/7 instead of activating when a call comes in), but well, this is what Google has forced upon apps then. |
@TheLastProject Hey have raised a PR for this bug with a fix. By asking the user to exclude the app from battery optimisations, which enabled the existing foreground service to be initiated from the background. I feel this maybe a better fix since we don't keep the service running indefinitely in the background and only start it on receiving the broadcast and stop it on pickup or decline. however there is a catch Google Play policies prohibit apps from requesting direct exemption from Power Management features in Android 6.0+ (Doze and App Standby) unless the core function of the app is adversely affected. If google reaches out we should be able to explain that without this fix the core functionality of the app will be affected, you can check the documentation here for details. and these are the acceptable usecases where we can use ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS I hope this helps :) |
After updating targetSdkVersion to 31, the app crashes on an incoming call.
The text was updated successfully, but these errors were encountered: