[null,null,["最后更新时间 (UTC)：2025-07-27。"],[],[],null,["# Coarse location on Android Automotive OS\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 fused network location (FLP) because it's fast and consumes less power.\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 requires that you use\n [`requestLocationUpdates`](/reference/android/location/LocationManager#requestLocationUpdates(java.lang.String,%20long,%20float,%20android.location.LocationListener))\n to explicitly identify the preferred location provider.\n\n- Google Play Services API offers a more straightforward way for you to\n work with location in\n [`FusedLocationProviderClient`](https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderClient).\n\nMany automotive apps use the FLP from the Google Play Services API instead of\n`LocationManager`. FLP selects the optimal location provider based on location\nrequest criteria and policies (power and accuracy) needed by the vehicle.\n\nYou can instead opt to explicitly request and use\n[`NETWORK_PROVIDER`](/reference/android/location/LocationManager#NETWORK_PROVIDER)\nas well as\n[`GPS_PROVIDER`](/reference/android/location/LocationManager#GPS_PROVIDER) for\nfine positions, which uses\n[`android.permission.ACCESS_FINE_LOCATION`](/reference/android/Manifest.permission#ACCESS_FINE_LOCATION)\npermissions. On Android 12 (API level 31) and higher, the\n[`FUSED_PROVIDER`](/reference/android/location/LocationManager#FUSED_PROVIDER),\npreviously accessible only through the Google Play Services API, is\navailable as a location provider to `LocationManager`. You can see an implementation of FLP in\n[`FusedLocationProvider.java`](https://cs.android.com/android/platform/superproject/+/master: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\n### Network location in automotive\n\nThe `NETWORK_PROVIDER` used on Android phones (with Google Mobile Services)\ndetermines location based on nearby cell towers, Wi-Fi access points, and\nBluetooth (BT) beacons. As a result, `NETWORK_PROVIDER` may require a data\nconnection.\n\nFor automotive apps, device constraints differ. Because Gthe global navigation\nsatellite system (GNSS) is usually on, no penalties are incurred due to\nincreased power and battery usage. As a result, IVI uptime is not compromised.\nWe strive to minimize data exchanged with our servers.\n\nA lot of apps therefore use FLP from the Play API instead of `LocationManager`\ndirectly as FLP automatically does the *smart thing* by using the location\nprovider best able to satisfy location request criteria/policies (namely power\nand accuracy).\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 (NLP)\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 the\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 perform any sensor fusion.\n\n### Design apps to target mobile and automotive uses\n\nFor apps targeting mobile *and* automotive devices that don't\nrequire a higher quality of precision, request\n[`android.permission.ACCESS_COARSE_LOCATION`](/reference/android/location/LocationManager#FUSED_PROVIDER)\n*only* and fall back to using FLP when available. Alternatively, use\n`GPS_PROVIDER` directly with the same permissions. The framework degrades the\nprecision of the underlying GNSS position to align with API expectations. To\nlearn more, see [Accuracy](/training/location/permissions#accuracy)\nin [Request location permissions](/develop/sensors-and-location/location/permissions).\n\nIn addition, these apps must explicitly declare the\n[`android.hardware.location.network`](/guide/topics/manifest/uses-feature-element#location-hw-features)\nfeature as *optional* in their manifest. For 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."]]
