Repository navigation
fix(location): carry the iPhone's location request onto the Wi-Fi link - #48
Open
code-new-bie wants to merge 1 commit into
Open
code-new-bie wants to merge 1 commit into
code-new-bie wants to merge 1 commit into
Conversation
During wireless CarPlay setup the iPhone sends StartLocationInformation (0xFFFA) on the Bluetooth iAP2 link and then closes that link; some iPhones send StopLocationInformation (0xFFFC) there within milliseconds. In testing it never asked again on the Wi-Fi tunnel link, even while driving, so no head-unit location reached the iPhone for the whole wireless session. The request is now recorded in an Iap2LocationRequest that the Bluetooth and Wi-Fi links of a wireless session share, and the Wi-Fi link carries it on: - A stop on the Bluetooth link of a wireless session ends only that link; the request stays for the Wi-Fi link. A stop on the Wi-Fi link, or on a wired link, stops reporting as before. - Both links share the location provider: each holds it while reporting and only the last one to stop releases it. - Reports are sent at most once a second, and the log records which NMEA sentences were sent, with a running count about every five minutes. The duplicated location handling of Iap2WiredControlClient and Iap2WirelessControlClient moves into Iap2LocationReporter in Iap2LocationClient.kt. Iap2LocationReporterTest covers the handover, a stop on the Bluetooth link, a stop on the Wi-Fi link, the shared provider and a wired link. Verified in a car (BYD Song PLUS, Android 10) running this code: before the change no location report followed the handover; after it, reports arrive for the whole wireless session.
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
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.
During wireless CarPlay setup the iPhone sends StartLocationInformation
(0xFFFA) on the Bluetooth iAP2 link and then closes that link; some iPhones
send StopLocationInformation (0xFFFC) there within milliseconds. In testing
it never asked again on the Wi-Fi tunnel link, even while driving, so no
head-unit location reached the iPhone for the whole wireless session.
The request is now recorded in an Iap2LocationRequest that the Bluetooth and
Wi-Fi links of a wireless session share, and the Wi-Fi link carries it on:
the request stays for the Wi-Fi link. A stop on the Wi-Fi link, or on a
wired link, stops reporting as before.
only the last one to stop releases it.
sentences were sent, with a running count about every five minutes.
The duplicated location handling of Iap2WiredControlClient and
Iap2WirelessControlClient moves into Iap2LocationReporter in
Iap2LocationClient.kt. Iap2LocationReporterTest covers the handover, a stop
on the Bluetooth link, a stop on the Wi-Fi link, the shared provider and a
wired link.
Verified in a car (BYD Song PLUS, Android 10) running this code: before the
change no location report followed the handover; after it, reports arrive
for the whole wireless session.