简体   繁体   English

WifiManager 中的 startScan() 在 Android P 中已弃用

[英]startScan() in WifiManager deprecated in Android P

How to get scan result from wifi for example every 3 seconds, without mWifimanager.startScan();如何在没有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.

Notice for this API level i'm using List<ScanResult> results = mWifiManager.getScanResults();请注意,对于此 API 级别,我正在使用List<ScanResult> results = mWifiManager.getScanResults(); without calling startScan , the list contains the wifi AP's but it makes updated very very slow在不调用startScan的情况下,该列表包含 wifi AP,但更新速度非常非常慢

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

Google has now documented the limitations for startScan() function in Android P:谷歌现在已经记录了 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. WifiManager.startScan() 的使用限制为: - 每个前台应用每 2 分钟限制为 4 次扫描。 - All background apps combined are restricted to one scan every 30 minutes." - 所有后台应用程序的组合限制为每 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

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() 直到官方文档发布。

startScan() is actually pretty buggy on P, as I raised Google Issue 79906367 . startScan() 实际上在 P 上有很多问题,因为我提出了Google Issue 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 is80211mcResponder which you check before performing RTT Ranging on the AP.希望我们很快就会听到,因为 RTT 仍然意味着您需要使用ScanResult is80211mcResponder扫描支持 802.11mc 的 AP,您在 AP 上执行 RTT 测距之前检查它。

StartScan() method is deprecated in Android P and new RTT protocol from 802.11mc standard has to be used with trilateration Algorithms. StartScan() 方法在 Android P 中已弃用,来自 802.11mc 标准的新 RTT 协议必须与三边测量算法一起使用。 https://android-developers.googleblog.com/2018/03/previewing-android-p.html 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.应该知道 AP 的 X、Y 位置以便准确定位,并且 AP 应该支持 802.11mc 的精细时间测量。 Intel® Wireless-AC 9260 support 802.11mc and several APs start supporting 802.11mc standard. Intel® Wireless-AC 9260 支持 802.11mc 并且一些 AP 开始支持 802.11mc 标准。

A couple of examples:几个例子:

From WifiManager#EXTRA_RESULTS_UPDATED来自WifiManager#EXTRA_RESULTS_UPDATED

Note: Apps holding android.Manifest.permission.NETWORK_SETTINGS permission 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 中,则常规应用程序无法使用它。

I would guess the intention is to have developers/users use WifiRttManager instead for indoor location atleast [1].我猜目的是让开发人员/用户至少使用 WifiRttManager 代替室内位置 [1]。 Or rely on usual Google Play location services, which is an option in some use cases, but definitely not all.或者依赖通常的 Google Play 定位服务,这在某些用例中是一个选项,但绝对不是全部。 It's optimised for the average use case.它针对一般用例进行了优化。 No use case is the average use case.没有用例是平均用例。

Unfortunately with the way WifiRttManager calculates location it requires the wifi accesspoints to have 802.11mc.不幸的是,WifiRttManager 计算位置的方式要求 wifi 接入点具有 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. [2] [3] [4] 使用 3 个接入点,您可以获得接近 1-2 米精度的位置。

Who knows if they'll place restrictions on this functionality as well though.谁知道他们是否也会对此功能施加限制。 I'm not happy that this functionality is being taken away from users and developers - all it needs is a permission.我很不高兴这个功能被从用户和开发人员手中夺走——它所需要的只是一个许可。

So it appears there will be a dark age for indoor location over the next few years until 802.11mc is popular.因此,在 802.11mc 普及之前,未来几年室内定位似乎将进入黑暗时代。 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 [2] https://github.com/Plinzen/android-rttmanager-sample [1] https://developer.android.com/reference/android/net/wifi/rtt/WifiRttManager [2] https://github.com/Plinzen/android-rttmanager-sample

Additional reading [3] https://en.wikipedia.org/wiki/IEEE_802.11mc [4] https://fit-iot.com/web/wifi-indoor-positioning/补充阅读 [3] https://en.wikipedia.org/wiki/IEEE_802.11mc [4] https://fit-iot.com/web/wifi-indoor-positioning/

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.此方法已在 API 级别 28 中弃用。应用程序触发扫描请求的功能将在未来版本中删除。 Check the documentation here. 在此处查看文档。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM