Status Update
Comments
ar...@gmail.com <ar...@gmail.com> #2
For clarity, are you requesting this as a developer or as a user?
ad...@google.com <ad...@google.com> #3
as a developer. i looked into wake locks but it's not quite what im after. im going to look into media projection next but im not sure thats quite it either
i tried system_alert_window and it didnt seem to work
my project is unity based and has a dependency of another sdk that has lots of stuff going on
im going to try a reduced test case to eliminate extra variables
i found this dex mode manifest meta data attribute. so maybe that's a clue
will report back
bo...@gmail.com <bo...@gmail.com> #4
Could you please confirm if the issue is also observed with pixel devices?
hi...@gmail.com <hi...@gmail.com> #5
i don't have a pixel device to test on, only a samsung device. is this a pixel-specific issue tracker?
i guess what i'm wondering about is some kind of "projector" api where the phone can act as a projector, and an app can keep playing on an external (displayport) monitor, while the primary device (be it phone or tablet) is locked
mi...@vonglasow.com <mi...@vonglasow.com> #6
We have shared this with our product and engineering team and will update this issue with more information as it becomes available.
ar...@gmail.com <ar...@gmail.com> #7
any updates on this?
ky...@gmail.com <ky...@gmail.com> #8
could 2024 be the year? :D
ry...@gmail.com <ry...@gmail.com> #9
bump
[Deleted User] <[Deleted User]> #10
There are some specifically interesting uses for fine grained radio monitoring. It's not all evil hacks.
gu...@gmail.com <gu...@gmail.com> #11
First: if you really want to safe battery at this level of logic then why not also limit users to take max 4 pics in two minutes or use the flash light only for 4 seconds. Hey why not limit speaking time for phone calls - he? This would be way more effective in both saving battery power AND let people understand the arbitrary power of Google/Alpha.
Secondly, what about education? Most people don't understand much about wireless signals and radiation. You can't hear, smell, feel or see it. In many cases this creates a strange feeling about the dangers and effects on the human body. There are special devices and solutions to visualize the signal and the strength, but they are quite expensive. And there are Android devices along with some intelligent and often used apps that allow a lot of people to show, learn and explain these signals. Now Google behaves like the medieval church and tries to hide this information for ordinary and especially poor people by taking a big step to turn Android devices into another white, expensive brick with printed fruit logo.
Third: if I - user and owner of my own device - want to use the battery power for something that complies with EVERY law, has no disadvantages for another living being and does not affect any other technical device, then this should remain possible from a purely logical point of view.
(not sure if I was able to cover up my anger.)
an...@gmail.com <an...@gmail.com> #12
This tool has been absolutely indispensable in setting up and maintaining wifi networks both for work and personal use, and I'd very sad to see it go. Beautiful and extremely easy-to-read visualizations.
de...@gmail.com <de...@gmail.com> #13
please remove this limitation.
sz...@gmail.com <sz...@gmail.com> #14
ho...@gmail.com <ho...@gmail.com> #15
ar...@gmail.com <ar...@gmail.com> #16
I propose as a first step a simple mailing list android-scan-apps@inria.fr
We can then discuss in this list other options.
ot...@gmail.com <ot...@gmail.com> #17
This is similar to background tracking and processing capabilities which are now mostly reserved to Google's own applications. The idea is to gradually tranform Android into a closed platform like iOS, where the ability of the app developers to use the full capabilities of the devices for the benefit of the end-users is crippled by the platform vendor for arbitrary reasons.
gu...@gmail.com <gu...@gmail.com> #18
Regarding the "unlikely that they will revise this decision"
The official statement is about battery saving.
And their message from 8 days ago in this issue tread is "We have passed this to the development team and will update this issue with more information as it becomes available."
Of course, it will take some time until they considered and discussed feedback and options internally, but we still should hope the best.
gu...@gmail.com <gu...@gmail.com> #19
Fortunately, they had left the idea in Oreo images. Not sure if their goal was also to safe battery or (I guess) to simulate fast scanresults by running an uncontrollable background scanning process.
Effectively all known Wifi-Scanner-Type apps had weird results. For example extremely fast scanresults (within ms) but always the same values for all (B)SSIDs. Then after some seconds, there was a fresh result from the background process and the faking imagination of getting new values continued.
gu...@gmail.com <gu...@gmail.com> #20
This is not caused by the artificial Pie limits and looks more like an attempt to speed up scanning by skipping "too much" BSSIDs.
However a new dedicated permission for wifi surveys and optimization could include and foresee a more precise scanresult behaviour than in normal users mode. This is what I would call progress and improvement.
jo...@jgstechnical.com <jo...@jgstechnical.com> #21
*
ne...@gmail.com <ne...@gmail.com> #22
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.
vi...@gmail.com <vi...@gmail.com> #23
ma...@gmail.com <ma...@gmail.com> #24
iz...@gmail.com <iz...@gmail.com> #25
ad...@gmail.com <ad...@gmail.com> #26
ji...@gmail.com <ji...@gmail.com> #27
sm...@gmail.com <sm...@gmail.com> #28
The right intentions but the wrong execution of this change, please keep the old behaviour when the application is in the foreground
fr...@gtempaccount.com <fr...@gtempaccount.com> #29
gu...@gmail.com <gu...@gmail.com> #30
ar...@gmail.com <ar...@gmail.com> #31
bk...@gmail.com <bk...@gmail.com> #32
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.
be...@outlook.com <be...@outlook.com> #33
jo...@gmail.com <jo...@gmail.com> #34
rc...@gmail.com <rc...@gmail.com> #35
ma...@gmail.com <ma...@gmail.com> #36
Apologies in advance to anyone who has been pinged by this message.
go...@gmail.com <go...@gmail.com> #37
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
bk...@gmail.com <bk...@gmail.com> #38
nl...@gmail.com <nl...@gmail.com> #39
Sent from my iPhone
je...@gmail.com <je...@gmail.com> #40
mt...@gmail.com <mt...@gmail.com> #41
ha...@gmail.com <ha...@gmail.com> #42
pa...@gmail.com <pa...@gmail.com> #43
gu...@gmail.com <gu...@gmail.com> #44
tu...@gmail.com <tu...@gmail.com> #45
[Deleted User] <[Deleted User]> #46
ha...@gmail.com <ha...@gmail.com> #47
ha...@gmail.com <ha...@gmail.com> #48
gu...@gmail.com <gu...@gmail.com> #49
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.
mm...@gmail.com <mm...@gmail.com> #50
em...@gmail.com <em...@gmail.com> #51
And still no answer from they
em...@gmail.com <em...@gmail.com> #52
We are waiting for official final decision what Google will do for this.
Sorry for my English
ma...@oyorooms.com <ma...@oyorooms.com> #53
This api is very much required and not to be deprecated.
tp...@gmail.com <tp...@gmail.com> #54
And for Pete's sake, can we get an update? Anything?
[Deleted User] <[Deleted User]> #55
Is it your head?
ma...@gmail.com <ma...@gmail.com> #56
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.
bk...@gmail.com <bk...@gmail.com> #57
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 (
go...@gmail.com <go...@gmail.com> #58
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.
gu...@gmail.com <gu...@gmail.com> #59
lu...@protonmail.com <lu...@protonmail.com> #61
er...@yahoo.com <er...@yahoo.com> #62
s....@gmail.com <s....@gmail.com> #63
ch...@gmail.com <ch...@gmail.com> #64
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)
ma...@gmail.com <ma...@gmail.com> #66
pi...@gmail.com <pi...@gmail.com> #67
sa...@gmail.com <sa...@gmail.com> #68
te...@gmail.com <te...@gmail.com> #69
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.
wi...@gmail.com <wi...@gmail.com> #70
em...@gmail.com <em...@gmail.com> #71
em...@gmail.com <em...@gmail.com> #72
je...@gmail.com <je...@gmail.com> #73
bk...@gmail.com <bk...@gmail.com> #74
co...@gmail.com <co...@gmail.com> #75
fr...@gtempaccount.com <fr...@gtempaccount.com> #76
ab...@gmail.com <ab...@gmail.com> #77
no...@gmail.com <no...@gmail.com> #78
li...@gmail.com <li...@gmail.com> #79
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.
ar...@gmail.com <ar...@gmail.com> #80
ar...@gmail.com <ar...@gmail.com> #81
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]
mi...@vonglasow.com <mi...@vonglasow.com> #82
ar...@gmail.com <ar...@gmail.com> #83
ge...@gmail.com <ge...@gmail.com> #84
da...@gmail.com <da...@gmail.com> #85
The reasoning behind this restriction seems muddled,
Many great apps will be hurt by these restrictions.
Please think again google
ju...@gmail.com <ju...@gmail.com> #86
f....@gmail.com <f....@gmail.com> #87
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.
al...@gmail.com <al...@gmail.com> #88
el...@gmail.com <el...@gmail.com> #89
ad...@google.com <ad...@google.com> #90
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
ma...@gmail.com <ma...@gmail.com> #91
"won't fix in Android P" or "won't fix ever..."?
On Fri, May 24, 2019, 5:09 AM <buganizer-system@google.com> wrote:
gu...@gmail.com <gu...@gmail.com> #92
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.
ar...@gmail.com <ar...@gmail.com> #93
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:
ma...@gmail.com <ma...@gmail.com> #94
pi...@gmail.com <pi...@gmail.com> #95
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.
lt...@gmail.com <lt...@gmail.com> #96
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.
de...@gmail.com <de...@gmail.com> #97
Would you please tell us what makes you not giving us a developer option in Android 9 to remove this limitation?
mr...@gmail.com <mr...@gmail.com> #98
Maybe ban games? They consume battery in foreground too.
And why apps by Google are not restricted? (don't answer, I know why)
be...@gmail.com <be...@gmail.com> #99
I've promoted Android for years as an open and fair platform and news like this is very disappointing.
sa...@gmail.com <sa...@gmail.com> #100
al...@gmail.com <al...@gmail.com> #101
li...@gmail.com <li...@gmail.com> #102
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.
ad...@google.com <ad...@google.com> #103
wi...@gmail.com <wi...@gmail.com> #104
An real permission would have been better, but still :-) I am plentiful pleased…
ke...@gmail.com <ke...@gmail.com> #105
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.
pi...@gmail.com <pi...@gmail.com> #106
Not best, but very pleased.
sa...@gmail.com <sa...@gmail.com> #107
On Wed, May 29, 2019 at 11:20 AM <buganizer-system@google.com> wrote:
ne...@gmail.com <ne...@gmail.com> #108
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
fr...@gtempaccount.com <fr...@gtempaccount.com> #109
bo...@gmail.com <bo...@gmail.com> #110
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.
ar...@gmail.com <ar...@gmail.com> #111
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
gu...@gmail.com <gu...@gmail.com> #112
@ad...
Your second mentioning does not mention the "will work on rooted devices only"
Can you clarify what this exactly does mean?
ma...@gmail.com <ma...@gmail.com> #113
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.
ca...@campus.fct.unl.pt <ca...@campus.fct.unl.pt> #114
Location services. They build network coverage maps. It is in their best interest to prevent potential competition, like Mozilla Stumbler and Wigle.
ma...@gmail.com <ma...@gmail.com> #115
ma...@gmail.com <ma...@gmail.com> #116
Location services are a system service, thus are excluded.
ad...@findlaypc.com <ad...@findlaypc.com> #117
Thanks for taking away one of my more valuable tools, Google.
ad...@google.com <ad...@google.com> #118
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.
an...@gmail.com <an...@gmail.com> #119
ar...@gmail.com <ar...@gmail.com> #120
"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
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."
an...@gmail.com <an...@gmail.com> #121
pi...@gmail.com <pi...@gmail.com> #122
- 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.
dj...@gmail.com <dj...@gmail.com> #123
sh...@gmail.com <sh...@gmail.com> #124
ar...@gmail.com <ar...@gmail.com> #125
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:
su...@scorbitz.com <su...@scorbitz.com> #126
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.
ne...@gmail.com <ne...@gmail.com> #127
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.
ar...@gmail.com <ar...@gmail.com> #128
fo...@gmail.com <fo...@gmail.com> #129
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.
kp...@gmail.com <kp...@gmail.com> #130
So.. Am I stuck to throttled pie?
el...@gmail.com <el...@gmail.com> #131
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.
mn...@gmail.com <mn...@gmail.com> #132
as reported here
This option will not included in android 10 also or what is the situation now.
Thanks
fl...@gmail.com <fl...@gmail.com> #133
ht...@gmail.com <ht...@gmail.com> #134
ge...@gmail.com <ge...@gmail.com> #135
hi...@gmail.com <hi...@gmail.com> #136
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:
da...@gmail.com <da...@gmail.com> #137
in...@gmail.com <in...@gmail.com> #138
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.
mo...@gmail.com <mo...@gmail.com> #139
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.
jo...@gmail.com <jo...@gmail.com> #140
bl...@gmail.com <bl...@gmail.com> #141
mi...@vonglasow.com <mi...@vonglasow.com> #142
On Android 10, you can get the same results by enabling Developer Options and disabling Wi-Fi scan throttling, or by changing this setting over ADB: adb shell settings put global wifi_scan_throttle_enabled 0
. As far as I know, that setting was introduced in Android 10 and not backported to 9. Haven’t tried that myself, though, as I skipped Android 9 for precisely this reason.
bl...@gmail.com <bl...@gmail.com> #143
[Deleted User] <[Deleted User]> #144
am...@gmail.com <am...@gmail.com> #145
It's been real, Google.
go...@gmail.com <go...@gmail.com> #146
vi...@gmail.com <vi...@gmail.com> #147
f....@gmail.com <f....@gmail.com> #148
we...@911cellular.com <we...@911cellular.com> #149
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.
ca...@gmail.com <ca...@gmail.com> #150
There is a new developer option to toggle the throttling off for local testing (under Developer Options > Networking > Wi-Fi scan throttling).
ar...@gmail.com <ar...@gmail.com> #151
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:
Description
Android Pie introduced two features that limits the functioning of our app ElectroSmart (
1. Throttling of `Wifimanager.startScan()` in foreground to four scans in 2-minute period
2. Deprecation of `Wifimanager.startScan()`
ElectroSmart is an app that shows the evolution of different signals (Wi-Fi, 2G, 3G, 4G and Bluetooth) in realtime (updates the results every 5 seconds) when the app is run in foreground. It uses curves to represent this graphically. As such, the users of ElectroSmart who use the app in foreground expect the results to be updated in that frequency. Now with the new restrictions of Android Pie, the results shown to the user static after the four scans in 2-minute period are exhausted in the first 20 seconds of the use of the app. This makes the application a whole lot less useful.
Secondly, Android Pie's WifiManager API marks the `startScan()` method as deprecated and without this method applications such as ours will not function as intended. I've tested out the new WifiRttManager API (
While we agree to the scan limit for the app in background, we think that the limit on wifi scans when the app is in foreground is a bit too harsh and should be something that is manageable by the user.
Hence, via this report we would like to request you to consider relaxing the restrictions and/or allow the end user control this.
We are aware of similar requests by other developers here:
Thank you.