Dans Android N, il est mentionné sur le site officiel que "les applications ciblant Android N ne reçoivent pas les diffusions CONNECTIVITY_ACTION". Et il est également mentionné qu'il JobScheduler
peut être utilisé comme alternative. Mais le JobScheduler
ne fournit pas exactement le même comportement que la CONNECTIVITY_ACTION
diffusion.
Dans mon application Android, j'utilisais cette diffusion pour connaître l'état du réseau de l'appareil. Je voulais savoir si cet état était CONNECTING
ou CONNECTED
avec l'aide de la CONNECTIVITY_ACTION
diffusion et il était le mieux adapté à mon besoin.
Maintenant qu'il est obsolète, quelqu'un peut-il me suggérer une approche alternative pour obtenir l'état actuel du réseau?
targetSdkVersion
à N ou plus tard?BroadcastReceiver
avec leandroid.net.conn.CONNECTIVITY_CHANGE
filtre d'intention même lorsque vous ciblez l'API29, il vous suffit de l'enregistrerApplication.OnCreate
. Vous n'obtiendrez tout simplement aucune mise à jour lorsque l'application sera fermée.Réponses:
Ce qui sera obsolète, c'est la possibilité pour une application en arrière-plan de recevoir des changements d'état de connexion réseau.
Comme l'a dit David Wasser , vous pouvez toujours être informé des changements de connectivité si le composant d'application est instancié (non détruit) et que vous avez enregistré votre récepteur par programme avec son contexte, au lieu de le faire dans le manifeste.
Ou vous pouvez utiliser NetworkCallback à la place. En particulier, vous devrez remplacer onAvailable pour les changements d'état connecté.
Permettez-moi de rédiger rapidement un extrait:
la source
Je mettrai à jour la
Sayem's
réponse pour résoudre les problèmes de charpie qu'il me montre.Et même usage:
Btw merci sayem pour votre solution.
la source
La documentation pour Android N indique:
Cela signifie que vous pouvez toujours enregistrer un
BroadcastReceiver
si votre application s'exécute au premier plan, afin de détecter les changements dans la connectivité réseau.la source
Intent
.Veuillez d'abord vérifier la réponse @Amokrane Chentir pour la prise en charge d'Android N.
Pour ceux qui souhaitent prendre en charge tous les niveaux d'API et l'observer dans l'interface utilisateur, veuillez vérifier le code ci-dessous.
LiveData de NetworkConnection:
observer dans l'interface utilisateur (activité / fragment):
la source
IntentFilter
explicitement. Comme ça:var intentFilter = IntentFilter(CONNECTIVITY_ACTION)
intentFilter
etconnectivityManager
) vous n'avez pas besoin de définir explicitement leur type (IntentFilter
etConnectivityManager
respectivement).J'ai rencontré le même problème il y a quelques jours et j'ai décidé d'utiliser cette bibliothèque Android-Job
Cette utilisation bibliothèque
JobSchedular
,GcmNetworkManager
etBroadcastReceiver
selon la version Android de l'application est en cours d' exécution sur.Commencer un travail est assez facile
la source
J'ai écrit une implémentation de Kotlin qui est basée sur la réponse de Sayam mais sans
LiveData
. J'ai décidé d'invoquer la dernière méthode API (à ce stadeConnectivityManager#registerDefaultNetworkCallback
) qui cible Android Nougat.Usage:
ou:
N'oubliez pas d'ajouter l'
ACCESS_NETWORK_STATE
autorisation dans votre AndroidManifest.xml :J'ai hâte de lire vos commentaires et améliorations utiles.
la source
(context as AppCompatActivity).runOnUiThread(object: Runnable{ override fun run() { onConnectionAvailable.invoke() } })
au lieu deonConnectionAvailable.invoke()
. La même chose pouronConnectionLost.invoke()
.Les applications ciblant Android N (Nougat) ne reçoivent pas les
CONNECTIVITY_ACTION
diffusions définies dans le manifeste (voir Svelte ).Solutions possibles:
ConnectivityManager.registernetworkCallback()
une fois que l'application est en cours d'exécution.JobScheduler
et spécifiez un réseau illimité viasetRequiredNetworkType()
.Voir aussi Android O - Détecter le changement de connectivité en arrière-plan
la source
Je suis d'accord avec la réponse suggérée par @rds.
Gardez à l'esprit que CONNECTIVITY_ACTION est obsolète au niveau de l'API 28.
Vous devez utiliser
connectivityManager.registerNetworkCallback(networkRequest, networkCallback)
La question est que vous ne pouvez pas utiliser BroadcastReceiver alors comment?
Vous pouvez utiliser JobScheduler ou mieux si WorkManager (demande périodique). Pourquoi Periodic car s'il s'agit d'un OneTimeRequest, il ne pourra s'exécuter qu'une seule fois et continuer à écouter pendant que votre application est au premier plan.
La documentation dit:
Une fois que l'application est supprimée ou supprimée de la liste des applications récentes, networkCallback ne pourra plus l'écouter.
Donc, vous avez besoin de tels emplois périodiques pour que l'application écoute en permanence. Quelle devrait être la durée? Cela dépend de vous et dépend du cas par cas.
Je sais que c'est un peu moche mais c'est comme ça. Un défi pourrait être que si l'appareil de l'utilisateur est en mode Veille ou que l'application est en état de veille, votre travail peut être retardé.
la source
Lorsque nous enregistrons un rappel réseau à l'aide de la
registerNetworkCallback
méthode, il ne se déclenche parfois pas et parfois il déclenche des faux positifs:onAvailable
méthode se déclenche.NetworkCallback
n'est appelé (c'est très étrange à cause de la p. 1)onAvailable
déclencheurs de méthode de connexion Internet . Et je pense que c'est un comportement faux positif parce que nous nous attendons à une observation de la connexion Internet.Comme vous le voyez dans le code ci-dessous, la connexion Internet par défaut est disponible et ne se déclenche que si elle change. Aucun déclencheur faussement positif.
Résumez simplement ceci et cela (mais uniquement pour l'API> = 21):
Comment fournir les dépendances
Et comment utiliser:
la source
Basé sur la réponse de @ KebabKrabby:
Et en l'utilisant presque de la même manière que dans la réponse originale (si vous observez à partir d'une activité, par exemple):
la source