'IT/Android'에 해당되는 글 8건

테스트 대상 기기: 삼성 갤럭시 노트3 네오, LGU+ (SM-N750L)

Android 버전: 4.4.2

스마트폰을 통한 네트워크 실험을 하는 과정에서, 여러 차례 와이파이에 연결된 스마트폰에 ping을 날려야 하는 경우가 있었다. 화면이 꺼져 있더라도 옵션을 통해서 와이파이에 항상 연결되어 있게 할 수는 있는데, 유독 화면이 꺼져 있을 때에 ping 속도가 느린 것 같다는 느낌이 들어서 실제로 테스트를 해 보았다.

샘플 수가 20개라서 사실 많지는 않지만, 그래도 동일한 환경에서 주변에 다른 방해하는 기기가 거의 없는 새벽 시간대에 해 본 것이라서 어느 정도 의미는 있을 것으로 생각한다.

테스트 환경으로, 라즈베리파이 2B에 hostapd를 돌려서 가상 AP로 만들고, 스마트폰이 그 AP에 연결되도록 했다.

라즈베리파이는 Raspbian Jessie 운영체제에 Atheros ath9k-htc 기반의 USB 무선랜카드를 달고 있고, IEEE 802.11n 모드로 AP를 돌렸다.

테스트용 스마트폰 외에 무선으로 연결된 다른 연결된 기기는 없었다.

아래는 화면이 꺼져 있을 때, 의 ping 결과이다.

아래는 스마트폰 화면을 켜고, 바탕화면을 전환하거나 카카오톡 앱을 한번 켜 보는 등 화면을 켜져 있도록 유지했을 때의 ping 결과이다. 카카오톡을 켤 때 잠시 서버에 접속하는 경우를 제외하고는 스마트폰에서 별도로 트래픽을 발생시키지 않았다.

최소값, 최대값, 평균 모두 차이가 남을 알 수 있다.

평균을 기준으로 대략 2배 가량 전송시간(round trip time)의 차이가 발생했다.

참고로 같은 증상이 삼성 갤럭시 넥서스(버전 4.1.1)에서도 나타났다.

무슨 연유로 어디에서 이러한 지연이 발생하는지는 정확하게 알 수 없다. 하지만 아마도 스마트폰에서 의도적으로 지연을 발생시켰을 것으로 예상되며, 그 이유는 여러가지가 있겠지만 에너지 절약 차원의 목표가 있을 것이라고 추측만 하고 있다.

네트워크 실험을 할 때에는 (물론 화면을 끄고서 실험할 일은 거의 없겠지만) 스마트폰 화면의 꺼짐 유무도 잘 확인하는 것이 좋겠다.

기기: 삼성 갤럭시 노트3 네오 (Samsung Galaxy Note 3 Neo, SM-N750L)

안드로이드 버전: 4.4.2

삼성 갤럭시 스마트폰에 기본으로 내장되어 있으면서 삭제가 불가능한 앱들이 여러 개 있다. 해당 앱들을 구글 플레이 스토어에서 업데이트하는 것은 가능하지만, 삭제하려고 하면 기본 앱(스마트폰 출고 당시의 버전) 상태로 돌아갈 뿐, 순정 상태에서는 결코 삭제할 수 없다.

이러한 앱들 중 상당수는 실제로는 거의 쓰이지 않는데도 삭제를 막아 놓음으로써 쓸데없이 SD 카드 용량만 차지하게 된다. 이번에 소개하는 Samsung WatchON 앱도 그러한 종류이다.

위와 같이 삭제 버튼 대신 "업데이트 삭제" 버튼만 있다. 삭제할 수 없이 기본으로 내장된 앱들 중에서 "사용 안함"으로 설정할 수 있는 앱들도 있는 반면에 이 WatchON 앱은 "사용 안함" 버튼조차 없다.

삭제할 수 없으면 "사용 안함"이라도 가능해야 하는데, 그 이유는 저러한 기본 앱들 중에는 사용자가 한번도 켜지 않았는데도 불구하고 백그라운드에서 실행되고 있는 경우도 많기 때문이다. 안타깝게도 WatchON은 백그라운드에서 몰래 실행까지 하고 있는 경우에 해당된다. 나는 분명히 위의 스크린샷을 찍기 몇 분 전에 "강제 중지"를 하고, "데이터 삭제"까지 해서 10.82MB의 데이터를 없앴는데도 불구하고 몇분 뒤에 다시 확인해 보니 위와 같이 내가 시키지도 않은 데이터 10.82MB를 모아 놓았다.

즉, 내가 강제중지를 해도 잠시 후 몰래 살아나서, 도대체 무슨 짓을 하는지도 알 수 없으면서 데이터는 데이터대로 저장하고 있다.

그리고 결정적으로, 이렇게 혼자서 백그라운드에서 자꾸만 실행되는 이 앱을 구글 플레이 스토어에서 확인해 보면...

스크린샷과 같이 삼성에서 WatchON 서비스를 종료해 버렸다.

참고로 서비스 종료는 공식적으로도 언론에 공개되었다. (http://www.etnews.com/20150210000245)

?!?

삼성에서 더이상 서비스하지 않는 앱인데,

갤럭시 스마트폰에서 기본 내장 앱으로 깔려 있어서 삭제는 불가능하고,

그런데 도대체 무슨 짓을 하는지 모르겠지만 백그라운드에서 자꾸만 실행되면서

10MB 이상의 추가 데이터를 생성/저장한다.

이 정도면 국내 삼성 갤럭시 스마트폰 사용자 입장에서는 악질 앱이라고 평가받아 마땅하다. 삼성전자에서 이 상황에 대해서 얼른 조치를 취해 줬으면 좋겠다. 펌웨어 업데이트를 통해서 WatchON을 삭제할 수 있도록 해야 한다. 그리고 비단 WatchON만 해당되는 것이 아니다. 다른 수많은 기본 앱들에 대해서도 사용자가 원하지 않으면 삭제할 수 있도록 해야 한다.

테스트 스마트폰: 팬택 베가아이언 (LG-U+)

문제의 앱: OK Cashbag (version 5.3.0)

이 글은 2015년 6월 30일, OK Cashbag 버전 5.3.0을 기준으로 작성되었으며, 최신 버전에서는 문제가 없을 수도 있습니다.

오랜만에 아내의 폰을 살펴보면서 쓸데없이 실행 중인 앱들이 없는지 살펴보고 있었는데, 설정에서 강제 종료해도 바로 되살아나서 24시간 내내 실행 중인 상태를 유지하는 앱이 있었으니...

(OK Cashbag 앱은 항상 위와 같이 서비스들을 메모리에 상주시킨다.)

바로 OK Cashbag(OK 캐시백) 앱이 되겠다.

물론 백그라운드에서 서비스로 실행되고 있는 그 자체가 나쁘다는 것이 아니다.

지메일, 카카오톡, 페이스북 등 수많은 앱들이 백그라운드 서비스를 사용하고 있다.

하지만, 백그라운드에서 실행 중인 것만으로도 지나치게 많은 배터리를 소모한다면?

아무래도 배터리 소모가 이상한 것 같아서 재부팅 후 약 2시간 동안 대기 상태로 놓아 뒀다가 배터리 사용량을 확인해 보니, OK 캐시백 앱이 어이없게도 무려 사용량 2위에 올라가 있다. 그동안 배터리는 약 6%를 소비했다. (95%에서 시작)

특정 앱이 배터리 사용량 2위를 차지하는 것이 별 것 아닌 것처럼 생각하는 분들도 계실 수 있겠지만, 저것은 절대로 일반적인 앱의 행태가 아니다. 앞서 말했듯이, 백그라운드 서비스를 실행하는 다른 각종 유명한 앱들(카카오톡, 페이스북, 지메일 등)은 백그라운드에서 실행 중인 상태에서는 절대로 저렇게 높은 순위에 올라가지 않는다. 내 스마트폰의 경우, 지메일과 카카오톡을 자주 켜서 사용하고 푸시 알림을 많이 받는데도 불구하고 배터리 소모량의 비중이 고작 3~4%밖에 되지 않는다.

그런데 저 황당한 OK 캐시백 앱은 단 한번도 켜지 않았는데도 배터리 사용량이 무려 2위이고, 사용량 비중도 14%나 되니까 얼마나 백그라운드에서 쓸데없는 짓을 많이 하길래 그러는지 궁금할 지경이다.

OK 캐시백 앱을 확인해 보니 각종 푸시 알림을 받는 기능을 비롯해서 블루투스 등 백그라운드에서 실행되는 기능 여러가지가 사용하도록 설정되어 있었다. 아내는 OK 캐시백 앱을 실제로 켜서 쓰는 경우가 일주일에 한 번이 채 안되기 때문에, 이것은 지나친 배터리 낭비라고 생각되어 푸시 알림과 위치기반 설정을 모두 해제시켰다.

하지만...

이렇게 각종 푸시 알림을 해제하고 나서 또 한 시간 가량을 대기 상태로 둔 다음 다시 확인했는데도 OK 캐시백은 여전히 배터리 사용량 2위를 차지하고 있었다. 그리고 실행 중인 앱 목록에서도 버젓이 실행되고 있었을 뿐만 아니라, 분명히 블루투스 기능을 해제시켰는데도 블루투스 Low Energy 기능과 연관된 BLEService가 버젓이 실행되고 있었다. 백그라운드 서비스 관리 능력이 완전 빵점이다.

이쯤 되면 개발자가 앱/서비스 최적화 따위는 안중에도 없다는 소리다. 앱에서 블루투스 기능 자체를 쓰지 않기로 설정을 했으면 블루투스 관련 모듈은 종료시키거나 아예 로드를 하지 말아야 하는데, 이 게으른 개발자는 그런 개념도 없이 무조건 다 실행되도록 해 놓았나 보다.

명색이 블루투스 Low Energy (BLE)인데, OK 캐시백 앱에서는 위와 같이 지나치게 블루투스 기능을 활성화시킴으로써 저전력이라는 말이 무색해지는 꼴이 되었다. 앱이 내부적으로 BLE를 어떻게 쓰길래 배터리를 이렇게나 들이켜 대는지도 궁금하다. 고해상도 이미지를 떡칠해서 겉만 번지르르하게 만들지 말고, 내부 프로세스를 코딩할 때 신경 좀 썼으면 좋겠다.