為尊重使用者隱私，我們建議應用程式開發人員只要求粗略 位置存取權。需要概略位置的應用程式 (通常是 使用網路位置 (FLP)，因為速度較快且耗電量更低。
與 Android 行動裝置相比，車用應用程式中的網路位置資訊 開發人員可能會比較困難您可以使用兩種 Android API：
使用 LocationManager API 時，您必須明確指出要使用的偏好應用程式 位置預測供應商
Google Play Services API 讓您 導入整合式位置預測提供工具，讓使用者能利用位置資訊 (FLP)。
許多汽車應用程式採用 Google Play 服務 (GPS) API 的 FLP 模型FLP 會根據位置資訊要求選擇最合適的定位服務供應商 車輛所需的標準和政策 (電力與準確性)。
您也可以改為明確要求
LM 中的 NETWORK_PROVIDER，以及
GPS_PROVIDER 適用於精確位置，使用
android.permission.ACCESS_FINE_LOCATION
授予其要求的權限。在 API 31 中，FUSED_PROVIDER
先前只能透過 GPS API 存取，現在
做為 LM 的定位提供者你可以查看較簡單的
FLP 的實作，在
FusedLocationProvider.java。
雖然 GPS_PROVIDER 只可在概略權限中使用，
這個架構會人工降低準確率，以符合期望
這對鎖定 Android 手機的開發人員來說並不合理
可用性不佳且通常較慢，拿出較差的位置。
汽車的網路位置
在 Android 手機 (搭配 Google 行動服務) 上使用的 NETWORK_PROVIDER：
從僅根據鄰近行動通信基地台判斷位置而變更為
也會使用 Wi-Fi 存取點，甚至是藍牙 (BT) 信標。使用
「NETWORK_PROVIDER」可能需要數據連線。
對於車用應用程式，裝置限制有所不同。由於 GNSS 通常處於開啟狀態， 也不會因電力和電池用量增加而造成懲處。身為 因此 IVI 運作時間並未遭到入侵。我們致力於盡量減少交換資料 與我們的伺服器互動。
因此，許多應用程式都會以 FLP 的形式直接使用 Play API 中的 FLP，而非直接以 FLP 形式使用 自動處理智慧型功能， 符合位置資訊要求條件/政策 (涵蓋力量和精確度)， 基礎架構
與行動裝置不同，車輛在某些地方很少跳躍 另一個例子。通常車輛位置位於車內。
網路位置供應商
大多數車輛不會實作必要的電話 API 以取得必要資訊 以及訊號強度)。這麼做是因為我們盡量減少資料用量 但不提供額外功能來導入自然語言處理 (NLP)。
整合式位置預測提供工具
行動 FLP 外，還巧妙地使用網路和 GPS 供應商來
並融合其他感應器的資訊，進一步
地點的品質。目前在
另一隻手利用上述假設和使用
GPS_PROVIDER 一律做為基礎來源。幫助使用者找到立場
加入一些錯誤，提高相關資訊的準確度。例如：
以提供概略位置給用戶端。
因此，在極少數情況下 第一個可用的位置例如第一次開車 更精確地說，使用其位置子系統，或在拖床之後使用其位置子系統。
設計應用程式來指定行動和汽車用途
建議您在應用程式不提供行動應用程式的「和」行動裝置
需要更高品質的精確度要求
android.permission.ACCESS_COARSE_LOCATION敬上
，並改回使用 FLP
(如適用)。或者，您也可以先直接使用 GPS_PROVIDER，
當中包含相同權限架構會降低基礎結構的精確度
GNSS 如何定位符合 API 期望。詳情請參閱「準確度」一節。
此外，這類應用程式必須明確宣告
android.hardware.location.network敬上
在資訊清單中為「選用」功能。
例如：
<uses-feature android:name="android.hardware.location.network" android:required="false" />
這種做法可確保最大程度地與各個產業的裝置相容， 因此，應用程式可用性上限 在取得任何程式碼時 適時放置