Develop Reference

No way to make Work persistent across reboots?

So I know WorkManager utilizes JobScheduler on supported APIs but there doesnt seem to be any way to make WorkManager work persistent across reboots? Is the only option to request the BOOT_COMPLETED permission and reschedule jobs?

To answer your question: You don't need to do anything if the device is rebooted. WorkManager keeps scheduling your Work without any additional requirement from your side.
WorkManager persists Work requests in its internal Room database. This allows it to guarantee Work execution across device restart.
The documentation covers this as this blog "Introducing WorkManager" that the team wrote last year.

WorkManager is actually used to persist deferrable tasks even after your app exits and the device restarts, please refer to the docs. It uses JobScheduler for api 23 and above and broadcastReceiver and AlarmManger on api 14 to 22. You can use constraints to check battery status, network coverage ...etc depending your particular usecase. You just have to be careful not to remove or rename your existing classes after they are added in the queue because WorkManager uses it's internal database to store those classes and your app will crash if you remove them or rename them.

get current app running android (app blocker)

I am trying to develop an app in android that can block other apps on a specific time. I have found several questions on stackoverflow talking about this, but the solutions they provide are deprecated and nowadays not working. I am actually a little bit lost, so any ideas would be appreciated. The steps are (for the moment):
List all installed apps.
Detect the name of the app that is currently running (in a service).
Thanks!

Here are the answers to your question.
List all installed apps.
PackageManager pm = getContext().getPackageManager();
List<ApplicationInfo> apps = pm.getInstalledApplications(0);
Detect the name of the app that is currently running (in a service).
There is currently no way to detect or get info on the currently running apps or services. This was depricated long ago because of security reasons.
getRunningTasks
public List<ActivityManager.RunningTaskInfo> getRunningTasks (int maxNum)
This method was deprecated in API level 21.
As of Build.VERSION_CODES.LOLLIPOP, this method is no longer available to third party applications: the introduction of document-centric recents means it can leak person information to the caller. For backwards compatibility, it will still return a small subset of its data: at least the caller's own tasks, and possibly some other tasks such as home that are known to not be sensitive.
Note: this method is only intended for debugging and presenting task management user interfaces. This should never be used for core logic in an application, such as deciding between different behaviors based on the information found here. Such uses are not supported, and will likely break in the future. For example, if multiple applications can be actively running at the same time, assumptions made about the meaning of the data here for purposes of control flow will be incorrect.
Check it here for more info
Hope this helps.

Android O Replacement for getRunningServices

In previous versions of Android, I used this method to find if a service from another app was up and running. It worked reliably for me:
ActivityManager manager = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);
List<RunningServiceInfo> services = manager.getRunningServices(Integer.MAX_VALUE);
However, with Android O, this is now deprecated and will only return information about the calling app's services. I've looked into other solutions, but I don't want to ask the user for more permissions, (UsageStatsManager, NotificationManager, etc).
Is there an alternate solution for obtaining if a service from a different app is running or not in Android O?

It is intentional that there is no replacement for this function. It is not too clear from the documentation, but from the docs:
Note: this method is only intended for debugging or implementing service management type user interfaces.
Basically, using the method to check other apps services was an unintended side-effect, so Google decided to remove it. Likely for privacy/security purposes to avoid apps "sniffing" other apps/services on the user's device.
You didn't mention your use-case, but you want to avoid asking users for permissions. However, Google is intentionally forcing developers to explicitly request permissions they need, a philosophy which you can find explained here.

As per documentation:
As of O, this method is no longer available to third party applications.
For backwards compatibility, it will still return the caller's own services.
But may be this solution will help: How to check if a service is running on Android?

Some questions about GcmTaskService

Background
I wanted to use the new JobScheduler API that was presented on Lollipop, but sadly it doesn't have an official port for pre-Lollipop.
However, there is the GcmTaskService, which provides very similar functionalities.
The problem
This API is quite new, so there are very few places to look for information of how to use it (here and here, for example).
The questions
I have a few questions about this new API :
It seems that it requires Google Play Services (here) to be used (except for when using Lollipop version of Android, which will use the normal JobScheduler). What should I do in case the Google play services aren't available?
It seems that even though I've used "setPersisted(true)" for a repeated task, when I restart the device the task won't be called again. How come?
EDIT: that's because I missed a permission of RECEIVE_BOOT_COMPLETED .
What is the default behavior of a task, in case I don't use "setRequiredNetwork" ? Is it "NETWORK_STATE_ANY" ?
The docs say about what's returned from onRunTask , I can return any of the values "RESULT_FAILURE", "RESULT_RESCHEDULE", "RESULT_SUCCESS" (info here). It seems both the FAILURE and SUCCESS options will do the same thing - remove the task from the queue. Is it true? If so, what exactly is the difference between them ? Do they function differently?
Are "TaskParams" used only for the tag of the task? Can I somehow pass a bundle to the task using the API? Otherwise, I would need to set a DB for storing what should be passed to the tasks, right?
Is it possible for the app to get the queue of the tasks? I know it's possible using adb, but is it possible using the API too?
They say (here) that each task has a wakelock of up to 3 minutes. What should be done if the task needs more than that? Should it acquire another wakelock for itself? Will the API warn that the wakelock was released? Here's what the docs say:
The scheduler will hold a PowerManager.WakeLock for your service,
however after three minutes of execution if your task has not returned
it will be considered to have timed out, and the wakelock will be
released. Rescheduling your task at this point will have no effect. If
you suspect your task will run longer than this you should start your
own service explicitly or use some other mechanism; this API is
intended for relatively quick network operations.
They say (here) that all networks-tasks are removed each time the app gets upgraded/replaced, and there is a call for "onInitializeTasks" when this happens, and that you can re-schedule them again. How can I re-schedule the tasks? I don't think I can even get the list of tasks...
Is it possible to tell the task to prefer specific times during the day ? For example, between the 14:00-15:00 ?
I've noticed that if you schedule a task, and then you force-stop and/or clear data of the app, the task will still run. How can I avoid this behavior?

jacktech24 did a really good job, but i will try as well in case there are any lingering questions.
It seems that it requires Google Play Services (here) to be used (except for when using Lollipop version of Android, which will use the normal JobScheduler). What should I do in case the Google play services aren't available?*
You can't use this API if Google Play Services isn't available. Rather, the Google Play Services client library is designed to request that the user download and install Google Play Services if it detects that it's missing, but I don't believe that the GcmNetworkManager does this.
What is the default behavior of a task, in case I don't use "setRequiredNetwork" ? Is it "NETWORK_STATE_ANY" ?*
The javadoc describes which is the default.
The docs say about what's returned from onRunTask , I can return any of the values "RESULT_FAILURE", "RESULT_RESCHEDULE", "RESULT_SUCCESS" (info here). It seems both the FAILURE and SUCCESS options will do the same thing - remove the task from the queue. Is it true? If so, what exactly is the difference between them ? Do they function differently?*
The only difference between these 2 is that in the adb shell dumpsys it will display what you returned, so you can use this to troubleshoot issues.
The other reason is that if the task fails, it is strange to require the client return a "success."
Are "TaskParams" used only for the tag of the task? Can I somehow pass a bundle to the task using the API? Otherwise, I would need to set a DB for storing what should be passed to the tasks, right?*
In the next version of GmsCore the ability to add a bundle to the task should be supported.
Is it possible for the app to get the queue of the tasks? I know it's possible using adb, but is it possible using the API too?
No it's not possible. Instead you should perform the cancel when you want it and if the task is not there it will be a no-op. Similarly you should schedule the task at the point in your code where you would have queried for the list of tasks. use setUpdateCurrent=false to ensure that it doesn't update the pre-existing task. The AlarmManager works in a similar way in that you would set the alarm regardless of whether the alarm was already set - the api was designed to follow this.
They say (here) that each task has a wakelock of up to 3 minutes. What should be done if the task needs more than that? Should it acquire another wakelock for itself? Will the API warn that the wakelock was released? Here's what the docs say:*
Yes, the app should acquire its own wakelock and everything will be fine. The reason the scheduler releases the wakelock after 3 mins is because in practice having an unlimited wakelock timeout only leads to really hard to track down battery drain bugs. If you need longer than 3 mins you have a sophisticated enough use-case that you can dig into how the PowerManager APIs work and call the acquire()/release() yourself (it's really quite simple, the fact that the network manager does it for you is more of a politeness than anything else).
They say (here) that all networks-tasks are removed each time the app gets upgraded/replaced, and there is a call for "onInitializeTasks" when this happens, and that you can re-schedule them again. How can I re-schedule the tasks? I don't think I can even get the list of tasks...*
You reschedule the tasks the same way you scheduled them in the first place. Whatever function you used to schedule them, call that function from GcmTaskService#onInitializeTasks. This was done to avoid lingering tasks across app logic changes. Consider the situation where a developer changes their task timetable, and starts using a different tag. They would be required to call cancel(old_tag) after they'd detected the upgrade (which they'd have to add more code to do), which would mean they'd need a reference to the old (unused) tag even in their new code. This would imply that a tag is a stable identifier that shouldn't change across app upgrades - which shouldn't be a requirement for this api.
Is it possible to tell the task to prefer specific times during the day ? For example, between the 14:00-15:00 ?*
No, this type of background scheduling causes all sorts of problems with herding across large populations of devices. I.e. if 1 device runs a job at 15:00 that is probably fine. But if 1x10e6 do suddenly your server is in serious problems.
I've noticed that if you schedule a task, and then you force-stop and/or clear data of the app, the task will still run. How can I avoid this behavior?*
Unfortunately you can't, but this is not intentional and should be changed - there should be no way for an app to run after the user has explicitly stopped it.

you can find answers to most of your questions it here.
https://github.com/jacktech24/gcmnetworkmanager-android-example/blob/master/README.md
To answers that are not answered there
7: You won't get notified when wakelock is removed, and as they say in documentation, this API is only for short tasks, if you have longer, write your own implementation
9: No you can't as of now, the API doesn't allow it
10: That's because Google Play services are taking care of it, and there is no way around it. You have to detect in the service whether the app is setup (I expect that's your problem) eg. configuration is created etc. and eventually cancel all tasks when one of them is called.

Xamarin.Mobile: task-based API marked as obsolete

The latest release of Xamarin.Mobile component obsoletes some Task-based APIs for Android. Release notes briefly comment on this:
Given the fragility of the Task<> based API on Android due to Activity lifecycle realities, the async API is now marked [Obsolete] specifically for Android.
Could someone please explain what fragility is meant here?

Essentially, using Task across app lifecycle boundaries is asking for trouble. When the camera Activity starts on Android, you are actually starting a completely new app. Your app is no longer running in the foreground, so Android is completely within its rights to kill off your app and just restart it when the camera returns. If this happens, your Task instance has been destroyed and so any awaits or ContinueWiths you have will never execute. It's not a Task/Android issue, it was simply a design flaw in Xamarin.Mobile.
As a result, the magic API was deprecated in favor of one that utilizes OnActivityResult, as it is the only way to properly handle this situation. If you notice, the new API GetMediaFileExtraAsync still returns a Task<MediaFile>.
(Source: I wrote Xamarin.Mobile).