Implicit Broadcast Receivers Going Away After Android N

[epicstar]

Apparently, Implicit Broadcast Receivers are going away in Android O. 3 of them are already gone in N, which includes the CONNECTIVITY_CHANGE broadcast.

I looked into your code and you don't seem to be using that (rather, you create an instance of a generic broadcast receiver and always call the ConnectivityManager for every broadcast received from it), but it's possible your current method of calling for connectivity changes could still be gone in Android N? Google recommends using the JobScheduler API instead (however, you can only use this starting in API 21...).

I'm thinking that releases should consider using the JobScheduler API instead for listening to connectivity changes (with a shim for using the current broadcast receiver below API 21). What do you think?

Source: https://www.youtube.com/watch?v=VC2Hlb22mZM

XDA has a good TL;DR about this: http://www.xda-developers.com/how-android-n-will-improve-battery-and-memory-management/

[pwittchen]

Thanks for creating that issue. I didn't know about that. I'll take a closer look at that update in Android N and write a more detailed answer later when I find some time in the nearest days.

[pwittchen]

I quickly browsed docs and I can give you a short answer. As far as I see in the documentation, Google Developers extended ConnectivityManager and added some new listeners, what you can read here: https://developer.android.com/reference/android/net/ConnectivityManager.html. I think, we can create a strategy with Broadcast for "pre-N" devices (existing solution) and a new strategy for "N and higher" devices. We'll need to code new implementation of the new strategy, but I think library API could stay the same.

You asked about JobScheduler. I'm not sure if it should be used for checking connectivity. I think it should be used for processing queues of the jobs or operations to be executed. When jobs are done, a scheduler is no longer needed. I don't have that much experience with JobScheduler, so I may be wrong. Moreover, after a quick look at the documentation, I think connectivity monitoring on Android N can be implemented without JobScheduler.

[pwittchen]

I've added this issue to the Roadmap. The plan is to implement it for release 0.5.0. I think, 0.3.0 should be released in the nearest days and 0.4.0 should be released shortly after the previous version. I just need to find some time for this.

[epicstar]

Wow, thanks for the immediate reply and possible solutions!

Based on your current reply, I was thinking that since NetworkCallback class started at API 21, I was thinking that perhaps instead of using the new solution for N+... should the new strategy start with devices with API 21 (L) instead?

Also, I'm willing to devote my time to improve the library :)

[pwittchen]

Yeah, I was thinking about NetworkCallback as it's part of new ConnectivityManager. I think new strategy can be implemented for Android L (API 21) and higher because a new implementation is available there. Pull Requests and new issues are always welcome :). I just need to release latest updates, which I have in mind and then this issue can be resolved (after the release of 0.4.0).

Side note: additional code snippet with usage of NetworkCallback: http://www.programcreek.com/java-api-examples/index.php?api=android.net.Network

There's a new branch created for this task named 'issue-62' from 'develop' branch.

[pwittchen]

Done. Right now, it's in 'develop' branch. Before next release 'develop' branch is going to be merged into 'master' branch and it will be available.

[pwittchen]

Branch 'develop' was merged into 'master' branch. An update will be available in the release of v. 0.5.0.