태그 보관물: 안드로이드

안드로이드 기기의 USB 메모리 마운트 위치

안드로이드 기기를 제조하는 많은(공식 넥서스를 제외, 루팅 하면 가능) 제조사에서 기기에 USB를 사용할 수 있도록 제공하고 있다. 이것은 USB OTG라는 USB 확장지원을 안드로이드에서 지원하게 되었고, 이제 OTG 케이블을 안드로이드 기기에 연결하면 USB 메모리, 마우스 등을 사용할 수 있게 된다.

이게 편리하기는 하지만, 막상 USB를 외부 메모리로 사용하려고 하면, 연결한 USB가 어디에 마운트(mount)되어 있는지 명확하지가 않다. /mnt 나 /storage에 마운트 하는 것이 일반적이다. 그래서 USB를 연결한 안드로이드 기기별로 USB 마운트 위치를 찾아보니, 스택오버플로에 테스트해서 정리한 것이 있다. 정리된 내용은 아래와 같다.

/storage/UsbDriveA (all Samsung devices)
/storage/USBstorage1 (LG G4, V10, G3, G2, other LG devices)
/storage/usbdisk (Moto Maxx, Turbo 2, Moto X Pure, other Motorola devices)
/storage/usbotg (Sony Xperia devices, Lenovo Tabs)
/storage/UDiskA (Oppo devices)
/storage/usb-storage (Acer Iconia Tabs)
/storage/usbcard (Dell Venue — Vanilla Android 4.3 tablet)
/storage/usb (HTC One M7, and some Vanilla Android devices)

삼성과 LG를 확인해보니, 삼성은 UsbDriveA, B… F와 같은 형태로 마운트 위치를 제공하고, LG는 USBstorage1, 2… 의 형태로 여러 개의 USB를 대응하고 있다.

혹시, 더 자세한 정보를 가지고 있는 분이 있다면 알려주시면 매우 감사합니다.

[번역] 안드로이드 앱이 메모리 누수(Leak)를 만드는 8가지 방법

이 글은 Eight Ways Your Android App Can Leak Memory 라는 내용으로 http://blog.nimbledroid.com에 포스팅된 글을 번역한 내용으로 저자로부터 허락을 받았습니다. 그리고 일부 오역이나 의역이 있을 수 있으니 참고해 주시면 감사하겠습니다.


자바처럼 가비지 콜렉터를 사용하는 언어가 가지는 장점 중 하나는 개발자가 명시적으로 메모리를 관리할 필요가 없다는 것이다. 이것은 잘못된 메모리 참조(segmentation fault)로 앱의 크래시나 메모리를 해제하지 않아 힙 메모리가 증가(bloating)하는 가능성을 줄여 안전한 코드를 만들게 한다. 불행하게도, 자바에서도 논리적으로 메모리를 누수 시킬 수 있는 여러 가지 방법이 있다. 결국 안드로이드 앱은 여전히 불필요한 메모리를 사용하고 OOM(Out Of Memory)의 결과로 크래시가 발생하기 쉽다는 것을 말한다.

일반적인 메모리 누수는, 모든 연관 참조가 범위(일반적으로 메서드 완료나 객체의 소멸)를 벗어나기 전에 할당한 메모리를 해제하지 않는 경우에 발생한다. 일반적인 메모리 누수와 다르게, 논리적인 메모리 누수는 앱에서 더는 필요 없는 객체의 참조를 해제하지 않은 것의 결과이다. 객체에 강한 참조(strong reference)가 있는 경우에, 가비지 컬렉터는 메모리에서 객체를 제거할 수 없다. 만약 한 컨텍스트(Context)에서 누수가 발생한다면 안드로이드 개발에 특히 문제가 된다. 액티비티(Activites)와 같은 컨텍스트는 많은 양의 메모리에 많은 참조(예로, 뷰 계층과 기타 자원 등)를 가지고 있기 때문이다. 컨텍스트가 누수된 경우, 컨텍스트가 가르키는 모든 것들 또한 누수된다. 대부분 안드로이드는 제한된 메모리를 사용하는 모바일 기기에서 실행해서, 누수가 많이 발생하면 앱에서 사용할 가용메모리가 전부 소진될 가능성이 매우 크다.

객체의 생명주기가 명확하기 정의되지 않았다면, 논리적인 메모리 누수를 감지하는 것은 주관적인 문제가 됐을 것이다. 다행히도, 액티비티는 매우 명확하게 정의한 생명주기를 가지고 있고, 생명주기는 액티비티 객체가 누수 했는지를 아주 쉽게 고려할 수 있게 한다. 액티비티의 onDestroy() 메서드는 생명이 종료할 때 그리고 프로그래머의 의도나 안드로이드가 일부 메모리 회수할 필요가 있을 때 객체가 종료된다는 것을 알려주는 경우 호출된다. 액티비티의 onDestory() 메서드가 완료했지만 액티비티 객체는 힙 루트의 강한 참조로 연결되어 있을 수 있고, 이런 경우 가비지 콜렉터는 메모리에서 삭제하기 위해 마크할 수 없다(원래 의도가 객체를 삭제하는 것임에도 불구하고). 결과적으로, 정상적인 생명주기를 지나 계속 유지되는 액티비티 객체는 누수라고 정의할 수 있다.

액티비티는 매우 크고 무거운 객체라서, 안드로이드 프레임웍이 처리하는 것들을 무시하도록 선택하면 안 된다. 하지만, 액티비티 객체는 의도하지 않게 누수될 수 있는 방법들이 있다. 안드로이드에서, 잠재적인 메모리 누수로 이끄는 위험한 것들 모두는 두 가지 기본 상황 위주로 연결되어 있다. 첫 번째 메모리 누수 카테고리는 앱의 상태와 관계없이 존재하고 액티비티에 참조로 유지하는 프로세스 전역 정적 객체로 인해서 발생한다. 다른 카테고리는 액티비티에서 강한 참조를 가진 스레드가 액비티비의 수명보다 오래 지속하는 경우에 발생한다. 이런 상황을 만들 수 있는 몇 가지(다른) 방법을 살펴보자.

아래 테스트 코드는 https://github.com/NimbleDroid/Memory-Leaks/blob/master/app/src/main/java/com/nimbledroid/memoryleaks/MainActivity.java 에서 확인할 수 있다.

1. 정적 액티비티(Static Activities)

액티비티를 누수 시키는 가장 쉬운 방법은 액티비티 클래스에 정적 변수를 선언하고, 다음에 액티비티의 실행 객체를 바인딩(setting)하는 것이다. 액티비티의 생명주기가 완료하기 전에 참조가 제거되지 않는다면, 액티비티는 누수될 것이다. 앱의 전체 실행시간에 액티비티의 클래스(예로 MainActivity)를 나타내는 객체가 정적이고 메모리에 적재되어 남아있기 때문이다. 이 클래스 객체가 액티비티 객체에 참조를 유지한다면, 가비지 콜렉션 대상이 아니게 된다.

void setStaticActivity() {
  activity = this;
}

View saButton = findViewById(R.id.sa_button);
saButton.setOnClickListener(new View.OnClickListener() {
  @Override public void onClick(View v) {
    setStaticActivity();
    nextActivity();
  }
});

2. 정적 뷰(Static Views)

비슷한 상황은 액티비티가 종종 참조하거나 객체를 메모리에 로드해서 유지하는데 장점이 있는 싱글톤 패턴(singleton pattern)을 구현하는 것일 수도 있고, 그것은 빠르게 복원될 수 있다. 그러나, 앞에서 언급한 것처럼, 액티비티에 정의된 생명주기를 무시하고 메모리에 정적 뷰를 유지하는 것은 매우 위험하고 불필요하다 – 그리고 모든 비용은 피해야한다.

그러나 객체화 하는데 많은 노력(?)이 필요하지만 같은 액티비티의 다른 생명주기에 걸쳐서 변화하지 않는 특별한 뷰를 가지고 있다면 어떻게 될까? 그렇다면, 아래코드에서처럼, 뷰를 객체로 만들고 뷰 계층에 추가한 뒤에 뷰를 정적으로 만들자.

이제 액티비티가 종료되면, 액티비티의 메모리 대부분을 해제할 수 있어야 한다. 추가된 뷰는 뷰의 컨텍스트(이 경우에는 액티비티)에 참조를 유지할 것이라는 것을 알고 있을 겁니다. 뷰에 정적 참조를 만들어서, 액티비티에 영속적인 참조 연결을 만들었고, 누수되었다. 뷰를 정적으로 추가하지 마세요, 만약 해야 한다면 액티비티가 완료하기 전 특정 시점에 뷰 계층에서 정적 뷰를 제거하세요.

void setStaticView() {
  view = findViewById(R.id.sv_button);
}

View svButton = findViewById(R.id.sv_button);
svButton.setOnClickListener(new View.OnClickListener() {
  @Override public void onClick(View v) {
    setStaticView();
    nextActivity();
  }
});

3. 내부 클래스(Inner Classes)

계속해서, 내부 클래스라고 불리는 클래스를 액티비티에 정의했다고 가정해보자. 프로그래머는 가독성과 캡슐화를 향상한다는 이유를 포함한 여러 가지 이유로 내부 클래스를 사용할 수 있을 것이다. 내부 클래스의 객체를 생성하고 정적 참조로 유지한다면 어떻게 될까? 이 지점에서 또한 메모리 누수가 다가오는 것을 예상할 수 있을 것이다.

void createInnerClass() {
    class InnerClass {
    }
    inner = new InnerClass();
}

View icButton = findViewById(R.id.ic_button);
icButton.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View v) {
        createInnerClass();
        nextActivity();
    }
});

불행하게도, 내부 클래스 객체의 장점 중의 하나가 “외부 클래스(내부 클래스를 선언한 클래스) 변수에 접근할 수 있다”는 것이기에, 내부 클래스 객체는 액티비티가 누수 하는 원인인 외부 클래스 객체에 참조를 유지해야 한다.

4. 익명 클래스(Anonymous Classes)

마찬가지로 익명 클래스 역시 익명 클래스를 선언한 클래스에 참조를 유지할 것이다. 그래서 액티비티에 AsyncTask를 익명으로 선언하고 객체화한다면 메모리 누수가 발생할 수 있다. 만약 액티비티가 종료한 후에 익명 AsyncTask가 백그라운드로 계속 동작한다면, 액티비티에 참조가 계속 유지될 것이고 이것은 백그라운드 작업이 완료될 때까지 액티비티가 가비지 콜렉트되지 않는다는 것이다.

void startAsyncTask() {
    new AsyncTask<Void, Void, Void>() {
        @Override protected Void doInBackground(Void... params) {
            while(true);
        }
    }.execute();
}

super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
View aicButton = findViewById(R.id.at_button);
aicButton.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View v) {
        startAsyncTask();
        nextActivity();
    }
});

5. 핸들러(Handlers)

매우 비슷한 원리가 Runnable 객체로 익명으로 정의된 백그라운드 태스크에 적용된다. 그리고 이 객체는 핸들러 객체로 실행하는 것을 기다린다. 액티비티에 선언된 Runnable 객체는 암시적으로 액티비티에 참조할 것이고, 다음에 핸들러의 메시지 큐(MessageQueue)에 메시지로 등록될 것이다. 액티비티 종료되기 전에 메시지가 처리되지 않는 한, 참조 연결은 액티비티를 메모리에 유지하게 할 것이고 누수의 원인이 된다.

void createHandler() {
    new Handler() {
        @Override public void handleMessage(Message message) {
            super.handleMessage(message);
        }
    }.postDelayed(new Runnable() {
        @Override public void run() {
            while(true);
        }
    }, Long.MAX_VALUE >> 1);
}

View hButton = findViewById(R.id.h_button);
hButton.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View v) {
        createHandler();
        nextActivity();
    }
});

6. 스레드(Thread)

스레드(Thread)와 타이머 태스크(TimerTask) 클래스 모두에서 같은 실수를 다시 반복할 수 있다.

void spawnThread() {
    new Thread() {
        @Override public void run() {
            while(true);
        }
    }.start();
}

View tButton = findViewById(R.id.t_button);
tButton.setOnClickListener(new View.OnClickListener() {
  @Override public void onClick(View v) {
      spawnThread();
      nextActivity();
  }
});

7. 타이머 작업

별도 스레드에서 작업을 수행하지만, 익명으로 선언되고 객체화되는 한, 이미 종료한 액티비티에 참조 연결을 계속 유지할 것이고 다시 누수의 원인이 될 것이다.

void scheduleTimer() {
    new Timer().schedule(new TimerTask() {
        @Override
        public void run() {
            while(true);
        }
    }, Long.MAX_VALUE >> 1);
}

View ttButton = findViewById(R.id.tt_button);
ttButton.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View v) {
        scheduleTimer();
        nextActivity();
    }
});

8. 센서 관리자

마지막으로, 컨텍스트(Context)로 getSystemService() 메서드를 호출해서 찾을 수 있는 시스템 서비스가 있다. 시스템 서비스는 자신의 프로세스에서 동작하고, 백그라운드 작업과 같은 종류를 실행하거나 기기 하드웨어의 기능을 인터페이스 해서 앱을 도와준다. 컨텍스트가 서비스에서 이벤트가 발생할 때마다 노티를 받기 원한다면, 리스너로 컨텍스트 자신을 등록시킬 필요가 있다. 그러나, 리스너로 등록하는 것은 서비스가 액티비티에 참조를 유지하게 할 것이고, 그리고 만약 프로그래머가 액티비티가 종료하기 전에 리스너로 등록해제를 하지 않았다면, 이것은 가비지 콜렉션 대상에서 제외할 것이고 메모리 누수를 발생시킬 것이다.

void registerListener() {
       SensorManager sensorManager = (SensorManager) getSystemService(SENSOR_SERVICE);
       Sensor sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ALL);
       sensorManager.registerListener(this, sensor, SensorManager.SENSOR_DELAY_FASTEST);
}

View smButton = findViewById(R.id.sm_button);
smButton.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View v) {
        registerListener();
        nextActivity();
    }
});

이제 실수로 엄청난 양의 메모리를 누수 하기가 얼마나 쉬운지 알 수 있는 다양한 메모리 누수를 살펴봤다. 최악에는 메모리 누수가 앱이 메모리를 다 소진하게 하거나 크래시를 유발할 것이지만, 누수가 항상 메모리 소진이나 크래시를 유발하는 것은 아니다. 대신에, 메모리 누수는 많은 양을 차지할 수 있지만 앱의 메모리 공간에 치명적이지 않은 양일 수 있다. 이 경우, 앱은 다른 객체에 할당해야 하는 메모리의 양이 적으며, 그래서 새로운 객체를 할당하는 공간을 확보하기 위해서 가비지 콜렉터가 더 자주 실행할 필요가 있다. 가비지 콜렉션은 매우 큰 작업이고 사용자가 느려지는 것을 느끼게 할 것이다. 액티비티에서 객체를 만들 때 잠재적인 참조 연결을 주의하고 자주 메모리 누수를 테스트해라.

안드로이드 스튜디오 앱 프로젝트가 사용하는 외부 라이브러리 최신 버전 확인하기

안드로이드 스튜디오를 사용해서 앱을 빌드하는 데는 그레들(Gradle)을 사용하고 있다. 그리고 작게는 몇 개에서 많게는 십수 개의 라이브러리를 사용하는 앱들을 흔하게 볼 수 있다. 물론 내가 개발하고 유지하는 앱들도 여러 개의 외부 라이브러리를 사용하고 있다.

이렇게 외부 라이브러리를 사용하다 보니, 개별 라이브러리의 최신 버전을 확인해야 하는 경우가 종종 있다. 이런 경우 라이브러리 프로젝트의 소스(대부분의 경우 Github에서 호스팅하고 있다)를 확인해서 버전이 업데이트 되었으면, 다시 동기화 하고 빌드해서 앱을 확인한다.

이 과정에서 라이브러리 업데이트는 필연으로 발생할 수 있는 문제지만, 라이브러리가 업데이트 되었는지 확인하는 작업은 아주 불편하다. 그래서 안드로이드 스튜디오에서 앱이 사용하는 라이브러리의 최신 버전을 확인할 수 있는 방법을 살펴보자. 인터넷으로 확인해본 결과 플러그인을 사용하는 방법, 안드로이드 스튜디오에서 지원하는 린트(Lint)를 사용하는 방법 그리고 젯브레인에 등록된 라이브러리를 사용하는 방법이 있다.

1. 플러그인을 사용하는 방법

https://github.com/ben-manes/gradle-versions-plugin 사이트에서 플러그인을 다운로드 받아서 설치해서 사용하면 된다.

1.1 예제 Build.xml

apply plugin: 'com.android.application'
apply plugin: 'com.github.ben-manes.versions'

buildscript {
    repositories {
        jcenter()
    }

    dependencies {
        classpath 'com.github.ben-manes:gradle-versions-plugin:0.12.0'
    }
}

android {
    compileSdkVersion 23
    buildToolsVersion "23.0.3"

    defaultConfig {
        applicationId "net.sjava.testapp"
        minSdkVersion 16
        targetSdkVersion 23
        versionCode 1
        versionName "1.0"
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    testCompile 'junit:junit:4.12'
    compile 'com.android.support:appcompat-v7:23.4.0'
    compile('com.mikepenz:materialdrawer:5.2.5@aar') {
        transitive = true
    }

    compile('com.mikepenz:aboutlibraries:5.6.6@aar') {
        transitive = true
    } 
}

1.2 실행

아래의 명령으로 프로젝트가 사용하는 라이브러리의 최신버전을 확인할 수 있다. 그리고 outputFormatter로 xml이나 json을 선택할 수 있다.
C:\dev\TestApp>gradlew dependencyUpdates -Drevision=release -DoutputFormatter=plain

1.3 결과

위 build.xml의 외부 라이브러리 확인결과, 아래와 같이 최신버전이 존재하는 것을 알 수 있다. 그리고, 맨 아래에 리포팅 결과를 txt파일로 저장했다는 것도 알 수 있다.

------------------------------------------------------------
:app Project Dependency Updates (report to plain text file)
------------------------------------------------------------
                                      
The following dependencies are using the latest release version:
 - com.github.ben-manes:gradle-versions-plugin:0.12.0
 - junit:junit:4.12                   
                                      
The following dependencies exceed the version found at the release revision level:
 - com.mikepenz:aboutlibraries [5.6.6  24.0.0-alpha2]
 - com.mikepenz:materialdrawer [5.2.5 -> 5.2.6]
                                      
Generated report file C:\dev\TestApp\app\build/dependencyUpdates/report.txt

2. 린트를 사용하는 방법

안드로이드 스튜디오에서 외부 라이브러리의 최신 버전을 쉽게 확인할 수 있게 린트를 사용해서 최신 버전을 확인할 수 있는 기능을 제공한다. 안드로이드 스튜디오에서 린트로 사용할 수 있지만, 기본으로 선택되어 있지 않아서 설정에서 추가한다.

2.1 린트 옵션 추가

안드로이드 스튜디오에서 Setting > Editor > Inspections 에러 아래와 같이 Newer로 찾으면 Newer Library Versions Available 옵션을 확인할 수 있고, 이 옵션을 선택하자.
setting_screen

2.2 린트를 실행해서 최신 버전의 라이브러리 확인

린트를 실행하는 방법은 상단 메뉴에서 Analyze > Run Inspection by Name…을 선택하고, Enter inspection name 창이 나오면 Newer 를 입력하면 Newer Library Versions Available을 선택할 수 있다. 그리고 Whole 프로젝트를 범위로 선택해서 확인하면, 아래와 같은 결과를 확인할 수 있다.
lint_result

3. 안드로이드 스튜디오 플러그인

안드로이드 스튜디오는 젯브레인(JetBrains)에 배포되어 있는 플러그인을 사용할 수 있다. 그래서 Setting > Plugins > Browse Repositories에 가서 version을 검색하면 Dependencies Version Checker 플러그인을 확인할 수 있고, 이 플러그인을 설치하고 안드로이드 스튜디오를 다시 시작하자. 현재 이 플러그인은 의존성 에러(안드로이드 2.1.1 버전에서 확인)로 사용할 수 없었다.

Remix OS for PC 베타 설치 & Play 스토어 앱 설치

Remix OS는 Jide라는 회사에서 개발하고 있는 또 다른 안드로이드 OS이다. 이 OS는 인텔 칩을 사용하는 기존의 PC에서 안드로이드 앱을 사용할 수 있도록 지원하고 있다. 웹 사이트(http://www.jide.com)에서 보면 알 수 있지만, 안드로이드 X86의 최대 오픈 소스 커뮤니티인 Android-x86(http://www.android-x86.org)과 파트너 쉽을 맺고 있는 것을 볼 수 있다. 그리고 Android-x86 사이트에서도 Remix OS와 파트너 쉽을 맺고 있다는 것을 알리고 있다.

개인적으로 Android-x86을 몇 번 설치해서 사용해 봤지만, 홀로 테마와 비율에 맞지 않는 앱들(창 조절 안 되는 문제)로 인해서 사용하기 불편했었다. 하지만 Remix OS에서는 이런 불편한 점들을 개선해서 안드로이드 OS도 데스크톱에서 쉽고 편하게 사용할 가능성을 제공하게 되었다.
Remix OS의 성능은 웹 사이트(http://www.jide.com/en/remixos-for-pc)에서 확인할 수 있다. 이제 Remix OS 설치와 Play 스토어 앱을 설치해 보자.

1. Remix OS 다운로드
Remix OS는 http://www.jide.com/en/remixos-for-pc#downloadNow 에서 사용자 환경에 맞게 다운로드를 하면 된다. 필자의 경우에는 32bit 랩톱에 설치할 예정이라 “32-bit Legacy BIOS only” 버전을 다운로드 받아서 설치한다. 설치하는 환경은 HP EliteBook 8440P의 랩톱이고, 윈도 10이 설치되어 있다.

remix_os_download
그림 1.1 다운로드 받은 Remix OS 베타 버전의 파일들

위 파일에서 Remix OS Installation Tool.exe를 사용해서 USB로 부팅해서 OS를 설치할 수 있도록 설치를 한다. 그리고 “How to Launch Remix OS for PC.txt” 파일은 설치하는 과정을 설명하는 파일이다.

remix_usb_install
그림 1.2 USB에 Remix OS 설치 화면

위 화면은 USB에 Remix OS를 설치하는데 필요한 ISO 이미지 설정, Type으로 USB Drive, 그리고 Drive의 위치를 선택해서 OK 버튼을 클릭하면 USB에 OS 설치를 완료한다.

2. Remix OS 설치
이제 컴퓨터에 설치해 보자. 설치하는 컴퓨터의 CMOS에서 USB 부팅 우선순위를 하드보다 높힌다음 계속 진행한다.
이제 아래와 같은 화면을 보게된다.

remix_os_install
그림 2.1 설치 화면

위 그림 2.1과 같은 화면이 나오면 하드 디스크에 설치(Resident mode) 또는 Usb Live 모드(Guest mode)로 설치할 수 있다. 필자는 하드 디스크에 설치했다. 이제 설치를 다 하고 부팅을 하면 아래와 같은 화면을 볼 수 있다.

remix_os_select_os
그림 2.2 Remix OS가 추가된 부팅 화면

그림 2.2에서 보듯이, Remix OS가 하드에 설치되어 부트 로더에 등록된 모습을 볼 수 있다. 이제 부팅을 하면서 Remix OS를 선택해서 사용할 수 있는 환경이 되었다.

3. Play 스토어 앱 설치
커스텀 안드로이드 OS를 사용하게 되면 늘 불편한 점이 Play 서비스와 Play 스토어 앱이 설치되어 있지 않다는 것이다. Remix OS에 Play 서비스와 Play 스토어 앱을 설치하는 방법은 Remix OS의 구글 그룹에서 확인할 수 있다. 이 그룹에서 “How to download and install Google Play Store on Remix OS for PC(https://groups.google.com/forum/#!topic/remix-os-for-pc/6jsV0ZB8174)”를 확인해 보면 구글 Play 서비스와 Play 스토어 앱을 설치해 주는 앱(GMSActivator.apk)을 다운로드 해서 설치하고 실행한다.

이 파일을 설치하기 전에 설정 > 보안 > 에서 “알 수 없는 소스”를 선택해야 한다. 그래야 로컬에 다운로드 받은 apk 파일을 설치할 수 잇다.

Screenshot_2016-03-02-04-16-50
그림 3-1, 설정 > 보안  화면

편의를 위해서 이곳에 업로드 해 놨으니 다운로드 받으면 된다. 그리고 이 파일을 압축해제하면 GMSActivator.apk 파일을 보게되고, 이 파일을 설치한다.

GMSActivator.zip

이 앱을 설치하고, 실행하면 아래와 같은 화면을 보게된다.

Screenshot_2016-03-02-04-15-58
그림 3-2, GMSActivator.apk 실행 화면

그림 3-2에서 “INSTALL GOOGLE SERVICES” 버튼을 클릭하면, 필요한 파일을 다운로드 받으면서 설치가 완료한다. 그리고, 부팅을 다시 한번 한다. 이 과정으로 Remix OS를 설치하고 Play 스토어 앱을 설치해서 데스크톱의 환경에서 편리하게 안드로이드 OS를 사용할 수 있게 된다.

Screenshot_2016-03-02-04-15-05

그림 3-3, Remix OS에서 Play 스토어 앱을 실행한 화면 및 설치된 앱들

안드로이드 앱(Apk 파일) 다운로드 서비스

안드로이드 앱을 개발하거나 사용하다 보면 앱 스토어가 업데이트 시켜주는 최신의 앱이 아닌 다른 버전의 앱이 궁금하기도 하다. 다른 버전이라는 것은 출시하지 않은 빌드 버전 또는 출시 버전이 아닌 이전 버전의 앱을 말한다. 그리고 종종 최신 버전의 UI/UX가 궁금한 경우, 이전 버전에서 제공했던 기능이나 UI/UX가 궁금한 경우가 가끔 있다. 그래서 다른 버전의 앱을 다운로드 할 수 있는 방법에 대해서 간략하게 살펴보자.

1. 앱 스토어 버전보다 최근 빌드한 앱
앱 스토어 버전보다 최근에 빌드한 앱을 다운로드 받을 수 있는 서비스이다.
1.1 URL : http://www.apkmirror.com/

2. 앱 스토어 버전의 이전 버전
앱 스토어 버전이나 이전에 서비스했던 앱을 다운로드 받을 수 있는 서비스이다.
2.1 URL : https://apkpure.com/