IssueTracker

Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:

Android build
Which Android build are you using? (e.g. OPP1.170223.012)

Steps to reproduce
What steps are needed to reproduce this issue?

Frequency
How frequently does this issue occur? (e.g 100% of the time, 10% of the time)

Please provide sample project or apk to reproduce the issue.  Also mention the steps to be followed for reproducing the issue with the given sample project or apk.

Android bug report capturing
After reproducing the issue, press the volume up, volume down, and power button simultaneously. This will capture a bug report on your device in the “bug reports” directory. Attach the bug report  file to this issue.

Alternate method
After reproducing the issue, navigate to “developer settings”, ensure “USB debugging” is enabled, then enable “Bug report shortcut”.  Capture bug report by holding the power button and selecting the “Take bug report” option.

Screen Record of the Issue
Please capture screen record or video of the issue using following steps:
adb shell screenrecord /sdcard/video.mp4
Subsequently use following command to pull the recorded file:
adb pull /sdcard/video.mp4
Attach the file to this issue.

Note: Please upload the files to google drive and share the folder to android-bugreport@google.com, then share the link here.

Android Build is PPP2.180412.013 on a Pixel XL, but it also happens on a Pixel.
I have created a sample app and APK based on our code in:
https://drive.google.com/drive/folders/1b-Qe82kEjN3REdwswNl0YXnSLUbs410K?usp=sharing

It happens every time, you just need to run up the app and leave it running for a while (less than a minute).
On Android 8.1 it will run updating the notification with Wifi scan results without any errors or throttling.

On P developer preview 2, we get a few scan results and then we start to see failed scans:
05-18 16:05:29.561 914-1607/? I/WifiService: startScan uid=10331
05-18 16:05:29.564 914-1346/? I/WifiScanRequestProxy: Scan request from com.example.navenio.wifiscan throttled
05-18 16:05:29.566 914-1346/? E/WifiService: Failed to start scan
05-18 16:05:29.571 22840-22840/com.example.navenio.wifiscan D/NvWifiService: received scanresult
    WiFi scan EXTRA_RESULTS_UPDATED showing as failed

See the Notification in the app and logcat for debug tracing.

We have passed this to the development team and will update this issue with more information as it becomes available.

Just to confirm we are still seeing the throttling of the foreground Wifi scans on the Pixel XL running P Beta 2 build PPP3.180510.008.

It is slightly different in that we see the startScan marked as failed, although it then goes on to return the scanResult with the failed extra in the Intent:
06-08 10:11:47.095 9671-9671/com.example.navenio.wifiscan D/NvWifiService: exectuting mStartScanRunnable
06-08 10:11:47.096 9671-9671/com.example.navenio.wifiscan D/NvWifiService: in startScan
06-08 10:11:47.099 909-1645/? I/WifiService: startScan uid=10297
06-08 10:11:47.104 909-1266/? I/WifiScanRequestProxy: Scan request from com.example.navenio.wifiscan throttled
06-08 10:11:47.107 909-1645/? E/WifiService: Failed to start scan
06-08 10:11:47.110 9671-9671/com.example.navenio.wifiscan D/NvWifiService: Wifi startScan failed
06-08 10:11:47.114 9671-9671/com.example.navenio.wifiscan D/NvWifiService: received scanresult
06-08 10:11:47.117 9671-9671/com.example.navenio.wifiscan D/NvWifiService: WiFi scan EXTRA_RESULTS_UPDATED showing as failed

This is the new behavior of the P platform - irrespective of the target API of the app.

Scans are throttled:
- Foreground apps are throttled less than background
- Background apps are heavily throttled

Please provide feedback on specific use-case which isn't met by the existing foreground scan ability.

Our application performs indoor localisation using periodic Wi-Fi scans. Our users run the application in foreground to navigate in an indoor environment and therefore accept the energy consumption of this system. However, the throttling mechanism in developer release of Android P makes it difficult for our application to provide this functionality. As Fused Location Provider or any other API provided by Android does not work well in an indoor environment, this throttling mechanism makes it very difficult for us to continue to provide indoor navigation capability. We are also concerned that there does not appear to be any mechanism available for our users to accept and whitelist our application.

We cannot find any documentation that specifies these throttling periods or any announcement related to this throttling. Can you provide more information?

Additionally, startScan() in WifiManager has been tagged as @deprecated. Does this mean that the ability to perform wifi scans is going to be completely blocked by applications or will there be an alternative mechanism?

We are not the original reporter of this bug report but totally agree with the comment #7. Indoor navigation applications utilising WiFi access point RSS values do not work with the latest Android P releases. And this is not only indoor navigation, but also all kind of Wi-Fi network analyzers, Wi-Fi heatmap creators and Wi-Fi coverage analysers will stop to work. Is there some reason to limit the foreground applications to start Wifi scans?

Is there any update on this. We are facing the same issues , also did not understand the restriction behind scanning WIFI even when app is in foreground

Any updates to this? Hopefully this new throttling feature is removed at least from foreground applications.
If nothing else can be done, then please at least implement a developer setting feature which can be used to disable this throttling.

Current throttling level of startScan makes it basically useless for indoor navigation (Actually, it makes it useless for most applications of WiFi network info gathering that one can think of).  At a minimum, it should allow updates at reasonable intervals for a person walking. Typical walking speed is 1-2 meter/second and positional accuracy possible is 1-2 meter or better. So as a compromise at least allow one startScan per second? So, can you please provide some way to remove the throttling.

It is, of course, important to limit battery usage by applications, particularly background apps. But several attempts to do this, such as this one, dramatically reduce the functionality of the device. How about as an alternative: introduce a new permission "Allow app to use battery power more heavily than typical - at least when in foreground"?

"startScan per second" is very frequent actions.
Most of Wi-Fi Full Scan operation has to time about 2 ~ 5 second.

Currently it appears to be throttled if you perform a scan about every 20 seconds, but as there is no documentation on this change, this is only from experimental testing with Pixels.

Fortunately WifiRttManager.startRanging is not similarly throttled. So one can do Wifi FTM RTT ranging frequently
after getting a list of Wifi APs that support 802.11mc. Just can't update that list of APs too often...

Please find the below comment received from our engineering team:
"
Permissions
- WifiManager.startScan() requires all of the following permissions:
  - ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION
  - CHANGE_WIFI_STATE
  - Location mode on the device to be enabled

- WifiManager.getScanResults() requires all of the following permissions:
  - ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION
  - ACCESS_WIFI_STATE
  - Location mode on the device to be enabled

If the conditions are not met a SecurityException will be thrown.

Call Limitations - Throttling

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."

Throttling Wi-Fi scanning for improving battery life is quite sensible.
However, this severely limits some of the use cases mentioned above.

It will make more sense to throttle Wi-Fi scanning by default but allow the user of the device to whitelist applications and make them exempt from throttling where the user is aware of and accepts higher energy consumption in return for a certain functionality. For example, users accept the higher energy consumption of GPS. It wouldn't make sense to throttle GPS to simply improve battery life and not allow the users to make full use of the capability if they are willing to accept the energy consumption.

Meantime, thanks for giving explicit information on what the throttling limits are.

Thanks for documenting the limits. But still the reasoning does not make sense for foreground applications. With this limitation you are blocking in Android P devices WiFi network analyzers, indoor navigation apps needing continuosly fresh list of access points and their rss values.

https://developer.android.com/reference/android/net/wifi/WifiManager.html#EXTRA_RESULTS_UPDATED documents:

An app requested too many scans in a certain period of time. This may lead to additional scan request rejections via "scan throttling" for both foreground and background apps. Note: Apps holding android.Manifest.permission.NETWORK_SETTINGS permission are exempted from scan throttling.

So you are planning to change this that NETWORK_SETTINGS is not taken into account?

Sounds like a very bad plan.

Please find the below comments received from our engineering team:

Reply for comment #18.
We are exploring solutions for future releases.

Reply for comment #19.
Question about an app's scan requests impacting other apps:
- If the app is foreground that its requests are *not* counted against any other app
- If the app is background then correct: all background apps together are restricted to one scan per 30 minutes
- Scans by the app holding NETWORK_SETTINGS are also not counted up against the quota for any other app

We've deferred this issue for consideration in a future release. Thank you for your time to make Android better.

In case you want to provide more information with respect to this bug, please file a bug in AOSP via "https://goo.gl/TbMiIO".

A response as We've deferred this issue for consideration in a future release without any solid explanation regarding this forced throthling is below any level of professional development.

This is a request to the Google engineering team regarding the throttling of `Wifimanager.startScan()` in foreground to
a) proof it is necessary to force users to improve battery life and to force in such a way by this throttling
b) proof it is necessary to force users to improve network performance and to force in such a way by this throttling
In case of argument of privacy
c) proof it is necessary to force users to improve privacy and to force in such a way by this throttling

imho a change significantly limiting functionality for users should never been made if such change is not proven in any way and if such a change is forced without providing users with controls to override such change and if any other solution is available without the need to force users.

Taking away functionality from users in favor of improvements users can already control can not be considered improvement. Foreground processes are commonly under control of the user. If any of these are causing significant limitation of battery life and/or network performance than this must be considered user choice.

I need Wi-Fi analyzer as a tool for work. This has eliminated my abilities to use my handheld device as a network scanner and finding rogue access points. Increased difficulty for troubleshooting my Wi-Fi networks.

I have had to stop using Android-based devices to support basic network maintenance tasks. Throttling foreground apps is absolutely absurd.

Of course throttling foreground apps is weirdest thing they could do. What
are other operating systems that can run Android apps on mobile devices?
Maybe it is time to leave Android? It becomes more and more iOS-like.

On Fri, May 17, 2019, 21:27 <buganizer-system@google.com> wrote:

Unthrottle the wifi scanning please! If nothing else.....have it an option in the wifi screen so a user knows it is sucking his better.

Dear Google. The least you can do is to implement a developer mode setting to disable the Wi-Fi scan throttling. This would make it at least possible to use Android 9 (and newer) devices to analyse surrounding Wi-Fi networks with applications suited for that. Also other use cases desperately need this like Wi-Fi positioning.

Once again, thank you for submitting request. After following up with our product and engineering teams, the request will not be considered at this time.
In Q, there is a new developer option to toggle the throttling off for local testing (Needs a rooted device).
adb shell settings put global wifi_scan_throttle_enabled 0

Are you 100% sure that this command needs a rooted device?

Looks like Android 8 will be my final Android OS then, well done (y)

Dear Google,

Requiring root and an adb command is a baloney resolution. Make a simple toggle in system Wi-Fi preferences to allow the USER to decide if the value of wifi_scan_throttle_enabled is 0 or 1.

Thanks,
Everyone else on this thread

100% this. A simple toggle in wi-fi settings or even in dev options that doesn't require root is definitely the most elegant solution. I do wireless design for a living and it would be great to be able to once again have the ability to use Metageek's InSSIDer (paid) or Wi-Fi Analyzer (free) on my phone for basic testing of customer networks or in pre-sales situations before an actual assessment occurs. Ekahau thankfully renders this need largely unnecessary with their new iPad software, but there are times when onsite without survey gear or time to fire up a laptop it would be very useful to just pull out my Pixel 3 and do a quick check on something, but since P, all I can do is test client association.

Have any of the product or engineering team members actually read this thread? Or any of the completely valid points we've raised, or the many other threads on various other platforms?

I can't believe that they would completely ignore this yet again.

+1 to everyone else saying that this should be a 'user' setting, in that in doesn't require root. If you really don't want most users accessing it for some baffling reason, just put it under the developer settings section as others have mentioned which appeases everyone -- especially those who want more from their device but are locked out of their bootloader or don't have root for many other reasons..

does this mean that startScan() will continue to be supported at least in some form, or is it still deprecated and will be removed without substitution? (after Q? or when?)

Seems a little anti-competitive. Doesn't this prevent anyone developing a better wifi positioning than Google?

Requiring root is a ridiculous step that the vast majority of users who want this functionality will never perform.

I don't see the justification for any of this in the context of foreground apps.

> di...@gmail.com added comment #36:
> Seems a little anti-competitive. Doesn't this prevent anyone developing a better wifi positioning than Google?

yes, and it's pretty blatant too


--
sent via Gmail web interface, so please excuse my gross neglect of Netiquette

First bug 82 crippling emergency operations, and now this... you've just made Android useless for wireless analysis.

Hell with this.  Time to migrate my code off of Android and over to Raspbian.

Also, they broke CardCast which was a lot of fun at parties with Chromecast! Have to resort to *gag* IOS devices now for that or my old ass Asus TF tablet still running Lolipop.

Speaking of Raspbian, since this appears to be a thread with wireless nerds - check this guy out: https://www.wlanpi.com/

The problem with all of this is that Google is just forcing people to go
use older, unsupported versions of Android or potentially unsafe, custom
ROMs, further fragmenting the ecosystem and making it unsafe for their
users.

On Fri, May 24, 2019, 11:38 AM <buganizer-system@google.com> wrote:

Google has the best minds in the world.  Highly paid specialists in an amazing team.  Surely these experts can figure out a reasonable solution to this problem.  Maybe there's some underlying security issue that hasn't been publicized. Whatever the case, it was shock to suddenly discover I could no longer conveniently do wireless install analysis.  Trundling around with my Windows laptop gets the job done but is certainly not convenient.  I can do the task with one portable device but not with another, my Android smartphone.  What gives?

Couldn't it be a developer option under developer options not requiring root, but hidden from regular users who may not understand the battery trade off?

Are there are other Wifi scanning implications, perhaps related to security concerns of some sort?  What's the real reason for this throttling inconvenience??  Heck, when I'm using wireless network scan applications, I always tell the app to keep the display on full bright, which is a far bigger draw than the scanning.  Today I was using Network Cell Info to check out an antenna move with the display deliberately held on.  Any underlying radio activity power consumption is trivial compared to the display drain I foreground choose to cause.

the next logical step would be to only allow full display brightness and flash/torchlight for 5 seconds every minute, since this stuff is so battery-intensive. video playback, camera, and voice calls should be restricted as well.

as the result of this, I cannot update to Pie, since it is broken, and I am forced to use the last version of Oreo which has not received any security updates for my phone since August 2018, when Pie was released.

I excitedly jumped right on the Pie update as I always do.  I trust Google implicitly to produce the world's best OS product, and now I've been let down.  My confidence is shaken by this annoying Wifi scan throttling snafu.  I mean, what's going to go wrong on the next Android update.  My physically inconvenient Dell XPS15 laptop does Wifi setup assessments perfectly, rescanning every few seconds, but my far more convenient Android smartphone is useless for this purpose. One portable device works, the other doesn't (but used to).

Nobody should accept a hidden setting that users have to toggle on to make wifi scanning work properly again for foreground apps. This functionality had existed forever. It is not worse than GPS, or recording video, or even Google's own new AR navigation which in the foreground drains my battery at a rate I've never experienced before.

To put this functionality in a hidden option means it is not worth developing apps for it because the market share of users who can use it without trouble will be tiny.

common google. Users know that when using apps that throttling wifi they will drain the battery faster.

At least GIVE the option to the user to accept or not the wifi throttle via permissions as it happens for all android services!!!

hope you rethink that

This is bad guys- basically P now breaks 1000s of Apps for no good reason that I can see. My usecase is that i've developed an app that allows for users to survey wifi access-points within geographical boundaries that now will no longer work on P. Surely you can have it as an option for the users to opt-in with a permission based approach.

This is very disappointing. Requiring root access doesn't seem like a reasonable or appropriate course of action.

Maybe someone, with concise tact, can post this disappointing news on reddit and gain some more exposure. Many people know that their apps don't work, but aren't aware of exactly why, or that it's a conscious decision by the Android team to intentionally make it difficult, if not impossible for foreground applications.

Wow. Just wow.

These are the types of decisions that frustrate end users. Surely as others have mentioned there's a compromise (like adding a toggle in Developer Options) because frankly saying "just use this root required ADB command" is shit. Especially when Google themselves has made rooting less supported (SafetyNet) and on plenty of other devices you permanently lose things (Samsung in particular loses Samsung Pay). Yea because that's what people want to do, choose between what features they can live without based on rooting or not.

I also use a wifi SSID scanner app from time to time and saying "well, guess you have to root" is entirely unacceptable. Which instead means I have to stay with Oreo and means I get no security patches. I was probably already going to have to due to the blocking of Substratum themes without root on Pie but now I have to or some of the tools I use flat out wont work correctly.

How am I supposed to use my wifi monitoring app to determine where my house has weak signals, or to figure out what is interfering with me if the app never updates the data, and I have to spend hours sitting around for your stupid throttling to let me check? How is this helpful in any way? I didn't used to understand the appeal of all these anti-Google OSes like /e/, but I think I have finally figured out why it is unacceptable to have an anti-consumer dictatorship of an ecosystem run by Google...

I was wondering why the app I use for wireless network checks had become unusable. This decision is ludicrous.

I wish I had known this terrible decision was in the pipeline before I purchased my Pixel 3 XL this past year.

And needing to root the device is not a solution, corporate controlled devices that need to be joined to MDMs need access to WiFi scanning as well.

This is such an artificial, needless constraint in its current state, I can't overstate how frustrating it is to read the excuses presented in this thread.

For years WiFi scanning abilities has been one of the features that set Android in a league of its own compared to Apple. I would hate it if Google started to limit it's OS in that way.
WiFi throttling could be a feature, but a feature that can't be turned off is a bug!!!

Please switch on your brain and make a permission for this

Honestly this is a dealbreaker feature for me, i always used a WIFI scanning app for my work ever since i got my first Froyo device. Now the choice is this : root (loose functionality, and possibly system stability), downgrade (makes getting a new device moot) or switch to iOS.  Also i can't use a rooted device for work, none of my work apps will even start. Also its a breach of policy for us.

How do you people consider that req root for something to work is acceptable, if even you'r own pay app doesn't work if the phone is rooted !?!?!?!?

Google, this is a completely unacceptable response telling us we need to root our phones to take advantage of the features we all grew accustomed to and used all the time.  Please make a permission to fix this.

This is an issue with Google as a whole…

Have you used Google Music/Youtube Music?
Both products are completely abandoned, even marketing does not exist at all.
It is a shit pile, and no one cares… there is no communication to the outside world… you cannot contact any official to get a status on an issue report…

At one time, someone errorsonly allowed my Account access to the internal ticket system and non of the other known issues had been put up for fixing…

Googles product development management has no communication at all… and that will bring it down to the Apple state, because Google, obviously, will never really need any freedom on Android, they can simply take it. And that is bad.
The whole Google Play crap should be optionally installable and the Huawei debacle has shown how bad this type of control can end…

Instead, Google f...s their quite healthy eco system of niche apps that people created upon android.

This decision has very real ramifications for your user base in the IT industry. We choose your platform for flexibility and openess..

This explains why all of my site survey and diagnostic tools no longer work.  More than half of my staff is on Android, including myself with a fairly new Galaxy S9.

This can easily be remedied with a developer setting, Requiring root is unacceptable -breaking our mdm and security policies (never mind losing core functionality due to SafetyNet).  Mistakes are made but how does no one appreciate the consequences of this draconian decision?  I expect this crap from Apple, not in Android.

I am equally baffled by this decision. Android devices have long been my preference, but in the IT field we depend on WiFi scanners to troubleshoot issues. Please make this a developer option that doesn't require Root.

We use Wifi scanning apps almost every day in our work installing internet service and managing our customers LAN setups .  This renders them useless.  Carrying a second device simply to do WiFi scans is the height of stupidity.

It is utterly unbelievable that Google has gone so far with this throttling and not given users a choice. All the things Google lets me do without rooting my phone, but I can't *scan for WiFi networks"? You've gotta be kidding me. One of the biggest advantages Android had for power users compared to iOS was the wealth of WiFi analyzer apps which simply could not be done on iOS. Well, it seems Google has ensured that now no mobile device has such capability.

Dear Google, Please hire more adults and fewer children.

Comment 62 contributed nothing to the conversation. Please refrain from
attacking people who are hired to help the user community and instead make
a coherent and intelligent case for why the throttling should be removed.
Name calling and whining only makes you look like the child and makes the
recipient of the attack less inclined to care that your favorite app no
longer works. You are asking them to add more work to the Devs plate. The
broken code is already in place and the easiest thing for them to do is
nothing; when you attack them, you give them a good reason to do nothing.

On Tue, May 28, 2019, 2:19 PM <buganizer-system@google.com> wrote:

Also don't understand this decision and please reconsider.  We use wifi scanning apps daily for troubleshooting and rely on the feature.  This should be something that is settable without rooting the device.

I work in the WISP industry and being able to scan WiFi networks is a very big part of my job. I need this functionality! You are hurting my ability to do my job efficiently!

"A new developer option to toggle scan throttling off will be available from Q Beta 5 onwards."

This is certainly a step in the right direction, thank you! It will be difficult to explain the steps involved to our tens of thousands of users around the world, but it's a start. In the future please either remove the foreground throttling, or create a runtime permission, either of which would let the user decide with low friction. Best of luck with the release.

I've been trying to speculate the "real reason" for the throttling  (viz., battery life as smokescreen).  It would come down to security I imagine.  However, concerned Wifi users and organizations can hide the SSID, use strong passwords (both Wifi access and admin), and/or use nonsensical SSID names.  Mine are gamonal, chaski, ayni, and maahe (actually real words), but there's not much to learn from them.  Deliberate bad actors can better scan with a compact Windows notebook, perhaps with external high gain or directive antenna.  A smartphone is mediocre for really serious sleuthing.  When I use scanning apps with continuous screen-on settings, the display drain far outpaces the scanning function, so I've had cause to wonder.

By the way, just for reference, here are some relevant measurements of battery usage.
This is on Pixel 3 XL, running Android Q

(1) No Wifi scan, just screen on (dim):  4.8% drop in battery charge per hour.

(2) Running Settings > Wifi, which scans every 10 seconds, causes 6.6% drop in battery charge per hour .

(3) One scan every 2.5 seconds (max rate possible) causes 9.7% drop in battery charge per hour.
(on Pixel 2 XL it wouldn't drop quite as fast because it takes longer - more like 3.7 seconds - for a WiFi scan).

So, yes, if you run flat out you can about double energy consumption.
Although, in typical applications you wouldn't be doing this hour after hour.
Also, for most purposes you don't need to run a scan every 2.5 seconds, and if you do, you'd presumably be aware of the implications for battery charge.

I figured out a workaround for end users that works alright in Android Pi. I tested this on a OnePlus 5 running Android 9 and the WiFi Analyzer app by Abdelrahman M. Sid.

Go to Android's Settings > Wi-Fi & internet > Wi-Fi. This is the settings page that displays available Wi-Fi networks. Now, active split-screen (long pressing the overview button usually does this), and select your Wi-Fi scanner app as the other one to display on screen. If the app is written well, it will display whatever scan results are available, even if its own scan request was rejected (see comment 118 in issue 112688545: https://issuetracker.google.com/issues/112688545#comment118 ).

I don't know how frequently Android's Wi-Fi settings page scans for new networks, but it seems to be pretty frequently, and it's certainly much more frequent than 4 times every 2 minutes. Having both the settings page and your Wi-Fi scanner app both up on screen at the same time allows the settings page to request scans, and for the scanner app to display the record of detailed results.

Because of the large number of "me too" comments with no new content, I was about to "unstar" this issue - and so make it look _less_ popular and less important. That's the inescapable irony of "me too" comments.

So I almost missed the split screen workaround in comment #69. I just tested it and I can confirm it is pure gold, go and try it. Amazing find, thanks a lot!

PS: that workaround isn't without irony either.

The split screen workaround is great. I should have thought of it myself,
but I'm glad someone else did.  On my Android 9 OnePlus 6T device using
the Abdelrahman M. Sid WiFi Analyzer pro version, there's a rescan about
every 10 seconds.  That's usable.  Great and thanks.  I'm going to email
this solution to Abdelrahman right now although I bet he may have seen it
by now since he follows these bug forums.  Yay.

On Sat, Jun 1, 2019 at 1:07 PM <buganizer-system@google.com> wrote:

Just FYI - this is an old issue against P Beta, so probably not the best issue to be complaining about.
However the good news is that in Q Beta 4 we can turn off Wifi throttling on unrooted devices with 'adb shell settings put global wifi_scan_throttle_enabled 0'

Possibly the scanning apps (e.g., A. M. Sid's "WiFi Analyzer") could be
redeveloped to use the system's own continuous scan results rather than
performing an additional simultaneous layer of scans.  In fact, it seems
less than elegant to have two sets of WiFi scans going - the system and the
app separately.  When a scanning app is used split screen with WiFi
Settings, the concept of using the system scans can be immediately
visualized.  In fact, that's how I do WiFi scans now.  My Android Pie
OnePlus 6T scans every 10 seconds, which is usable.

On Thu, Jun 6, 2019 at 2:30 AM <buganizer-system@google.com> wrote:

@google

Is it possible to set wifi_scan_throttle_enabled via DevicePolicyManager on provisioned devices?

adb shell settings put global wifi_scan_throttle_enabled 0

https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setGlobalSetting(android.content.ComponentName,%20java.lang.String,%20java.lang.String)

please, comment and star this issue that we opened for Android 11 DP, after DP2 chance that anything will change for the Wi-Fi scan will be quite low, do it is the right moment to show your concerns
https://issuetracker.google.com/issues/150633522

Is this problem solved?about wifiscan？

In Pie this is not solved. In Android 10 they gave us an option to disable throttling in Developer Menu in which upon disabling it it increases to about 2 scans per second which is pretty fast.
So in order to work around this you must update your device to 10 or stay in Oreo which I can't recommend.