일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 고려대학교
- Bidirectional Associative Memory
- 파이썬
- 인공지능
- SSM
- 나르왈프레오
- 물걸레로봇청소기추천
- BAM
- 삼성
- 패턴 인식
- Friendship
- 증강현실
- Neural Network
- 구글 앱 엔진
- 신경망
- Google App Engine
- 빅데이터
- 신경회로망
- NarwalFreo
- 멤버십
- 가상화
- 삼성전자 소프트웨어멤버십 SSM
- 물걸레자동세척로봇청소기
- 삼성소프트웨어멤버십
- 패턴인식
- 갤럭시탭S8울트라
- 하이퍼바이저
- hopfield network
- 동아리
- Python
- Today
- Total
정보공간_1
[4기 신촌 박영웅] Android Application Stealth Update (3) 본문
[4기 신촌 박영웅] Android Application Stealth Update (3)
알 수 없는 사용자 2013. 12. 5. 11:16안녕하세요. 신촌 멤버십 22-2기 박영웅입니다.
지난 글에 이어 Android Application의 Stealth Update 구현과 관련된 내용을 설명드리겠습니다.
이번 글에서 설명드릴 부분은 Run-time에 Load될 .apk 파일의 스위칭입니다.
이것은 소프트웨어 부분 업데이트 과정과 거의 동일하다고 보시면 됩니다.
실질적은 구현 내용보다는 구현 과정에서의 생각해볼 수 있는 선택지들을 중점적으로 구성하였습니다.
이 부분에 대해 감이 안 잡히시는 분들이 있을지도 몰라 마련한 위한 순서도입니다.
첫째, 업데이트에 앞서 우선적으로 업데이트 대상이 존재하는지 파악합니다.
제 경험상 업데이트를 확인하는 방법은 크게 세가지로 나눌 수 있습니다.
1) 어플리케이션 실행시 업데이트 존재 여부를 확인하는 방법
2) Service에서의 주기적인 Polling을 통하여 업데이트 존재 여부를 확인하는 방법
3) GCM 혹은 이외의 푸시 서비스를 이용하여 서버에서 어플리케이션으로 직접 업데이트 존재 여부를 통보하는 방법
기본적으로 어플리케이션의 특성 및 효율을 따져 적합한 방법을 선택하시기 바랍니다.
보통, Activity상의 상호작용이 주가되는 실행형 어플리케이션이 아니라
Service 형태로 동작하는 경우, 혹은 Widget의 경우는 2), 3)의 방식이 더 적합합니다.
둘째, 지정된 경로에 파일을 다운로드합니다.
.apk 파일이 노출될 경우 보안상 문제가 될 수 있으므로 External SD card 경로가 아닌
어플리케이션 하위 경로에 mode를 Context.MODE_PRIVATE으로 설정하여 저장하는 것을 권장합니다.
파일의 다운로드가 완료된 경우 현재 다운로드한 파일보다 이전에 다운로드된 파일은 삭제합니다.
(신규 파일에 오류가 발생할 경우를 대비하여 바로 안정화 버전의 경우 따로 남겨두기도 합니다.)
저는 보통 파일을 저장할 때 파일명을 grader.1.apk, grader.2.apk와 같이
[파일명].[버전 혹은 날짜].[확장자] 형태로 저장하여 변경 파일의 전후관계를 파악하기 쉽게합니다.
( '.' 문자를 기준으로 파일명을 split하면 구분이 뙇! )
셋째, 로드할 대상 파일의 경로를 수정합니다.
여기에서 저는 보통 두 가지 방법 중 한가지를 사용하는데요.
1) 로드할 대상의 경로를 Preference를 사용하여 기억하는 방법
2) 파일의 다운로드 경로 내의 모든 파일 중 버전 혹은 날짜가 가장 최신인 파일을 로드하는 방법
둘 중 1)은 구현이 간단하다. 2)는 Preference와 실제 파일이 상이할 경우 생길 수 있는 오류를 방지할 수 있다는 장점이 있으니 원하대로 골라 쓰시는 것을 추천드립니다.
넷째, Run-time Dynamic Class Loading을 수행한다.
세번째 과정에 수정된 경로를 통하여 클래스를 로드하고 어플리케이션의 작업을 수행합니다.
업데이트 대상이 없거나, 파일 다운로드 과정에서 오류가 발생한 경우 이전에 설정된 대상에 대하여
Run-time Dynamic Class Loading을 수행합니다.
이대로 끝마치면 아쉬울 것 같아서,
추가적으로 Run-time Dynamic Class Loading 기법을 사용하는 과정에서
가장 빈번하게 발생하는 오류들에 대해서 이야기 해보겠습니다.
1) IOException
2) FileNotFoundException
위의 두 예외는 파일 경로가 올바르게 지정되어있지 않아서 발생합니다.
.apk 파일의 경로가 올바르게 지정되어있는지, 혹은 해당 경로에 대한 읽기 권한이 있는지 확인해보세요.
이 두 경우 모두 문제가 없다면 optimized Path에 대한 쓰기 권한이 문제인 경우가 대다수일 것입니다..
3) ClassNotFoundException
파일은 올바르게 로드되었는데 클래스를 찾을 수 없다면 클래스명이 올바르게 입력되지 않은 것입니다.
Grader가 아닌 org.secmem.grader.Garader와 같이 패키지명을 포함한 클래스명을 적어주셔야합니다.
혹시나 해당 .apk 파일을 자신이 작성한 경우가 아니어서 클래스명을 알 수 없다면
다음과 같은 메서드를 작성하여 실제 클래스명을 확인할 수 있습니다.
4) NoSuchMethodException
클래스까지 로드되었는데 해당 메서드를 찾지 못하는 경우입니다.
보통 메서드명이 잘못된 것보다 전달인자형과 반환형을 잘못 입력하여 발생하는 경우가 대다수입니다.
이러한 경우도 다음과 같은 메서드를 작성하여 실제 메서드에 관한 정보를 확인하고
해당 메서드를 사용하시면 수월하게 해결하실 수 있습니다.
5) Sub Permissions
가장 빈번하게 하지만 가장 대응하기 난해한 상황을 야기하는 경우입니다.
로드 대상 클래스 상에서 특정 Permission을 요구한다면
로드 주체에서도 동일한 Permission을 가지고 있어야만합니다.
이유를 알 수 없이 특정 기능을 수행할 수 없다면 이와 같은 경우는 아닌지 확인해 볼 필요가 있습니다.
Permission 뿐만 아니라 Manifest 상에서 필수적으로 등록해야하는 모든 정보들에 대해서도
한 번 더 확인하는 자세가 필요합니다.
3개의 글에 걸쳐 Android Application Stealth Update을 구현하는 방법에 대하여 알아보았는데요.
일반적인 업데이트를 하는 것이 이와 같은 방법으로 업데이트를 수행하도록 구성하는 것 보다
여러모로 신경써야할 부분들이 많습니다.
하지만 더 나은 어플리케이션을 만들기 위해서 어떤 방식의 구현을 선택할지는 개발자의 몫이라 생각합니다.
'IT 놀이터 > Elite Member Tech & Talk' 카테고리의 다른 글
[4기 강북 송용길] Unit test with JUnit(5) (1) | 2013.12.05 |
---|---|
[4기 신촌 김형진] 다른 윈도우의 핸들을 얻고 제어하기 (0) | 2013.12.05 |
[4기 강남 노진우] 인간의 선택적 주의 (0) | 2013.12.05 |
[4기 신촌 백재현] 유니코드의 이해 (0) | 2013.12.05 |
[4기 신촌 백재현] Windows Device Driver의 Logo 인증 받는 절차 (0) | 2013.12.05 |