How to keep DPC alive all the time?

[shizhx]

It is well known that many third-party ROMs kill applications frequently, if there is not any way to survive from these massacres, DPC is meaningless.

[tony-mak]

Why DPC needs to be running all the time?
DPC retrieves policies from server and applies them through DevicePolicyManager, it doesn't needed to be alive to enforce the policy. It can also register for all kinds of system broadcast in case it is interested in some particular events.
If you indeed want to make sure DPC to run all the time, you can consider to use service.startForground.

[shizhx]

@ming030890 on some ROMs, once DPC be killed, all static broadcasts become inactive state and cannot receive any broadcast, then DPC cannot pull policies from server.

Service.startForeground() not working.

[tony-mak]

Hmm, so you are saying you can't fetch policy from server in the background?
You can consider using AlarmManager, JobScheduler to schedule the job.
Also, consider using GCM to request client syncing.

[shizhx]

Unfortunately, because these methods used to keep application alive in the past, many ROMs disable them when application be killed.
GCM? GCM is unreachable for us...

[shizhx]

@ming030890 Sadly, due to the problem of survival, I don't think DPC is a stable solution for real work situation, although we has been developing on it(Device Owner part) for nearly one year, from android 5.0 to android 7.0.

I think the biggest advantage of DevicePolicyManager solution is that we don't need to cooperate with phone maker, but if the problem of survival can't solved, we have to do that. If we have to cooperate with phone maker, why don't we ask for higher permissions like system signature.

[shizhx]

Finally, we have to use some bad methods to keep DPC alive to fetch policies on time, that breaks user experience but there is no other way.

[AlexMisiulia]

@shizhx can you please tell me which methods did you use finally? Had the similar problem, stuck with foreground services, but they seem to be not reliable solution at all.

[shizhx]

@shizhx can you please tell me which methods did you use finally? Had the similar problem, stuck with foreground services, but they seem to be not reliable solution at all.

no solution yet, we finally give up and choose SDK provided by phone manufacturer :(

[AlexMisiulia]

@shizhx can I ask you a few questions about your DPC architecture?

1. What mechanism do you use for periodic background tasks?

Now I am using AlarmManager + BroadcastReceiver. And inside receiver I do http calls. Before I tried to use Service but it can't be started when app is at background (https://stackoverflow.com/questions/45016174/android-o-and-background-limits-prevents-simple-alarm-notification).
But I am not sure that AlarmManager is reliable solution. Another option is WorkManager, but it has limitation that it can't execute periodic background tasks frequently than 15 minutes interval (this is not case for my app). Also, I found the DeviceAdminService but it is available only from Android Oreo. I don't know how to solve this problem in lower levels of Api.

2. Did you find a way to restore your app after the crash?

I have a requirement that the app must recover itself after any kinds of the crash. I think that AlarmManager solves this problem partially, but maybe you found more elegant solution.