태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.
2019.07.29 19:48


[android] Pie (9) 의 Power management


https://developer.android.com/about/versions/pie/power


 Active, active bucket, activity, adb app standby bucket, adb low power, adb unplug, alarm, android 9 power management, android debug bridge commands, android p power management, android pie power management, android power management, api 28 power management, app standby bucket, app standby buckets, background 실행 제한, battery saver, battery saver improvements, best practice, Content Provider, doze whilelist, doze whitelist app standby bucket, FCM, fcm notification, foreground app, foreground service, Frequent, frequent bucket, getAppStandbyBucket, high priority fcm, Job, launcher activity, location service, Machine Learning, Never, never bucket, noti blocking option, noti dismiss, notification, preload ml, priority, priority bucket, Rare, rare bucket, screen off location, stand by bucket priority logic, sync adapter, UsageStatsManager, working set, working set bucket, [android] Pie (9) 의 Power management, 앱 사용 패턴


-

Android 9 (API 28) 에서는 전원 관리를 위한 새로운 feature 가 추가되었다.

이 전원 관리 기능은 2가지 카테고리로 나뉜다.


1. App standby buckets

    시스템이 단말의 CPU, 배터리 등의 리소스 사용을 유저의 사용 패턴에 의해 제한한다.


2. Battery saver 개선

    Battery saver 가 켜져 있을 때 시스템이 모든 앱에 대해 제한을 건다.

    이건 기존에 있던 기능인데, Pie(9) 에서 개선되었다.





* App Standby Buckets


-

얼마나 최근에 얼마나 자주 앱이 사용되었는지에 대한 유저 패턴에 기반하여 리소스 사용에 대한 priority 를 관리한다.

각각의 앱은 5개의 priority bucket 안에 위치한다.


1. Active

    아래 조건을 만족시킨다면, active bucket 안에 위치하며, 이는 job, alarm, FCM 등등에 대해 아무런 제약이 없다.

    - 앱의 activity 를 실행시켰다.

    - 앱이 foreground service 를 실행하고 있다.

    - 앱이 content provider 와 관련하여 sync adapter 를 가지고 있으며, foreground app 이 이를 사용하고 있다.

    - 유저가 app 의 notification 을 클릭한다.


2. Working set

    앱이 자주 실행되지만 현재는 active 에 포함되지 않는 경우에 working set bucket 에 들어간다.

    예를 들면 SNS 같은 경우 daily basis 로 launching 이 되기 때문에 이 bucket 에 들기 쉽다.

    간접적으로라도 자주 사용된다면 이 bucket 에 들어올 수 있다.


    working set bucket 의 앱들에 대해 시스템은 약한 제약을 건다.



3. Frequent

    매일 사용되는 것은 아니지만, 평범하게 사용이 된다면 이 bucket 안에 든다.

    예를 들면 운동 기록 앱같은 경우는 gym 에서만 주로 실행이 되는데 이런 것들이 이 bucket 에 포함될 수 있다.


    frequent bucket 의 앱들은 더 강력한 제한을 받는다. High-priority FCM message 는 받을 수 있다.


4. Rare

    자주 사용되지 않는 앱들이 여기에 포함된다.

    Hotel app 들이 예인데, 필요에 의해 아주 가끔 실행되는 이런 류의 앱들이 이 bucket 에 포함될 수 있다.


    rare bucket 의 앱들은 시스템이 강력한 제한을 건다. 심지어 high-priority FCM message 도 받을 수 없다.

    network 를 사용할 수도 없다.


5. Never

    설치는 되었지만 전혀 실행되지 않은 경우에 이 bucket 에 할당된다.

    system 은 혹독한 제약을 건다.



-

시스템은 동적으로 앱들을 priority bucket 에 할당하며, 이는 필요에 따라 재할당된다.

시스템은 preload 된 앱의 ML (machine learning)을 이용하여 이를 판단한다.

만약에 해당 앱이 system default 로 없다면, 시스템은 얼마나 자주 사용되었는지만을 기준으로 priority 를 판단한다.

bucket 은 얼마나 자주 앱이 job 을 실행하는지, 얼마나 자주 alarm 을 trigger 하는지, 얼마나 자주 FCM message 를 받는지 등이 bucket priority 에 의해 조절된다.



-

제조사가 각자가 원하는 non-active app 에 대해 criteria 들을 설정할 수 있다.

앱 개발자들은 어떤 bucket 에 속하더라도 동작을 잘 하도록 확실히 하는 것이 중요하다.



-

내가 어떤 bucket 에 속해있는지는 UsageStatsManager.getAppStandbyBucket() 을 호출해서 알 수 있다.



-

Doze whitelist 에 들어있는 앱들은 bucket 기반 제약에서 예외처리된다.





* Best practices


-

이미 Doze and app standby 의 best practice 를 따르고 있다면, 새로운 power management 기능을 다루는 것이 어렵지 않을 것이다.


다음을 체크하자.


- 시스템이 너의 앱을 특정 bucket 에 넣도록 이상한 수를 써서 유도하지 말아라. 시스템이 bucket 을 분리하는 로직은 변화될 수 있고, 각 제조사가 그들의 algorithm 을 적용하여 bucketing 규칙을 정할 수도 있다.

- 앱이 launcher activity 가 없다면, 결코 active bucket 으로 들어갈 수 없을 것이다. 그런 경우 launcher activity 를 갖도록 redesign 되어야 한다.

- notification 이 actionable 하지 않다면, active bucket 으로 승급시키기가 어렵다. 이런 경우 notification 을 수정하여 user 의 action 에 반응할 수 있도록 해야 한다.

- 앱이 FCM 을 받아도 notification 을 보여주지 않는다면, active bucket 으로 승급할 기회가 줄어든다. high priority FCM 을 사용하면서 notification 을 사용하지 않는다면, 이는 일반 메시지를 편법적인 것으로 간주하는 것으로 추정될 수 있다. (이는 나중의 algorithm 에 영향을 받아 bucket 조정에 영향을 미칠 수도 있을 것 같다.)

- 앱이 multiple package 로 나누어 진다면, 각각의 앱이 다른 bucket 으로 들어갈 수 있다. 그러므로 이런 경우 정상 작동 하는지 체크를 더 해야 한다.



-

유저가 반복적으로 noti 를 dismiss 시킨다면, 시스템은 user 에게 noti 를 blocking 시키는 option 을 제공할 예정이다.

그러므로 user 에게 noti 를 spam 처럼 제공해서 active bucket 으로 올리려는 이상한 시도를 하지 말것!








* Battery saver improvements


-

제조사가 제약사항을 결정할 수 있다.

예를 들어 AOSP 에서 시스템은 다음과 같은 제약을 갖는다.


- 시스템은 조금 더 공격적으로 앱을 standby mode 에 넣는다.

- Background 실행 제한이 모든 앱에 적용된다. target API level 과 상관없이..

- Location service 가 screen off 되었을 때 동작하지 않는다.

- Background app 은 network 를 사용할 수 없다.



-

역시나 Battery saver mode 에서 테스트가 수행되어야 한다.





* Testing and troubleshooting


-

새로운 power management 기능들은 target api 상관 없이 모든 앱에 적용된다.

그래서 테스트가 필요하다.





* Android Debug Bridge commands


App standby buckets


-

$ adb shell am set-standby-bucket packagename active|working_set|frequent|rare


여러 개의 package 를 한번에 세팅할 떄는..

$ adb shell am set-standby-bucket package1 bucket1 package2 bucket2…


현재 실행중인 버킷을 알고 싶다면..

$ adb shell am get-standby-bucket [packagename]


위의 command 에서 packageName 을 전달해주지 않으면 모든 앱에 대해서 출력된다.




Battery saver


-

Setting > Battery saver 에 가서 on/off 할 수 있다.

unplug 를 simulate 하려면

$ adb shell dumpsys battery unplug


low power condition simulate 하려면

$ adb shell settings put global low_power 1


테스트가 끝나면

$ adb shell dumpsys battery reset




댓글을 달아 주세요


Posted by 돼지왕왕돼지