대략적인 위치 권한만으로도 GPS_PROVIDER를 사용할 수 있지만 프레임워크에서는 기대치에 맞추기 위해 인위적으로 정확도 수준을 떨어뜨립니다. 이는 전체적인 가용성이 낮고 대략적인 위치를 얻는 시간이 더 느린 경우가 많아 Android 휴대전화를 타겟팅하는 개발자에게는 의미가 없습니다.
자동차의 네트워크 위치
Android 휴대전화(Google 모바일 서비스 포함)에 사용되는 NETWORK_PROVIDER는 근처 휴대폰 기지국에만 의존해 위치를 결정하는 데서 Wi-Fi 액세스 포인트나 블루투스(BT) 비콘까지 사용하는 것으로 변경되었습니다. NETWORK_PROVIDER를 사용하려면 데이터 연결이 필요할 수 있습니다.
자동차 앱의 경우 기기마다 제약이 다릅니다. 보통 GNSS는 켜져 있으므로 전력과 배터리 사용량 증가로 인한 불이익은 발생하지 않습니다. 따라서 IVI 가동시간이 영향을 받지 않습니다. Google에서는 서버와 교환되는 데이터를 최소화하려고 노력합니다.
따라서 많은 앱이 LM 대신 Play API의 FLP를 직접 사용합니다. FLP는 위치 요청 기준/정책(즉, 전력과 정확도)을 가장 잘 충족할 수 있는 위치 정보 제공자를 내부적으로 사용하여 자동으로 스마트한 작업을 실행하기 때문입니다.
휴대기기와 달리 차량은 한 위치에서 다른 위치로 이동하는 경우가 드뭅니다. 차량 위치는 대부분 내부적으로 알려져 있습니다.
네트워크 위치 정보 제공자
대다수 차량은 셀 ID(및 신호 강도)에 관한 필요한 정보를 가져오기 위해 필수 전화 통신 API를 구현하지 않습니다. 또한 Google에서는 데이터 사용량을 최소화하므로 NLP의 추가 기능 구현이 제공되지 않습니다.
통합 위치 정보 제공자
적절하게 네트워크 제공자와 GPS 제공자를 영리하게 사용하는 것 외에도 모바일 FLP는 다른 센서의 정보를 통합하여 위치 정보의 품질을 더 높입니다. 반면 Automotive의 현재 FLP 구현에서는 앞서 언급한 가정을 활용하고 GPS_PROVIDER를 기본 소스로 항상 사용합니다. 또한 GNSS의 위치를 모호하게 하여 필요할 때 더 부정확한 오류를 추가합니다. 예를 들어 대략적인 위치를 클라이언트에 제공하는 경우입니다.
따라서 극히 일부의 경우 첫 번째 위치가 제공되는 시간이 평소보다 길어질 수 있습니다. 예를 들어 차량 또는 더 정확하게는 차량의 위치 하위 시스템이 처음 사용되거나 견인된 후입니다.
모바일 및 자동차 용도를 타겟팅하는 앱 설계
높은 품질의 정밀도가 필요하지 않은 모바일 및 자동차 기기를 타겟팅하는 앱은 android.permission.ACCESS_COARSE_LOCATION만 요청하고 가능하면 FLP를 사용하는 것으로 대체하도록 권고합니다. 또는 최후의 수단으로 동일한 권한을 사용하여 GPS_PROVIDER를 직접 사용하세요. 프레임워크에서 기본 GNSS 위치의 정밀도를 떨어뜨려 API 기대치와 맞춥니다. 자세한 내용은 정확성을 참고하세요.
이 접근 방식을 통해 카테고리 전반에 걸쳐 기기와의 호환성을 극대화할 수 있으므로 필요 시 위치를 얻을 때 코드 차이 없이 앱을 최대로 사용할 수 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-09(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-09(UTC)"],[],[],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."]]
