I am facing an issue, where my app users cannot get past a point.
When the user tries to login, it gets logged in, but after that I hit an API with "OneoffTask" using this code :
OneoffTask task = new OneoffTask.Builder()
.setService(SyncService.class)
.setTag(TaskConstants.UPLOAD_STREAK)
.setExecutionWindow(0L, 200)
.setRequiredNetwork(Task.NETWORK_STATE_CONNECTED)
.setPersisted(true)
.setUpdateCurrent(true)
.build();
GcmNetworkManager mGcmNetworkManager = GcmNetworkManager.getInstance(MainApplication.getContext());
mGcmNetworkManager.schedule(task);
This code is executed, but the scheduled task does not execute. samsung s8 model : SM-G950F. It is working on all other devices. Why is this issue, I am also not getting an error. It is just stuck there.
I'm not able to comment, so I have made some assumptions regarding the issue you are facing and hopefully have this right. Please let me know if that is not the case.
The Samsung S8 is probably upgraded to Android 8.0 (Oreo), right?
In Oreo there are limitations that you need to handle in a different manner.
Android 8.0 places limitations on what apps can do while users aren't directly interacting with them. Apps are restricted in two ways "Background Service Limitations" and "Broadcast Limitations", reference: https://developer.android.com/about/versions/oreo/background#overview
Also the GcmNetworkManager require that the user have "play services" installed, you have to ensure to check that. GCM is also soon deprecated so look for other solutions, replaced by FCM for instance: https://developers.google.com/cloud-messaging/android/client (see also requirements to ensure the S8 meets them).
To ensure that GcmNetworkManager scheduler works as espected you need to combine it with a JobScheduler. Best reference I found is this: https://github.com/yigit/android-priority-jobqueue/wiki/Integration-with-JobScheduler-and-GcmNetworkManager
My experience with JobScheduler is that it is working great on all newer devices I have tested (Android 6.0 --> 8.0) so hopefully you don't need so much "Oreo-logic".
Please let me know if that got you in the right direction :)
Related
Before I begin, I understand that GCM is depreciated, but due to time and resource constraints on this ticket, I don't think migrating to FCM is feasible at this juncture. I didn't write the app (the contractor who did it is long-gone by now), I just need to fix it if possible. If it's not possible without doing a migration, I'd like to just relay that information onwards instead of continuing to bash my head against this any longer.
My question, in short, is this: Was there anything introduced in Android 9.0 (API 28) that would preclude the GCM registration process from working? The app works fine on all preceding versions of Android, but not Pie.
More info: When the app starts on a fresh 9.0 device, a call to GCMRegistrar.getRegistrationId() is made. It returns a blank string, as expected. Intent filters are created, receiver is registered, etc. Finally, a call to GCMRegistrar.register() is made. On every other version of Android, I get a response with a registration token that gets fielded in the onRegistered method in the GCMIntentService class. For some reason, this callback method is never called on devices running Pie.
What I've tried: Already updated play-services-gcm to v16.0.0. Min sdk is 14. Target is 28. Ran some debug broadcasts that target my receiver, it still functions. Still can't find a good reason why onRegistered suddenly isn't being called on this version of Android.
I'm more or less unconcerned about the code and/or manifest because, again, it has been chugging along fine on hundreds of devices for many years now. Did Google just cut life support for GCM registration at the OS level with Pie or something? If not, are there Pie-specific changes that need to be made to get it to work? Looking at Google's documentation, their solution seems to be "migrate to FCM", but as I mentioned before, that's not an option at the moment.
As I mentioned in my comment, the rollout isn't supposed to come to full fruition until April of 2019. With that said, it's hard to say without code, but depending on your implementation and that you mentioned the GCMIntentService it could have something to do with the changes to how background Services are allowed to run in Android Pie. See this post for more details.
Check your logcat to see if you get any errors when trying to start the Service during the registration process.
When I clear my app from recent apps list, my app background service killed. I tried with android nougat and oreo. But it's working in Android 6.0. After searched about the issue. Lot of people navigated the answer to Background Execution Limits.
Any one have solution for this issue?
Android Nougat should not have those issues ideally. I've spend weeks on NotificationListenerService which runs perfectly fine in background in Nougat.
It also works great in Samsung S9 (Android Oreo) but I have some issues in Google devices and emulators.
I've raised a similar issue few weeks back.
Just to make sure, enable background services for your app through console.
Also, specify which service you are using?
try this
#TargetApi(Build.VERSION_CODES.O)
private void moveToStartedState() {
Intent intent = new MyIntentBuilder(this)
.setCommand(Command.START).build();
if (isPreAndroidO()) {
Log.d(TAG, "Running on Android N or lower");
startService(intent);
} else {
Log.d(TAG, "Running on Android O");
startForegroundService(intent);
}
}
Example
https://proandroiddev.com/deep-dive-into-android-services-4830b8c9a09
Simple answer:
Use foreground services instead of background services.
Why?
Because of changes in how latest Android SDKs treat background services and Doze mode.
Good luck :)
My application performs data synchronization in background service which is critical task for application in order to work properly. now, application works fine & expected in some of devices having pure Android or near to pure Android ROM. e.g. Google Nexus, Android One & Motorola devices. but, some devices like Redmi having MIUI has inbuilt options for blocking application's background processes. which causes my application working not properly. So, I want to know "is there any way to find out my background processes are blocked? so that I can notify user to unblock it."
here's a somewhat related question
here's some screenshot related to this.
Any suggestions or help are welcome.
Thanks in advance
as i know, apps cannot get the info about whether or not in whitelist, but you can notify the user any more by :
Intent intent = new Intent(); intent.setAction("miui.intent.action.OP_AUTO_START"); intent.addCategory(Intent.CATEGORY_DEFAULT);
I would like to know which users have uninstalled my application so that I can ask them for a feedback to improve the app. Hence, I would like to detect when the user has initiated the uninstallation process on my app.
One of the older solutions on StackOverflow had the following steps:
List< ActivityManager.RunningTaskInfo > taskInfo = am.getRunningTasks(MAX_PRIORITY);
String activityName = taskInfo.get(0).topActivity.getClassName();
if (activityName.equals("com.android.packageinstaller.UninstallerActivity")) {
// do whatever is needed
Since Lollipop, getRunningTasks has been deprecated. So how can com.android.packageinstaller.UninstallerActivity activity be detected without getRunningTask?
Alternatively is there any other method to detect uninstallation process has been started on my app? Using getAppTask probably?
Apparently you wont be able to do this, you will have to rely on something called silent notification.
What we did was we sent notification every 3 days or whatever frequency you want.
On the client side as soon as a notification is received we hit a network call which mark NotificationReceived for the client. Now since notification are not full proof we assumed a threshold of 2/3 missed notification as uninstall event. And for the client we have this counter above decided threshold we contacted them for feedback.
Also no one will be willing to fill your form at the time of uninstallation as user has already decided to uninstall your application.
Read these 2 questions and answers:
native solution
GCM solution
As I know you have to mix the two. Read the limitations of first solution. You have to confirm uninstallation event of the first solution with the second solution for a complete implementation.
Hopefully, this solution will work for you. It helps you understand the reasons for your app uninstalls, reduce the uninstall rate using a powerful predictive engine and also get app Re-installs through a unique actionable channel (Android version 4.0 and above).
Just set a variable named appLastPresent for every user in the server-side and update that variable every day by calling an API using WorkManager's PeriodicWorkRequest. Also set installedDate variable when the user installs the app.
Now set up a chron job on the server side to check if the difference between installedDate and appLastPresent is greater than 7 days. Then send the user an email or message enquiring for issues or feedback, if it is greater.
NB: User can be offline for 7 days. Therefore only send email enquiring like why you are not using the app, if uninstalled please let us know why
Some friends and I have been working in an app that requires to have a service running listening for voice commands. We have successfully implemented the listener. However, after we started having problems because the operating system killed the service after a while (I suppose to reclaim some resources). We (apparently) fixed this problem by making the service a foreground process (calling startForeground).
We have been testing the app in a range of devices and we found out that the app was still being killed by the OS in some devices. Having a close look at this issue we found out that the devices where the app is being killed have Google Search version greater or equal to 2.3... (for instance 2.4.10.626027) If we uninstall the updates and downgrade to version 2.2.10.573038 then it works like a charm.
By the way, I have mentioned Google Search here because when we start the voice listener, a package named com.google.android.googlequicksearchbox is started.
Does anyone have an idea of why this might be? or what main differences exist between the versions 2.2.10.573038 (and older) and those after? Of course the solution would be to downgrade the version but we would like it to be compatible with the newer versions too...