[null,null,["最后更新时间 (UTC)：2025-03-26。"],[],[],null,["# Get coarse location\n\nTo respect user privacy, app developers are encouraged to only request coarse\nlocation permissions. Apps that need an approximate coarse position typically\nuse the network location (FLP) because it's fast and consumes less power.\n\nAs compared to Android-based mobile devices, network location in automotive apps\ncan be more challenging. You can use two Android APIs:\n\n- [LocationManager API](https://developer.android.com/reference/android/location/LocationManager#requestLocationUpdates(java.lang.String,%20long,%20float,%20android.location.LocationListener)) or LM requires you to explicitly identify the preferred\n location provider.\n\n- [Google Play Services API](https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderClient) offers a more simplified way for your to\n work with location with the introduction of the Fused Location Provider\n (FLP).\n\nMany automotive apps use FLP from the Google Play Services (GPS) API instead of\nLM. FLP selects the optimal location provider based on location request\ncriteria and policies (power and accuracy) needed by the vehicle.\n\nYou can instead choose to explicitly request and use\n[`NETWORK_PROVIDER`](https://developer.android.com/reference/android/location/LocationManager#NETWORK_PROVIDER) in LM, as well as\n[`GPS_PROVIDER`](https://developer.android.com/reference/android/location/LocationManager#GPS_PROVIDER) for fine positions, which uses\n[`android.permission.ACCESS_FINE_LOCATION`](https://developer.android.com/reference/android/Manifest.permission#ACCESS_FINE_LOCATION)\npermissions. In API 31, the [`FUSED_PROVIDER`](https://developer.android.com/reference/android/location/LocationManager#FUSED_PROVIDER),\npreviously accessible only through the GPS API, is now\navailable as a location provider to LM. You can view a more simple\nimplementation of FLP, in\n[`FusedLocationProvider.java`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/packages/FusedLocation/src/com/android/location/fused/FusedLocationProvider.java;l=49;drc=1679ed09011e7756e415be9086a9f0ca5dff816b)).\n\nWhile it's possible to use `GPS_PROVIDER` with coarse permission rights only,\nthe framework artificially degrades accuracy to align with expectations, it\nmakes little sense for developers targeting Android phones because overall\navailability is poor and often slower to obtain a coarse position.\n\nNetwork location in automotive\n------------------------------\n\nThe `NETWORK_PROVIDER` used on Android phones (with Google Mobile Services) has\nchanged from determining location based solely on nearby cell towers to\nalso use Wi-Fi access points or even Bluetooth (BT) beacons. Use of\n`NETWORK_PROVIDER` may require a data connection.\n\nFor automotive apps, device constraints differ. Because GNSS is normally on,\nno penalties are incurred due to increased power and battery usage. As a\nresult, IVI uptime isn't compromised. We strive to minimize data exchanged\nwith our servers.\n\nA lot of apps therefore use FLP from the Play API instead of LM directly as FLP\nautomatically does the *smart thing* by using the location provider best able to\nsatisfy location request criteria/policies (namely power and accuracy) under\nthe hood.\n\nUnlike mobile devices, vehicles rarely appear to *jump* from one place to\nanother. Vehicle position is known under the hood most of the time.\n\n### Network location provider\n\nMost vehicles don't implement required telephony APIs to get needed information\non a Cell ID (and signal strength). As a result, and because we minimize data\nusage, no additional functional implementation of NLP is provided.\n\n### Fused location provider\n\nThe mobile FLP, in addition to smartly using network and GPS providers as\nappropriate, fuses information from other sensors to further enhance the\nquality of locations. The current implementation of Automotive's FLP on the\nother hand takes advantage of the aforementioned assumptions and uses\n`GPS_PROVIDER` as an underlying source all the time. It fudges the positions\nfrom GNSS, adding some errors to be more inaccurate when needed. For example,\nwhen coarse locations are provided to a client.\n\nAs such, in a very few instances there can be a longer than usual time for the\nfirst position to be available. For example, the very first time a vehicle or,\nto be more precise, its location subsystem is used or after getting towed.\n| **Note:** Automotive apps should have no expectation that an NLP can be leveraged nor is it expected that the FLP performs any sensor fusion.\n\nDesign apps to target mobile and automotive uses\n------------------------------------------------\n\nWe recommend that apps targeting mobile **and** automotive devices that don't\nrequire a higher quality of precision request\n[`android.permission.ACCESS_COARSE_LOCATION`](https://developer.android.com/reference/android/Manifest.permission.html#ACCESS_COARSE_LOCATION)\n**only** and fall back to using FLP\nwhen available. Alternatively, as a last recourse, use `GPS_PROVIDER` directly\nwith the same permissions. The framework degrades precision of the underlying\nGNSS position to align with API expectations. To learn more, see [Accuracy](https://developer.android.com/training/location/permissions#accuracy).\n\nIn addition, these apps must explicitly declare the\n[`android.hardware.location.network`](https://developer.android.com/guide/topics/manifest/uses-feature-element#location-hw-features)\nfeature *optional* in their manifest.\nFor example: \n\n \u003cuses-feature android:name=\"android.hardware.location.network\" android:required=\"false\" /\u003e\n\nThis approach ensures maximum compatibility with devices across verticals and,\ntherefore, maximum app availability with no code differences for getting\npositions when needed."]]
