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