IssueTracker

What do you mean by "share"? You mean take a screenshot of it?

You can already have a reference to the MapView simply by instantiating it on your own. Please do not forget to forward events (onCreate, onPause, etc.) to it.

For taking a screenshot you normally use a Bitmap to be drawn on by the view. This does not work with the API v2 as it uses OpenGL. Thus the outcome Bitmap is a just black.

It's possible via android build-in command like what eclipse DDMS "screen capture" did. The problem is the authority to execute the command.

Hope the next release can enhance this to take screen capture on google map v2.

Thanks...

Yes, this was exactly what I was trying to do a few minutes ago. Didn't work.
Please guys, add such a functionality!

I am developing an application in which this is a necessary and pivotal function; if this action is not possible then the majority of the app would be useless.  Currently, the app uses Google Maps API v2, and I would really hate to have to downgrade back to Google Maps API v1 for this one function.

i am developing an application in which this is a necessary .

Re #2: I don't know what the MapsV2 lib does internally, but it has no GLSurfaceView in the client's app. I suspect they render it in another app and bit-copy over the results into a private, from plain SurfaceView derived view that you can access in your app. I'd really like to see this to get https://code.google.com/p/robotium/issues/detail?id=462 supported.

#9 - we essentially use a GLSurfaceView. It's a slightly modified version, though, so gets obfuscated by proguard.

Users need to be able to specifically opt into interesting behaviors, or there won't *be* any interesting behaviors to opt into.  Not everyone can run off and build their own kernel, or even find a phone that lets you do that anymore.

There are some specifically interesting uses for fine grained radio monitoring.  It's not all evil hacks.  http://rfpose.csail.mit.edu/  I've been exploring similar.

We added GoogleMap.snapshot:
https://developers.google.com/maps/documentation/android/reference/com/google/android/gms/maps/GoogleMap

Note that the bitmap returned by snapshot cannot be sent off the device - use it for things like thumbnails or in notifications. See the docs for more complete information on how you can use snapshots.

Thank you very much!

Many thanks!

[Comment deleted]

Just update from ADT, the google-play-services.jar is created on 2013-07-24. Is this the right version, did not see the method "snapshot()".

Thanks...

[Comment deleted]

Nope, it looks like nothing has been released yet :( Still waiting ...

Sorry all - looks like we (the Maps team) launched a bit early. The client should come through the SDK Manager in the next day or so. You'll see announcements from the Android team.

Thanks very much !

Just want to understand the terms of "off device" - per the original request,  currently the user can take a snapshot of the screen pressing hardware buttons.  this feature which has been added now allows the ability to capture a bitmap programatically.  Are the terms such that the original use case in the original request is not allowed, ie, a screenshot of the activity which is composed of the map view + other views is not allowed to be put in the gallery on the device and emailed?

Clarification around this would be fantastic and appreciated, as we do not want to break the rules.

I would also appreciate further clarification about what is allowed to do with the image.

"use it for things like thumbnails" means it is allowed to store thumbnails off-device? E.g. a thumbnail of a track to be stored together with a track file on Google Drive, so that in the file listing the user sees the thumbnails. What is then the maximum pixel size to be considered a thumbnail?

I would suppose any restriction will be due to Google's rights on the map data, rather than the API, so if using a TileProvider with non-Google maps there is no restriction?

OK, the "snapshot" is fine now. And my problem is the same with #21.

THANKS...

How about #21, #22 ? Thanks...

Would it be possible to use this feature to embed a thumbnail in an online video, while respecting the Attribution Clause and this specific point from Google Maps Guidelines?

"In all online video cases, you must show attribution to both Google and our data providers on-screen at the time the content is shown. You may not move the attribution to the end credits or fade it out after a few seconds. We cannot grant an exception to this requirement under any circumstance. Please see our attribution page for more information."

Thanks

any current solution to make a screenshot of the whole screen (maps + layouts, textviews, imageviews, etc) ???

Please return to the old behavior. It affects our daily activities in WiFi optimization.

Google repeatedly shows that it is utterly irresponsible in its actions.

I can only say positive things about reducing background Wi-Fi scans, but I don't understand why this is being done for apps in the foreground and especially why the limit was raised so aggressively.

The right intentions but the wrong execution of this change, please keep the old behaviour when the application is in the foreground

The app I work on also depends on frequent WiFi scanning on a single place and the feature, although not completely broken, is not working properly on Android Pie due to this limitation. It's just really bad that the change is enforced and no workaround/alternative is provided. Google devs might say "it might be fixed/updated on the *next* release"... so how do we proceed with the current version?

Will there be any public feedback on this issue, or is this just hoping people calm down and accept for God's sakes?

At #30, the best public action I can imagine is to encourage to vote for this issue. This is an objective metric that can be used by the Android dev team to take a decision.

I previously said: "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..."

But, actually, throttling startScan is still a show stopper for FTM RTT. Here is why: according to Wikipedia, a comfortable walking speed is 1.4 meter/second (although some may walk as fast as 2.5 m/sec). At that rate, 30 seconds corresponds to 42 meters. That means you will be out the other end of the building by the time you get a second set of potential Wifi APs for ranging! Add to that that startScan() rarely gets all of the available APs so one has to run it more than once to get most of them anyway. Further, while in quite environmen,t out doors, without obstacles, one can pick up an AP 50 meter or even 90 meter away, this is not the case indoors. In my house, for example, Google Wifis that are more than 10 meters away are only picked up occasionally.

I totally agree with #1!

I also agree with #1!

+1 for #1!

Please do not post simple "+1" messages without more detail as it notifies everyone watching the issue and has lead to Google locking them before.  Simply click the star icon to show support for the problem as described.

Apologies in advance to anyone who has been pinged by this message.

1. Whilst this has crippled some popular apps like WiGLE, many Wifi Analyser-like apps are also made unuseable by the change and it makes our  WiFi site analysis tools unusable. Moving at more than about 1 metre every 10 seconds means that vital information is missed doing a site survey. < This is a foreground-app problem directly caused by this issue.

2. As an RF specialist l'm extremely dissapointed at impacts on wifi site survey tools - our current workaround is to carry up to 10 devices instead of 1 and then manually merge the data later, wasting about 2 hours per day. We've currently gone back to Android 7 devices as a crisis response and we are trialing "the unmentionable" fruit-based competition. I never thought I'd see the day :(  

3. Our in-house employee and warehousing pick-cart movement and tracking system is totally broken by this too as it relies on scanning the nearest APs to work out it's location within the buildings. Before you ask - there no GPS signal in here (entirely metal-frame and roof building, lower stories, industrial environment) and no gateway to the internet because it's totally airgapped to the outside world, so non-GPS location-fixing can't work either. We now have several dozens of expensive brand-new mobile carts that are unuseable unless we use older pre-Android - an upcoming security nightmare for us is being pinned upon us. This is both a background and foreground-app problem, depending on the current user status and location of the cart operator, in our specific use case. Personally I'd prefer the background-app scan limit set to a more acceptable level too, eg: once every 5 or 10 minutes, though the foreground scan limit is what will put us out of business without very serious non-Android investment (our contingency investigation concludes that massive, business-crippling investment will be required if we can't use the extant, used-for-other-purposes, WiFi APs at our sites. You're basically breaking something that has worked perfectly fine for several years with zero hardware capital investment before Android 9.  < This is a foreground-app problem directly caused by this issue.

4. I am aware of other logistics systems with similar problems - it's not just ours. Another industry I know affected in Android 9 fleet rollout is courtesy golf-cart style electric vehicle pools at airports - they use the same underlying code as ours to detect roughly where the carts are in near-realtime, derived from AP scans (there's neither GPS signal inside the metal-roofed buildings nor internet access on their intranet APs)
Large site inside-of-building location beaconing systems that *don't* use extant WiFi APs often run into million-dollar+ capital investments, so WiFi AP scanning as a means to determine onsite location is almost universal in industry for mobile vehicles, robots and similar portable assistive tech. <This is a foreground-app problem directly caused by this issue, as well as being affected by the background limit (of once per 30 minutes) for multi-purposes devices.

5. Many large supermarkets use it for restocking both front of house and in the rear warehouse, though the more open scale of their buildings gives less position granularity as our use-case (many rooms or bays with high RF attenuation in between, yet each one having an existing AP for other, non-location purposes. Indeed - many large sites have WiFi APs fittted in some areas *solely* for geo-location or moveable assets. As this is a relatively new technology in the scale of things, it's the norm to use recent smartfone or tablet devices as multi-role IoT+user devices.
 
6. Frequent WiFi scanning is far more common than your developer's assumpion of domestic customers running a wifi analyser while walking slowly  around their home once every couple of years - in fact, some organisations depened ENTIRELY on it working at a reasonable rate so that a picker on a forklift or motorised picking cart can have their pick route optimised and altered en route - these vehicles can travel upwards of 12km/hour in our case and even faster going from between stock areas. <This is a foreground-app problem directly caused by this issue, as well as being affected by the background limit (when an operator has another app foregrounded for inventory control or other purposes like using a browser, making a call or similar user interactions)

7. I forsee this breaking many IoT style uses of Android in the future. Not every Android user is a teenage human with a smartfone watching Youtube or Netflix all day - there are many existing autonomous industrial and semi-industrial uses well established. Android 9 with this limit could kill a whole tranche of valuable use-cases that are currently establishing Android devices as the go-to system for gneral-purpose portable intra-building IoT+User Interaction systems. Not all of these use-cases requrie even occsaional WiFi scanning, but those that do *absolutely depend* on it and increasingly so at movement speeds of more than a slug or snail. Things have moved on very significanlty since the days of small, line-following toy robots.

Please, I'm begging you, at the very least give us a choice (active opt-out on a per-app foreground basis, at the very least) rather than put us out of a job.
Much better, please refrain from such short-sighted drastic changes in the future without any regard to negative impacts on your customers. WHilst I have only around 50 human users onsite at any given time, yet we have a fleet of over 400+ Android devices in industrial roles, most of these under 6 months since comissioning, running 8 already. Our latest aquisition of Pixels is basically collectively useless due to this issue. As more devices move onto Android 9 this organisation is simply going to fall apart as a direct result.
 
I don't normally write bug reports or complaints but it's worth my time typing this as long as the devs take notice. We've already wasted enough of our app developer and tech team time in the last 5 weeks alone. We simply can't fix what you've broken and there are no possible workarounds. More and more will break as the months go on so we've cancelled all our current and future orders of Android 9 devices as a direct result pending resolution or refusal to fix.

Things are not looking good, in case I've not made myself abundantly clear

One alternative is to use Linux boxes with Wifi cards. Some are relatively cheap and you then have software that is totally under your control. An example is Compulab's WILD (Wifi Indoor Location Device) https://fit-iot.com/web/ (I'd personally rather use Android, but the wifi scan limit prevents useful 802.11mc FTM RTT see http://people.csail.mit.edu/bkph/ftmrtt.shtml)

Yes, but there are entire enterprise / commercial applications built around this functionality in Android.  This change will impact some wireless survey processes and cripple some excellent wireless tools.

Sent from my iPhone

Perspective from a user of one of the apps that this new limitation will kill: Please put these throttling inside the normal battery optimizations that already exists for the user to be able to opt out of on a per app basis, and if we exclude the app from the battery optimizations, remove the throttling on the app.

I understand the wish to conserve battery life.  But if the user wants to use an app that hits battery life, it should be enough to show a warning.  Let the user decide if she wants to use a battery-unfriendly app.  The current policy is more like what the user could expect from Apple!

The throttling has impacted my application as well (the app simply doesn't work on Android Pie). It should be up to the user to decide- maybe enforcing a special type of permission could be an option where the user will be presented with a default message explaining the implications if he/she grants the app access to no wifi scan throttling. There are many ways how Google can do this to ensure that the user knows what s/he is agreeing to. By deprecating the method you are limiting us developers ( it makes me wonder  if  Android is the new iOS now ) to use this method where we actually need it

I am a developer working on an IoT product that relies on WiFi scanning during unboxing and setup to make initial contact with the unconfigured device.  The WiFi scanning restrictions introduced in Pie make the user experience during setup more unreliable and frustrating.  At the very least, it would be helpful (in this use case, anyway) for the OS to allow a few minutes of unrestricted scanning before the throttling kicks in.

I have a WiFi survey app that is fully functional and now just needs a website and some advertising and a launch. The adsense budget is frozen until further notice.

One of my hobbies is wardriving. My Nokia 6.1 is totally unusable for it.

delete

Comment

Remove

What's going on with these comments?
Still no official communication or decision on this issue?

Our oneplus devices just received the Pie update announcement. We can't install them because it breaks a main functionality.

Android users need to decide how frequently they want to scan, via a setting which offers the same scan rates as seen in A5/A6/A7. If we want more battery, we need to be informed within Android, about the tradeoff of battery life vs scan frequency. Reducing user control equates with many negative reactions.

This is the worst decision ever deprecating useful API and my work depend on this feature of Android. I'm going back to older versions !
And still no answer from they

I'm developer of this app too : https://play.google.com/store/apps/details?id=com.eakteam.networkmanager and to many tools depends on WiFi scanning. This app provides real-time data of WiFi and many network tools too and it takes me very much time to provide to Android users best network experience. Almost everything someone needs for network analyzing, testing and information gathering. And this decision is terrible.
We are waiting for official final decision what Google will do for this.
Sorry for my English

I m also a developer. Our app uses wifi scan identify the fake hotel checkins and No show cases.
This api is very much required and not to be deprecated.

I honestly can't believe, particularly after reading comment #37, that there is no response from Google after this much time. I'm a regular user of scanning tools and analyzers in my work, and am sitting here with a Pixel running Android 7 and 120+ days out of date on security patches simply because of this unwelcome change. Listed above, there are more than enough reasons this terrible idea needs to be reversed which hold a lot more clout than I do, but feel the need to add my voice to the "this is a terrible idea and absolutely needs to be reversed" crowd here.

And for Pete's sake, can we get an update? Anything?

Bad Updated. API 28 wifimanager.startscan()  is deprecated. very bad updated. It's a terrible thought.
Is it your head?

Comment #55, I appreciate that this is probably a bad translation but insulting Google is only a way to get this bug report locked forever.

Just summarizing points made so far.  This change breaks apps with two main purposes:

1. Scanning for diagnostic purposes (e.g. WiFi Analyzer)
2. Scanning for wardriving purposes (e.g. WiGLE)
3. Scanning for crude location purposes

Most developers are requesting a dynamic user authentication to authorize such limit bypassing.

Adding to the list in comment #56:

       4. Getting WiFi AP list needed for FTM RTT (802.11mc) ranging (android.net.wifi.rtt.WifiRttManager)

Note that indoor location finding was a major selling point for Android P as described in last year,s spring Google I.O meeting (https://www.mouser.com/blog/wi-fi-will-soon-provide-position-accuracy-of-one-meter)

Unfortunate.  There's an excellent internal positioning framework called FIND: https://www.internalpositioning.com/
It works by collecting RSSI of Wifi and BT devices, then using machine learning to determine internal position.  I use it for home automation and it works incredibly well.  I was working on an application that would run frequent wifi scans when the user is at home, as defined by a geofence.  Even as a foreground service, I'm now limited to 30 second intervals.  That's not useful for home automation that needs to understand as I leave one room and enter the next so my lights can turn on appropriately.

I don't think Google understands the myriad of use cases that people depend on this functionality for.

My favorite and purchased apps are beginning to die out on Pi systems...

No official response yet, but it looks like it might be fixed in Android Q.
https://www.androidpolice.com/2019/01/27/background-location-access-for-third-party-apps-might-return-in-android-q/

Google, you need to fix this regression bug!

Agreed, this new WIFI restriction needs to be changed.

Agreed

Hello, i use wifi analysis apps for my work when installing access points and those throttling limitations are now just making my life more difficult

There should be an option to disable throttling either on a per app basis or globally (maybe under developer settings?)

Also this breaks WiGLE and other similar apps (As mentioned above)

Also, deprecating WifiManager.startScan() would contradict approach we use for IOT described here: https://android-developers.googleblog.com/2016/07/connecting-your-app-to-wi-fi-device.html

This has impacted the functionality of our Wi-Fi application used by service providers' installation technicians. The reduced scanning capability for foreground apps has made it so android 9 users cannot effectively see Wi-Fi interference from neighboring wi-fi networks, nor continually scan for signal strength received from a specific network in real time (or near real time). This is core functionality of our application and impacts our value. We have starred the issue and hope google can find a compromise. Thanks

Indoor positioning by wi-fi fingerprint is impossible due to this limitation. Google says "you can use RTT" but AP providing RTT feature is not available almost every buildings.

It should be up to the device owner i.e. user to decided whether to restrict Wi-Fi scans or not. The OS should provide a setting or a permission for this that the user can toggle or agree to.

Hello. We are designing and developing indoor geolocation based solutions, mainly leveraging either Bluetooth or Wi-Fi signals. This Wi-Fi scan limitation, even for a foreground application, is preventing us from deploying on Android Pie. At the hardware level, the Wi-Fi RTT (Round-Trip Time) technology is currently only supported on a few mobiles, and even less routers. It will take several years for it to be deployed on a large scale. There is thus currently no true alternative to a regular Wi-Fi scan. Moreover, on Android, a Wi-Fi scan is a one shoot operation, performed on a passive basis, which lasts between 300 and 1600 ms on the average, depending on the range of supported frequencies (2,4 / 5 GHz). As a result, it does not impact that much battery consumption !

To put it in a nutshell, an end user should be given the opportunity to grant or not an application to perform "intensive" Wi-Fi scans. Thank you.

Has anyone tried the Android Q beta yet? does the new "FINE location" permission solve the issue?

In the first Beta of Android Q, nothing changes. But this is first release, things may change in following

For the moment they only change on how to activate WiFi if it is dissabled

Google, you need to pick up on this behaviour - do not break the apps like you are planning to do!

See also https://issuetracker.google.com/129248937 [Android Q Beta] Receipt of wifiscan generated by other apps is throttled (SCAN_RESULTS_AVAILABLE_ACTION)

I'm going to pile on here. This is a bad decision. I utilize several WiFi survey and analyzing applications that are seriously diminished by this change. I have always been an Android user because these applications were available and performed well on this platform. Well now google have made the decision that "saving battery", if that is infact the reason for all of this,  is more important that the needs of users.  It is my device, and my battery, it should be my choice. Please fix this mistake, and quit heading down the path of Apple.

To be honest, it's seems that they would do that not (only?) for the sake of battery saving, but make it harder for IOT apps / device makers to have a harder time with Android connectivity. I really hope it's not the case, but it's something to think about. This imposed limitations are really, really bad. Besides, it seems they're completely ignoring the community feedback - just look at the date of the last (and only?) response by a Google employee on this thread.

In the situation where an Android device is attached to a "vehicle / robot", has anyone tried connecting the device to a power source to see if Pi does not throttle? Because when the device is connected to a power source, the battery life should not be affected. Obviously, that's not a workaround for someone that is walking around with a device.

Tested and it still throttles when hooked up to a power supply.  Also the issue is blocked by issue (112825565 [Details unavailable.] ).  Any one know what it is?  When I try to look into it it tells me access denied.

This breaks my indoor navigation application...

When I first got into Android development it was because of the capabilities Android gave my users in comparison to iOS.
My users CHOOSE to use wifi scans to tell their location indoors.
And now you're not letting make this choice??? Why?
Why can my users not choose to do what they want to do?

This completely nullifies why anyone would choose Android.

We created a bug report for android Q as this issue is still present in Q. We still hope that the Android dev. team will fix this issue for Q final release. Please vote for it https://issuetracker.google.com/issues/129900566

It is really not clear what is the motivation for deprecating any kind of Wi-Fi scan in Android see [1].
It is also not clear how important is the concerns of app developers on this issue for the Android dev. team.
The answer of the Android developers is quite vague. However, for many of us, removing the possibility
to perform Wi-Fi scans is a show stopper.

One additional possibility would be to ask our users to vote for the issue so that it becomes top of the list.

Also, as a reminder, I created a mailing list android-scan-apps@inria.fr to discuss among us (app developers) such
issues and find the most appropriate solution. Currently only one app developer subscribed.


[1] https://developer.android.com/reference/android/net/wifi/WifiManager#startScan()

Is the mailing list (android-scan-apps@inria.fr) available to the public? If so, how can I sign up for it?

The list is private (that is, only members of the list can send messages), to subscribe to this list, just send a message to android-scan-apps-request@inria.fr

Please remove this limitation !!!!

Does google ever ask developers for their opinions on these types of restrictions?
The reasoning behind this restriction seems muddled,
Many great apps will be hurt by these restrictions.

Please think again google

Please remove the limitations. Dont tell us developers what apps we can make. These limitations are killing many apps.

It is very disappointing for users who have bought a phone which takes part in the Android One Program. We believed that the updates to newer versions of Android would be an andvantage that makes the phones working better. Now the opposite is the case!

I just got used to use some great apps that have to be supplied with constant WiFi information (tracking, scanning, mapping etc...). Also notifications arrive to late. The whole phone seems to be more clumsy and is no fun to use anymore. It worked all fine with 8.1.

Any updates, on the issue? From this thread https://issuetracker.google.com/issues/129248937 it looks like they fixed something at least. Can someone with Android Q confirm? It's a shame seeing Google on a dangerous path to becoming Apple...

for #88, the issue you refer to has no link this current issue. What say describe in https://issuetracker.google.com/issues/129248937 is that android Q is now allowing to refuse location in the background. For a developer not aware of that, it was difficult to debug when they make a wifi scan that does not return any AP. They just added additional log to find that a scan is refused in background because there is no permission.

Once again, thank you for submitting the feature request. After following up with our product and engineering teams, the feature 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

For those of us who spend a bit less time in this realm, does this mean
"won't fix in Android P" or "won't fix ever..."?

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

tbh it should not be called feature 'request' as an existing feature was removed without any logical reason. It is a feature 'demand' for many existing applications. This decision clearly shows: play-store is a dangerous and unsafe ecosystem you can't rely on and invest in.
I don't get the use-case for "local testing on rooted devices". Why test something, the product and engineers team denied to deliver as functionality to the users?

Disgusting, but at least a clear statement.

This is jaw-dropping intellectual rigidity.  I'm surprised and dismayed as
I've normally expected Google to provide the most functional solutions.
The ongoing user scan restriction is not a most functional solution.  I've
been greatly inconvenienced as have many others.  Having to walk around
with a Windows laptop instead of my smartphone to do site surveys is very
clunky.  This is just crazy and causes me to wonder what else is possibly
wrong within Android.  A loss of confidence.

On Fri, May 24, 2019 at 3:09 AM <buganizer-system@google.com> wrote:

Except for the insecure suggestion of rooting to get around the limitation, I thought the no rationale response was very Apple like.  I started using Android to get away from these kind of arbitrary deprecation of capabilities that break useful functional utility apps with no explanation.

Tell frankly. Do you even believe "Throttling wifi scan is for battery saving", google?

Why are you throttling wifi scan? Why are you blocking hardware functionality without choice for third-party and end-user? Why are you using not-throttled data only for google and hardware venders?

At least we want to know a reason. Do not tell annoying lie.

Throttling foreground wifi scanning is NUTS.
I used it a lot when setting up wifi networks. It's the intended behavior of the app!
I downgraded my S8 to OREO for now.

I cannot understand this. My old S4 is now superior to any S10 / P30 and so on for wifi debugging/optimization.

Would you please tell us what makes you not giving us a developer option in Android 9 to remove this limitation?

Why to completely restrict it? Many people use software which implements this functionality. Scanners, navigators, monitoring could be done by smartphone, but now couldn't. I used to use my self-developed app which is not in Play Store even. And it's broken now. Have to use laptop with Windows for my purposes. Thank you. Why don't make an option to allow scans?? I am the user, I decide what functionality to use.

Maybe ban games? They consume battery in foreground too.

And why apps by Google are not restricted? (don't answer, I know why)

This is not a good resolution. Google has acknowledged that this data is valuable and now understands that it causes damage to companies that rely on it. Being that Google apps are accessing the data while restricting others, I think there may be a case to be made that this policy is Monopolistic behavior. Without clear reasoning to explain the security threat for scanning in foreground, it is hard to rule out market manipulation as a motivator.

I've promoted Android for years as an open and fair platform and news like this is very disappointing.

This is a very heavy handed change that breaks many of the apps I depend on to do my job.  I really resent this change and it makes me resent Google.

Disappointing that android "The open platform" makes something as basic as wifi scanning limited... It should be up to users & developers on how to use the capabilities of their devices & apps... NOT Google

"Being that Google apps are accessing the data while restricting others, I think there may be a case to be made that this policy is Monopolistic behavior."
This is what I was thinking as well, it's a joke to not implement a permission for the user to decide on battery and privacy concerns weighed up against the functionality of the application.
It's not a logical or intelligent decision being made to Android here.

It's very easy to conclude there is some anti competitive motivation behind it.

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

Thank you oh great lord Cthulhu :-) that's wonderful news.
An real permission would have been better, but still :-) I am plentiful pleased…

Thanks @Google  - a dev option is a start but why now a user accepting permission.

For me, this restriction has completely destroyed my app & my idea that i've been working on over the last year on (for no money & all in my own time in the evenings/weekends) . i was working on tool that uses wifi scans to maps out wifi density in a geographical area (think campuses) to overlay into Google Earth so you can make informed decisions about your coverage.

I'll be honest - hearing about the removal of this feature crushed me personally as I'm not a large business or indeed that important in the grand picture of Google plan as i'm only a solo developer that develops for fun & my app was something that I have loved working on but by removing this API has now nullified months of my development effort and shot a massive hole in my ambitions for the app.

I don't know where to take it from here - i'll have a think over the coming weeks; maybe restrict people with android >O from using the app?!? I can't believe restricting newer phones from installing your could now become 'a thing' &  never in a million years thought a feature could be removed from the Android API so I'm now seriously concerned about what other API features @Google could pull in the future releases of Android & what to invest my development time in; Could GPS recording/Ble Scanning/Telephony access all be pulled in the future releases as well? Should I be confident that what APIs we developers invest in today may not be removed tomorrow.

I not a 'hater'; I love android, love the API and get excited to ge to listen to all the Google IO talks around what new in Android but this really scares me of what precedent has now been set for what I once believed was a open & inclusive ecosystem.  

Also - the massive kicker to all this is the 'Google' signed apps (gmail/maps/calendar/hangouts) can all still use wifi scanning on tap but everyone else can't.

At least our voice reached to google.
Not best, but very pleased.

On comment #103, is there any official announcement somewhere on this?

On Wed, May 29, 2019 at 11:20 AM <buganizer-system@google.com> wrote:

Hi to all,

Anyone know if AT LEAST we could get some information in Q and after when we issue a "WifiManager.getScanResults()".  I'm hopping we could get the last system scan results, even if it's not in real time.  They didn't include this command on the deprecated list, but now... who knows!!  

We're investing in a new App that relies on WiFi scanning and we talked to our customers about how good was to use Android instead of iOS... and now guess what, we end up with the same kind of limitations as Apple in future releases.  Sad to hear this new "ways" on Android.

Best regards to all the affected with such decisions.

N

About #103... adding a developer option DOES NOT fix the big problem. It's "ok" for developers, but what about end-users? As many have said, it's really, really hard not see an anti-competitive motivation behind this terrible decision. Someone working on the IOT field shouldn't ask users to user developer options, that's bad in many levels.

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

It is really not clear to me what is the intent of #90 and #103. This issue is not about developers that need to make tests, it is about real users that cannot use apps relying of Wi-Fi scanning anymore. Real users must not have to root a device or enter a developer option. Are #90 and #103 what you consider as a definitive work around, is it a step toward adding a new permission to relax the foreground scan limitation as all devs are asking for (but I don't see why we need a developer option for that anyway).

Does anybody presented a use case for a developer option or an adb command? I am not aware of any reasonable use case.

It would be really helpful and a relief for all developers to clearly communicate what is your plan and timeline on
- adding a permission to perform unconstrained foreground Wi-Fi scans
- keeping the wifi scan API in future releases

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

@ad... toogle.com

Your second mentioning does not mention the "will work on rooted devices only"
Can you clarify what this exactly does mean?

R.E. #105

Are we sure that Google apps are excluded from this restriction?  I'm pretty sure they are as bound to it as anyone else, just Google doesn't have any apps which need to do any Wi-Fi scanning (besides system apps, which are obviously excluded).

R.E. #112

Obviously I can't speak on behalf of Google, but this appears to be a new developer option that *does not* require rooted access.  This is an extremely recent announcement from Google.

> Google doesn't have any apps which need to do any Wi-Fi scanning

Location services. They build network coverage maps. It is in their best interest to prevent potential competition, like Mozilla Stumbler and Wigle.

A new developer option to toggle scan throttling off without having to root the device would be a very welcome option.

>Location services. They build network coverage maps. It is in their best interest to prevent potential competition, like Mozilla Stumbler and Wigle.

Location services are a system service, thus are excluded.

I have used this functionality professionally for an entire decade.

Thanks for taking away one of my more valuable tools, Google.

Regarding comment #108 :

The API will return the most current scan results - whether issued by your app, other apps, or the system itself. Additional, the broadcast which notifies of new scan results will always be updated whenever scan results are available from any such source.

It's pretty heartbreaking watching our previously highly-rated app drop in the Play Store standings, as people award us a steady stream of one-stars because we can't scan at a reasonable rate anymore since Pie. Users don't care about the reasons behind it; they blame us. It will be very hard to convince them to activate a developer option, and people will still knock us down because we don't behave as expected "out of the box."

In the meantime, this easy solution provides a scan every 10 seconds in the A. Sid WiFi Analyzer app on my own Android Pie OnePlus 6T phone.  I used it for an hour yesterday.  What a breath of fresh air.  Finally can do WiFi surveys.  We shouldn't have to do this.

https://issuetracker.google.com/issues/79906367#comment69
"pg...@gmail.com  <pg...@gmail.com>  #69 Jun 1, 2019 12:40PM
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."

Getting average users to do this is roughly as unlikely as enabling a developer setting - in fact, I'd bet they're more likely to say "your app sucks."

#118 So, am I correctly understand?
- If app turns on fine location (with wifi scan enabled by user), we can get latest(and fastest) scan result with getter API when we get broadcast.
- App cannot trigger starting scan without restriction. but you can gel global(device-wise) last result with simple API.

If so, we don't need to trigger scanning. Because scanning is controlled by OS, list is maintained by OS, we can get latest list without any restriction or battery concerning.
Scanning speed? I'm not worry about that. I know android system location uses continous wifi scanning. I don't know there is governor or not, but I saw android uses wifi scanning result very fast(under 4 seconds).

I think it is good solution. thanks google(if I'm not wrong)

And I have one question. is there a way or patch to avoid throttling scanning at android P? regarding #118, we can use that in androud Q and after.

Just food for thought..... I work in a 911 center and it was discussed that hotspots within a building can be relayed to our screens showing where in a building (like a large office building) the phone last pinged on. I believe this technology will use combined gps from cellular and wifi connections to narrow down where in the building a person actually needs help (copy machine room). With the infrequency of scans this could have a negative impact on locating someone who cannot speak , remaining quiet or unconscious. the intended purpose may not work as well as planned in that case. Perhaps turn it on by default with an option of off which could be less safe. This goes back to the root of gps for 911 calls, originally on tower hits (2500 meter confidence factor) (911 phase 1) eventually to with a few meters of accuracy (911 Phase 2)  when seconds count.  This is another example of going backwards for battery life. As more and more places obtain this technology within large buildings or floor designs,  by time we get the info it could be old location even on a re-ping with an active caller if it didn't scan new wifis nearby.

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:31 AM <buganizer-system@google.com> wrote:

So has anyone figured out a reasonable alternative (such as an alternative API) so the app can work out of the box w/o having the end user doing something? The last thing I want to do is ask the end user to root their phone, or do some weird workaround such as the split screen solution.

Looked into WifiRttManager, and that looked promising until I saw that the access points must support the 802.11mc standard so that's basically useless.

The user choice opt-in toggle has to end up in the final version of Android Q and beyond. Otherwise this may very well end up in current or next anti trust cases in the US or Europe.

Google forcing privacy settings or battery use to users, thus limiting users rights to have control over their own data, privacy and device use, is not the road to follow.

Since Google is forcing very restricting limitations on both users and many independent App developers to use wifi scanning data (with the concent of the users to use scanning data), Google is limiting users and developer business. Also Google is apparently not limiting it's own limitations to use wifi data for Google location services. Or at least Google is not transparant regarding it's own use of wifi scan data regarding to privacy versus the limitations forced to users and developers.

Google is not in the best position to force limitations to users regarding their privacy or device use. Google is not in the best position to make choices for users regarding the use of their data or use of the device.

If Google has a problem with users making choices regarding their privacy, if Google has a problem with users giving consent to developers to use the sensors or data retrieved from sensors like wifi hardware that may affect the users privacy or users device, then Google should address that with users, not regardless of users.
If Google has a problem with the limitations of the  design of Android regarding the impact of privacy settings, then Google should address the design, instead of focusing on forced limited workarounds.

The problem is not that scanning can affect the privacy of users, the problem is lack of control by users over their privacy.
The problem is not that scanning can affect battery performance, the problem is lack of control by users over battery performance.
The opt-in toggle is not an option, it is a must have.

Fraud

Hello All,

Does anyone know if this issue will be addressed by the upcoming "always" location permission (ACCESS_BACKGROUND_LOCATION)? If an app is granted this permission, will the scans be unrestricted as before 9.0?

To compare, IOS does not restrict location once given "always permission". If Google does the same, then they would be moving in the right direction, otherwise they would be crippling a slew of applications and even companies and industries not to mention actual users.

Once the user is informed clearly about the working principles and the intention of the app, it should be up to the user to grant these permissions. If it's a network app or a location sharing app, the user will know the benefit and the purpose of the app.

Google's intentional crippling not only hurts developers but actual app users as well in the sense that they will not be getting the full benefits of the app intended for them.

I think this is a serious issue that needs to be addressed in the full Q release.

What about Andoid Pie? I dont think my P10 will ever get the Q-android..
So.. Am I stuck to throttled pie?

All, as this issue is marked as won't fix for Android 10, I opened a new issue here https://issuetracker.google.com/issues/140447183

Please, star it, follow it, contribute use cases. Keep in mind that startScan is still marked as deprecated and it might just be discontinued in the next Android release, which no more Wi-Fi scan.

I updated my Huawei mate 20 pro to android 10 to can remove Wifi scan throttling but I didn't find this option in the developers options
as reported here https://developer.android.com/guide/topics/connectivity/wifi-scan 
This option will not included in android 10 also or what is the situation now.

Thanks

I have the option on my OnePlus 6T with A10. That is odd you don't. Highly unlikely to ever be fixed on Pie.

Agree with #132. I have it as an option on my recently updated Android 10.

For anyone interested ;) I know Android 9 is essentially dead but I am still building for my specific device. This change to the source essentially neuters the scan throttling. So sad how it requires a full build to manipulate one var....
https://github.com/Geofferey/android_frameworks_opt_net_wifi/commit/ef2b928183902a889d84bffdde1dec3ee58bb2e6

Huawei has customized version of the developer settings and it seems that
they have left out this important option. As a work around, you can run the
following command to disable WiFi throttling also in Huawei devices:
 adb shell settings put global wifi_scan_throttle_enabled 0

Verified with Huawei Mate 20 Pro.

On Fri, 13 Dec 2019, 10:07 , <buganizer-system@google.com> wrote:

My team developing an application that requires frequent wifi scanning. This update is become a great issue.  

my company is developing a home automation app.
a new device creates an access point that the phone needs to connect to during the initial setup.
we need the scan functionality to be able to do that.

This kind of deprecation for "startscan()" API limits many of the location-based services in indoor environments because most of them rely on frequent Wi-Fi scanning every 5 seconds.
Please, this kind of limitation is very harsh and needs to be fixed or replaced by an alternative solution.
We hope that the Google team takes this issue in their consideration and gives the solution in future Android releases ASAP.

My thesis requires the startScan() API for Data collection. This deprecation is a big block in its completion.

You'll just have to provide proof for your thesis with android 8. That's exactly what i did for my thesis. It's a real shame Google removed this. They are moving on to RTT based approach... Except most routers don't yet support this.

Comment above is correct, if anyone needs this functionality, you'll have to tell your user to enable developer options and disable this setting. I believe there also seems to be a workaround on android 9 where if you have a phone which allows splitscreen or popup window, if you open the WiFi settings and your app, your app will actually be able to request more than 4 scans in 2 minutes. I can't confirm this though.

Status: Won't Fix (Intended behavior), This status get me really angry, just because it's what google intends doesn't make it correct.

Well, here we are, the moment where a developer says "I'll never work on Android development again."
It's been real, Google.

Welcome to the darkside. We've spent 16 million USD in the last 2FY just to get around this single decision. We aren't happy at all. Apple all the way here now.

I'm out, too.  Pinephone all the way now.

Google is a top tech company and make this kind of decision... Unbelievable

@Google Why can this not be an option that the user can enable?  This cripples my company's idea to determine indoor positioning for emergency activations using android watches (we were going to exclusively recommend our clients purchase your watches for this... not anymore, obviously).

I do not at all understand the reasoning behind this decision. The workarounds aren't even workarounds, I don't see what the point is in allowing the throttling to be turned off via an ADB command.
Why can this not be a permission that the user is prompted for? "This app needs to conduct frequent wifi scans which may affect battery life: Approve or Deny".  It should be that simple.  Now I have to look at possibly building a custom kernel, then loading this up on android devices and reselling them.  This really isn't an option though as we are a small company... the app could be finished in a week if we could simply scan for bssids every 2-3 seconds (which is possible, but restricted, because of ???)

If anyone else has been or is working on custom kernel for this, please reach out to me at wesley.hendon@911cellular.com and I can offer any assistance you need to get this going.

For those wanting a workaround:
There is a new developer option to toggle the throttling off for local testing (under Developer Options > Networking > Wi-Fi scan throttling).

Super.  Just tried it with "WiFi Analyzer".  Works great.  When the
app starts, there's an immediate notification about this new Developer
Options workaround.  Was previously using a split screen trick for the
workaround.  Useful app finally works like it once did before the
throttling was implemented in Android.

On Fri, Apr 8, 2022 at 7:16 AM <buganizer-system@google.com> wrote: