Read location providers according to the permission actually granted - #990
Open
Madroid2 wants to merge 1 commit into
Open
Read location providers according to the permission actually granted#990Madroid2 wants to merge 1 commit into
Madroid2 wants to merge 1 commit into
Conversation
LastKnownLocationInfoManager gated both providers behind a single check that passed when either ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION was granted, then read GPS_PROVIDER and NETWORK_PROVIDER inside one try block. GPS_PROVIDER requires precise location. Since Android 12 a user can grant approximate location on its own, and that is the common case -- the runtime dialog offers it as a first-class choice. In that state the GPS read throws SecurityException, which unwinds to the shared catch before NETWORK_PROVIDER is ever reached, so the SDK ends up with no location at all rather than the coarse fix the user did consent to. The only trace is a log line blaming an "android firmware bug", which sends anyone debugging it in the wrong direction. Each provider is now asked for separately and only when the permission it actually needs is held: GPS_PROVIDER for precise, NETWORK_PROVIDER for either grant. The read itself is isolated per provider, so a refusal or a provider missing on the device no longer prevents the other from being consulted -- IllegalArgumentException is handled for that second case, which the previous code did not cover at all. The selection logic that prefers GPS and falls back to the network fix via isBetterLocation is unchanged. Covers the new behaviour in LastKnownLocationInfoManagerTest: coarse-only never asks for GPS, a refused GPS read still yields the network location, and no grant reads no provider. Partially addresses prebid#956 (location permissions). The deprecated display metrics and network connection APIs named in that issue are handled separately.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Change Log with reasoning:
LastKnownLocationInfoManager gated both providers behind a single check that passed when either ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION was granted, then read GPS_PROVIDER and NETWORK_PROVIDER inside one try block.
GPS_PROVIDER requires precise location. Since Android 12 a user can grant approximate location on its own, and that is the common case -- the runtime dialog offers it as a first-class choice. In that state the GPS read throws SecurityException, which unwinds to the shared catch before NETWORK_PROVIDER is ever reached, so the SDK ends up with no location at all rather than the coarse fix the user did consent to. The only trace is a log line blaming an "android firmware bug", which sends anyone debugging it in the wrong direction.
Each provider is now asked for separately and only when the permission it actually needs is held: GPS_PROVIDER for precise, NETWORK_PROVIDER for either grant. The read itself is isolated per provider, so a refusal or a provider missing on the device no longer prevents the other from being consulted -- IllegalArgumentException is handled for that second case, which the previous code did not cover at all. The selection logic that prefers GPS and falls back to the network fix via isBetterLocation is unchanged.
Covers the new behaviour in LastKnownLocationInfoManagerTest: coarse-only never asks for GPS, a refused GPS read still yields the network location, and no grant reads no provider.
Partially addresses Deprecated API usage for device and user info #956 (location permissions). The deprecated display metrics and network connection APIs named in that issue are handled separately.