java Android P 中不推荐使用 WifiManager 中的 startScan()

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/49178307/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-11-03 10:17:25  来源:igfitidea点击:

startScan() in WifiManager deprecated in Android P

javaandroidkotlinandroid-9.0-pie

提问by EAK TEAM

How to get scan result from wifi for example every 3 seconds, without mWifimanager.startScan();

例如,如何每 3 秒从 wifi 获取扫描结果,而无需 mWifimanager.startScan();

Google says :

谷歌说:

startScan() This method was deprecated in API level P. The ability for apps to trigger scan requests will be removed in a future release.

startScan() This method was deprecated in API level P. The ability for apps to trigger scan requests will be removed in a future release.

Notice for this API level i'm using List<ScanResult> results = mWifiManager.getScanResults();without calling startScan, the list contains the wifi AP's but it makes updated very very slow

请注意,我在List<ScanResult> results = mWifiManager.getScanResults();未调用startScan的情况下使用此 API 级别 ,该列表包含 wifi AP,但更新速度非常慢

Update to 12 January 2019 : https://issuetracker.google.com/issues/112688545

更新至 2019 年 1 月 12 日:https: //issuetracker.google.com/issues/112688545

采纳答案by marko.tm

Google has now documented the limitations for startScan() function in Android P:

Google 现在记录了 Android P 中 startScan() 函数的限制:

"We are further limiting the number of scans apps can request to improve network performance and improve battery life.

“我们正在进一步限制应用程序可以请求的扫描次数,以提高网络性能并延长电池寿命。

The WifiManager.startScan() usage is limited to: - Each foreground app is restricted to 4 scans every 2 minutes. - All background apps combined are restricted to one scan every 30 minutes."

WifiManager.startScan() 的使用仅限于: - 每个前台应用程序限制为每 2 分钟扫描 4 次。- 所有后台应用程序组合仅限于每 30 分钟扫描一次。”

Source: https://issuetracker.google.com/issues/79906367

来源:https: //issuetracker.google.com/issues/79906367

Edit 8-Aug-2018: Information has been added also here: https://developer.android.com/guide/topics/connectivity/wifi-scan#wifi-scan-throttling

2018 年 8 月 8 日编辑:此处还添加了信息:https: //developer.android.com/guide/topics/connectivity/wifi-scan#wifi-scan-throttling

回答by Nino Gonzales

I think in API level P they're planning to move startScan() to a different class (WifiScanner) all together with some key differences.

我认为在 API 级别 P 中,他们计划将 startScan() 移至不同的类 (WifiScanner),但存在一些关键差异。

See: https://android.googlesource.com/platform/frameworks/base/+/android-p-preview-1/wifi/java/android/net/wifi/WifiScanner.java

请参阅:https: //android.googlesource.com/platform/frameworks/base/+/android-p-preview-1/wifi/java/android/net/wifi/WifiScanner.java

If there's an alternative solution to this, I'd love to hear it as well.

如果对此有替代解决方案,我也很想听听。

For now, I might just use startScan() until official docs are released.

现在,我可能只使用 startScan() 直到官方文档发布。

回答by meavydev

startScan() is actually pretty buggy on P, as I raised Google Issue 79906367.

startScan() 实际上在 P 上有很多问题,因为我提出了Google 问题 79906367

I don't think that WifiScanner is the replacement either, as that is marked as a SystemApi which means no access for Apps...

我也不认为 WifiScanner 是替代品,因为它被标记为 SystemApi,这意味着无法访问应用程序......

Hopefully we will hear soon, as RTT still means you need to scan for APs which support 802.11mc using ScanResult is80211mcResponderwhich you check before performing RTT Ranging on the AP.

希望我们很快就会听到,因为 RTT 仍然意味着您需要使用ScanResult is80211mcResponder扫描支持 802.11mc 的 AP ,您在对 AP 执行 RTT 测距之前检查它。

回答by Jose A Lopez Pastor

StartScan() method is deprecated in Android P and new RTT protocol from 802.11mc standard has to be used with trilateration Algorithms. https://android-developers.googleblog.com/2018/03/previewing-android-p.html

Android P 中不推荐使用 StartScan() 方法,并且必须将来自 802.11mc 标准的新 RTT 协议与三边测量算法一起使用。 https://android-developers.googleblog.com/2018/03/previewing-android-p.html

X,Y position of the AP should to be knonw for accurate positioning and the AP should support 802.11mc's Fine Time Measurement. Intel? Wireless-AC 9260 support 802.11mc and several APs start supporting 802.11mc standard.

需要知道 AP 的 X、Y 位置才能准确定位,并且 AP 应支持 802.11mc 的精细时间测量。英特尔?Wireless-AC 9260 支持 802.11mc 并且一些 AP 开始支持 802.11mc 标准。

A couple of examples:

几个例子:

回答by Sevenate

From WifiManager#EXTRA_RESULTS_UPDATED

来自WifiManager#EXTRA_RESULTS_UPDATED

Note: Apps holding android.Manifest.permission.NETWORK_SETTINGSpermission are exempted from scan throttling.

注意:持有android.Manifest.permission.NETWORK_SETTINGS权限的应用程序不受扫描限制。

Note: This is a system permission, regular apps can't use it without rooting and moving the app to the 'privileged' location or having it baked into a custom ROM.

注意:这是系统权限,常规应用程序无法使用它,除非生根并将应用程序移动到“特权”位置或将其烘焙到自定义 ROM 中。

回答by Manmohan Soni

I think google is planning to restrict application from scanning wifi.

我认为谷歌正计划限制应用程序扫描 wifi。

This method was deprecated in API level 28. The ability for apps to trigger scan requests will be removed in a future release. Check the documentation here.

此方法已在 API 级别 28 中弃用。应用程序触发扫描请求的功能将在未来版本中移除。 检查此处的文档。

回答by heliam1

It appears Googles intention might be to force developers to use WifiRttManager instead for indoor location atleast [1]. Or rely on usual Google Play location services, which is an option in some use cases, but definitely not all. It's optimised for the average use case. No use case is the average use case.

看来 Google 的意图可能是迫使开发人员至少使用 WifiRttManager 来进行室内定位 [1]。或者依靠通常的 Google Play 位置服务,这在某些用例中是一种选择,但绝对不是全部。它针对一般用例进行了优化。没有用例是平均用例。

Unfortunately with the way WifiRttManager calculates location it requires the wifi accesspoints to have 802.11mc. However you don't need to connect to these points. Virtually 0 routers today have this standard. [2] [3] [4] With 3 access points you can get location close to 1-2m accuracy.

不幸的是,通过 WifiRttManager 计算位置的方式,它需要 wifi 接入点具有 802.11mc。但是,您不需要连接到这些点。今天几乎有 0 台路由器有这个标准。[2] [3] [4] 使用 3 个接入点,您可以获得接近 1-2m 精度的位置。

Who knows if they'll place restrictions on this functionality as well though. There is simply no excuse for taking this choice away from users and developers. Disgusting.

谁知道他们是否也会限制此功能。没有任何理由让用户和开发人员放弃这种选择。恶心。

So it appears there will atleast be a dark age for indoor location. Perhaps a workaround is to have devices you are connected to and ping them.

因此,室内定位至少会出现一个黑暗时代。也许一种解决方法是让您连接的设备并 ping 它们。

[1] https://developer.android.com/reference/android/net/wifi/rtt/WifiRttManager

[1] https://developer.android.com/reference/android/net/wifi/rtt/WifiRttManager

[2] https://github.com/Plinzen/android-rttmanager-sample

[2] https://github.com/Plinzen/android-rttmanager-sample

Additional reading

补充阅读

[3] https://en.wikipedia.org/wiki/IEEE_802.11mc

[3] https://en.wikipedia.org/wiki/IEEE_802.11mc

[4] https://fit-iot.com/web/wifi-indoor-positioning/

[4] https://fit-iot.com/web/wifi-indoor-positioning/