[번역] [Android O Preview] Background Location Limits

Background Location Limits

Power 소모를 줄이기 위해, Android O 개발자 Preview는 App의 Target SDK Version과 관계 없이 사용자의 현재 위치를 검색할 수 있는 빈도를 제한한다.
이 위치 검색은 만약 앱이 background에서 수행되는 동안 실시간 Alert과 모션인식에 의존한다면, 계속 유의해야 한다. 
중요: 백그라운드 앱이 매시간마다 몇번 위치 업데이트를 받을 수 있도록 허용중이다. 개발자의 피드백과 시스템 영향을 기반으로 Preview를 통해 위치 업데이트 간격을 조정중이다.
시스템은 background앱과 foreground앱을 구분한다. 앱은 아래의 조건중 하나라도 참일때 foreground로 간주된다.
  • 액티비티가 started혹은 paused이더라도 하나의 보여지는 activity를 가지고 있다. 
  • 하나의 foreground service를 가지고 있다.
  • 또 다른 Foreground 앱이 이 앱의 서비스중 하나에 binding되었거나, 이 앱의 Content Provider중 하나를 사용하여 연결되었다. 
만약에 이 조건들 중 true가 되는 것이 없다면, 그 앱은 background 앱으로 간주된다.

Foreground app behavior is preserved

If an app is in the foreground on a device running Android O, the location update behavior is the same as on Android 7.1.1 (API level 25) and lower.
만약 앱이 Android O 단말에서 foreground라면 위치 업데이트는 Android 7.1.1 이하에서와 동일하다. 
Warning: 만약 앱이 오랜 시간동안 실시간 위치 업데이트에 가까운 검색을 한다면, 단말의 배터리 수명이 크게 단축된다.

Tuning your app's location behavior

백그라운드에서 실행되는 앱의 Use Case에서 위치업데이트가 자주 발생하지 않는 경우 문제가 있는지 고려하라. 만약 그런 경우, 아래 작업중 하나를 수행해서 위치 업데이트를 좀 더 자주 검색할 수 있다:
  • 앱을 foreground로 만들어라.
  • 앱에서 foreground service 를 사용해라. 이 서비스가 활성화 되면, 앱은 notification area에 ongoing notification으로 보여야 한다.
  • Geofencing API의 요소들을 사용해라. GeofencingApi interface는 전력 사용 최소화에 최적화 되어있다.
  • Foreground 앱이 좀 더 빠른속도로 위치를 요청할 경우 수동적인(passive) location listener를 사용해라. 
Note: 앱에서 시간이 오래걸리는 업데이트가 포함된 위치 기록에 액세스 해야하는 경우, FusedLocationProviderApi 인터페이스와 같은 Fused Location Provider API를 사용하라. 앱이 백그라운드에서 실행될때, 이 API는 일괄처리 되지 않은 API보다 더 빈번하게 사용자의 위치를 받는다. 명심할 점은, 앱은 여전히 매 시각마다 오직 몇번의 업데이트를 받는다.

영향받는 APIs

백그라운드 앱의 위치검색 동작이 변경되면 아래 API들에 영향을 준다:
Fused Location Provider (FLP)
  • 만약 앱이 백그라운드에서 실행된다면, 위치 시스템 서비스는  앱을 위해서 시간당 오직 몇번만(Android O Behavior 변경에 정의된 간격에 따라) 새로운 위치를 계산한다.  이것은 앱이 좀더 빈번하게 위치 업데이트를 요청할때도 마찬가지이다.
  • If your app is running in the foreground, there is no change in location sampling rates compared to Android 7.1.1 (API level 25).
Geofencing
  • 백그라운드 앱은 Fused Location Provider의 업데이트보다 Geofencing Transition 이벤트를 좀 더 빈번하게 받을 수 있다.
GNSS Measurements and GNSS Navigation Message
Location Manager
  • 위치 업데이트는 백그라운드 앱에게 시간당 오직 몇번의(Android O Behavior 변경에 정의된 간격에 따라) 업데이트만 제공한다. 
    Note: 만약 Google Play Service가 설치된 단말에서 앱을 실행한다면, Fused Location Provider (FLP)를 사용하는 것을 추천한다

댓글

댓글 쓰기

이 블로그의 인기 게시물

[Android] DataBinding의 동작방식 - 4. include Tag 혹은 ViewStub 사용시의 Binding

이미지
이번에는 <include>와 ViewStub 사용시의 Binding에 대해서 알아보려고 한다. 사실 include와 ViewStub까지 사용해서 앱을 만드는 경우는 그렇게 많지는 않다고 생각한다. 하지만 앱이 복잡해 지는경우, View의 재사용을 include를 통해 적용하게 되는 경우등에는 쓰는 경우들이 있는데, Binding을 사용하는 경우에는 Bind되는 Model을 재사용하거나 분리하려고 할 때도 쓸 수 있다. "[Android] DataBinding의 동작방식" 전체목록     1. Setter Method와의 연결     2. BindingAdapter의 기본 및 사용 시점     3. BindingAdapter의 사용시 팁     4. include Tag 혹은 ViewStub 사용시의 Binding     5. Listener, Callback     6. InverseBinding (InverseBindingAdapter) + Two way Binding 1. <include>에서의 Binding  우선은 제일 간단한 <include> Tag 사용시의 Binding에 대해서 알아본다. 가장 외곽  1) outer layout xml <? xml version = "1.0" encoding = "utf-8" ?> < layout xmlns: android = "http://schemas.android.com/apk/res/android" xmlns: app = "http://schemas.android.com/apk/res-auto" > < data > < variable name = "user" type = "com.example.User" /...
자세한 내용 보기

[Android] Retrofit2, OkHttpClient Method 정리

이미지
(이 Post는 Retrofit 2.2.0 기준으로 작성되었음) Retrofit을 적용하면서, 지원되는 기능들을 한번 정리를 해 둬야, 어떤 것을 쓸수 있는지 확실히 할 수 있을 것 같아서, 아래와 같이 정리한다. 1. Retrofit.Builder    baseUrl(String baseUrl) 을 제외하면, 대부분 DI의 형태를 띄고 있다. 각각 Injection 되는 Class들의 용도는 각 항목에서 설명한다. 분석을 하고 보니, Retrofit Class는 이 Builder를 통해 Injection 된 Instance들을 들고있는 Holder 역할을 하는 것으로 보인다. baseUrl(String baseUrl) : Base가 되는 URL을 설정한다. 많은 서비스들에서 사용하는 API들은 앞부분의 Host 정도는 동일하고, 뒷부분의 API Name들로 구분을 하는 경우가 많다. 그때 고정이 되는 앞부분을 여기서는 BaseURL이라고 이야기하고 있다. 만약 BaseUrl을 "https://apis.github.com"이라고 설정한 다음 실제 Retrofit Service Interface에서 @GET("/user/repos")라고 선언해서 사용한다면 실제 요청은 "https://apis.github.com/user/repos"로 나가게 된다. 중요한 부분이 있어서 Retrofit의 Document에서 일부를 가져온다. 올바른 사용: Base URL: http://example.com/api/ Endpoint: foo/bar/ Result: http://example.com/api/foo/bar/ 잘못된 사용: Base URL: http://example.com/api Endpoint: foo/bar/ Result: http://example.com/foo/bar/ 만약 Base URL을 설정하지 않으면 IllegalStateException이 발생하게 된다. baseUrl(HttpU...
자세한 내용 보기

[Android] EventBus보다 빠르고 간단한 MessageBus !!

Android에서 이벤트를 전달하는 방법은 다양합니다. 일반적인 Callback이나 Listener를 통해 전달하는 방법이 있고, Broadcast를 통해서 전달하거나 Intent를 통해 전달을 하는 등, 다양한 방법들이 있습니다. 하지만, 앱이 복잡해짐에 따라 Listener를 깊숙하게 전달해야하는 문제들이 있었습니다. Broadcast를 하기에는 너무 무거운 감이 있고, 기타 방법들도 마땅치 않은 경우들이 많습니다. 이러한 문제를 해결하기 위해서 다양한 개발자들이 여러 해법들을 제시해왔고, 그 중 인기를 얻고 있는 EventBus(https://github.com/greenrobot/EventBus) 가 있습니다. 저 역시 EventBus를 사용하기 위해 검토를 해봤는데, 제가 봤을 때 문제점과 우려되는 점 들이 있었습니다. EventBus의 문제 + 우려 1. 전달하는 Event의 형태는 항상 Object이다.   - instanceof 로 같은 Class를 등록해둔 Subscriber는 모두 받게 된다.   - 가볍게 이벤트의 발생만 알리고 싶어도 커스텀 클래스를 정의해야한다. 2. 정의된 Annotation을 통해 Subscriber로 등록하지만, Runtime에 Annotation이 리플렉션으로 처리되기 때문에, 약간의 속도저하를 예상할 수 있다.   - 한두개 정도의 Subscriber의 등록은 큰 문제 없겠지만, 동시에 Subscriber로 등록하는 컴포넌트들이 많다면(40~60개 수준?), 약간은 걱정되는 부분이다. 이 두가지 문제를 해결하기 위해 MessageBus 를 만들게 되었습니다. ( Github :  https://github.com/UnsignedUSB/MessageBus ) 1. MessageBus에서는 Event를 integer형으로 던질 수 있습니다. 2. MessageBus는 Annotation Processor로 돌아가기 때문에, Build tim...
자세한 내용 보기