mirror of
https://github.com/seemoo-lab/AirGuard.git
synced 2026-04-25 15:35:49 +03:00
[GH-ISSUE #19] Question regarding the low power scan option #15
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/AirGuard#15
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @aforemendude on GitHub (Dec 23, 2021).
Original GitHub issue: https://github.com/seemoo-lab/AirGuard/issues/19
Hi,
I have a question regarding the low power scan option if you don't mind me asking.
Recently, the label text for the option was changed from
If enabled bluetooth low power scan will be used to discover nearby AirTags!<b>WARNING</b>: This could cause that some devices won\'t be discovered!toIf enabled, Bluetooth Low Energy scanning will be used to discover nearby AirTags!<b>WARNING</b>: Without this option, some devices might not be discovered!.However, according to the code, Bluetooth Low Energy is used regardless of this option, and the low power scanning mode is used when this option is enabled.
github.com/seemoo-lab/AirGuard@4a29baeb96/app/src/main/java/de/seemoo/at_tracking_detection/detection/ScanBluetoothWorker.kt (L7)github.com/seemoo-lab/AirGuard@4a29baeb96/app/src/main/java/de/seemoo/at_tracking_detection/detection/ScanBluetoothWorker.kt (L154-L161)So, it seems to me that the label should say
If enabled, low power scanning mode will be used to discover nearby AirTags! <b>WARNING</b>: When this option is enabled, some devices might not be discovered!. Can someone please confirm if this is correct? Also, please let me know if you want me to open a PR to make the change.@musm commented on GitHub (Jan 26, 2022):
The wording is certainly confusing on what the option does. Looking for documentation lead me to this issue. Interested in hearing feedback on it.
@DrMaxNix commented on GitHub (Jan 30, 2022):
The Android docs only say that
SCAN_MODE_LOW_POWER"consumes the least power", not that useful.But I found this in the docs of NordicSemiconductor/Android-Scanner-Compat-Library: "A Bluetooth LE device should advertise very often (at least once per 100 ms) in order to be found with this mode, otherwise the scanning interval may miss some or even all advertising events."
So it seems like when using
SCAN_MODE_LOW_POWERyou will find less devices..@Sn0wfreezeDev commented on GitHub (Jan 31, 2022):
We did some measurements using the different scan modes and different scan durations. The low power scan mode clearly misses some devices, even though it will scan for a longer time.
The reason is that the scanning cycles will occur less often in Android. Nevertheless, if you have a tracker on you and only every 3rd scan will find it, the app will still be able to notify you after about 2 hours.
@DrMaxNix commented on GitHub (Jan 31, 2022):
Alright, but then the descriptive text of the settings option is very missleading and should probably be changed..
@lenhart commented on GitHub (Feb 21, 2022):
Hi, I was confused by this option as well (I was about to open an issue that this option was not enabled by default because i read it in a way that scanning won't function at all otherwise).
update: my suggestion to add/modify the thread openers suggestion would be:
Warning: With this option, some devices might be detected later _(up to approx. 2 hours)_ or not at all. This option will reduce energy consumption."@Sn0wfreezeDev is the ~2 hours something that should be included as information in the description? (or rather: did you measure that or is this more of a gut feeling?)
Cheers!
@DrMaxNix commented on GitHub (Feb 21, 2022):
In both cases Bluetooth LowEnergy is used.. It just changes the poll interval for devices to be discovered.
Also I have a PR open (PR #39) for fixing typos for 23 days which hasn't been merged yet..
@lenhart commented on GitHub (Feb 21, 2022):
Hi @DrMaxNix: oh, too much skipping between open browser tabs, sorry about that confusion, should have read the opening post again. I will edit my previous post and propose that if the 2 hour mark can be something of a guidance, that it could be included in the fix @aforemendude proposed initially :-)
Cheers!
@Sn0wfreezeDev commented on GitHub (Feb 21, 2022):
@DrMaxNix we try to align pull-requests with our feature releases. So we are currently working on an enhanced device detection and we will add the pull requests in this release 😊
@DrMaxNix commented on GitHub (Mar 10, 2022):
To bring some progress into this issue I will sum up the ideas we had so far.
Please tell me if you think my suggestion should be changed in some way or if it's ready for a PR!
Current text (as of v1.2)
@aforemendude
@lenhart
My suggestion to combine all of those ideas