React Native) 개발용 Dev 앱 분리하기 (Android)

2ast·2024년 3월 30일
3

Android 개발용 앱 분리하기

지난번 iOS 개발용 앱 분리하기에 이어 이번에는 Android 개발용 앱 분리하기를 해보려고 한다. android가 ios보다 훨씬 쉽다.

Flavor 설정하기

android는 빌드 환경 분리를 위한 Flavor라는 기능을 제공하고 있다. 이전 ios에서 configuration을 통해 환경을 분리했던 것처럼, android에서는 staging과 production flavor를 설정해 환경을 분리해보려고 한다.
flavor 설정 방법은 간단하다. android > app > build.gradle 파일에 다음 코드를 추가하면 된다.

...
android {
    ...
    flavorDimensions.add("environment")

    productFlavors {
        staging {
            dimension "environment"
            applicationIdSuffix ".staging"
        }
        production {
            dimension "environment"
        }
    }
    ...
}

먼저 flavor demension을 추가해주고, staging과 production이라는 이름으로 flavor를 정의해주었다. flavor에서는 applicationIdSuffix라는 속성으로 id를 유니크하게 만들어주는 기능도 제공하고 있다. 만약 production app의 application id가 com.sample이라면, 위와같이 설정한 뒤 staging 빌드했을 때 id는 com.sample.staging이 된다.

앱 이름 분기하기

flavor를 통해 앱 이름도 분기해줄 것이다. 안드로이드 앱의 이름은, app > src > main > AndroidMenifest.xml 파일에서 설정할 수 있다. application 태그와 activity 태그에는 android:label 속성이 있는데, 이 속성을 원하는 이름으로 바꿔주면 된다. 빌드시점에 동적으로 할당해주기 위해 manifestPlaceholder라는 것을 사용할 것이다.

    <application
        android:label="${applicationLabel}">
        ...
            <activity
                android:label="${applicationLabel}">
                ...
        </activity>
        ...
    </application>

위 코드는 앱 이름에 applicationLabel이라는 이름으로 placeholder를 배치해준상태로, 이제 빌드타임에 applicationLabel에 값을 할당해주면, 그 값으로 빌드하게 된다. 다시 app > build.gradle로 돌아와 아래와 같이 작성해주면 된다.

...
android {
	...
     defaultConfig {
        manifestPlaceholders = [applicationLabel: "@string/app_name"]
    }
    ...
    flavorDimensions.add("environment")

    productFlavors {
        staging {
            dimension "environment"
            applicationIdSuffix ".staging"
            manifestPlaceholders = [applicationLabel: "Dev_샘플"]
        }
        production {
            dimension "environment"
        }
    }
    ...
}

defaultConfig로 앱의 기본 이름을 할당해주고, staging flavor에 Dev_샘플이라는 이름을 할당해주어 placeholder를 덮어써주었다. (참고로 defaultConfig에 보이는 @string/app_name은 미리 선언해놓은 문자열 셋에서 app_name을 들고오는 코드로, 파일의 위치는 app > src > main > res> values > strings.xml이다.)

이로써 android에서 개발용 앱 분리가 완료됐다. build 설정을 변경했으니, android studio에서 sync project를 실행한 뒤 build variants를 확인해보면, flavor + buildTypes 조합으로 빌드 환경을 선택할 수 있게 된 것을 확인할 수 있다.

이제 production이랑 staging을 각각 빌드해보면 아래와 같이 독립적인 앱으로 설치된다.

Advenced Step

기본적인 설정은 끝났지만, 각 프로젝트 환경에 따라 추가적으로 셋팅해줘야하는 부분들이 있다. 이번에는 그 대응 작업을 해보려고 한다.

Firebase google-service.json 파일 분기하기

firebase를 적용하기 위해서는 firebase console에 앱을 추가하고, google-service.json 파일을 다운로드 받아서 프로젝트에 배치해주어야 한다. 여기서 문제는 배포용 앱과 개발용 앱의 package name이 다르기 때문에, google-service.json 파일의 호환이 불가능하다는 점이다. 즉, 빌드타임에 적절한 파일을 배치해주어야한다. 다행인 점은 flavor에서 이런 기능을 제공해주고 있다는 사실이다.
먼저 firebase console에서 android 개발용 앱을 추가하고, google-service.json을 다운로드 받아준다. 그리고 project의 android > app > src 경로에 flavor의 이름과 동일한 폴더를 만들어준다. 이번 케이스를 예시로 들자면, production과 staging이라는 이름의 폴더를 만들어주면 된다. 그리고 그 안에 각 환경에 맞는 google-service.json 파일을 넣어주기만 하면 끝이다.

이렇게만 설정해주면, 빌드 시점에 각 flavor에 맞는 경로를 찾아가, 알아서 파일을 참조한다. 여기서 주의할 점은, 폴더면은 반드시 소문자로구성되어야한다는 점이다. "Production", "Staging"과 같이 폴더명에 소문자가 아니라 다른 문자가 포함되면 경로를 제대로 인식하지 못해 파일을 찾지 못하는 버그(기능인가..?)가 있다

firebase app distribution 업로드

보통 android 앱을 테스트할 때, 우선 AAB로 빌드하여 firebase app distribution에 업로드하게 되는데, 이때 개발용 앱의 업로드가 실패할 수도 있다. 이 문제는 사실 flavor 설정과는 무관한 play store의 정책때문인데, 스토어에 하나 이상의 트랙에 정식 배포된 앱만 AAB파일을 firebase app distribution에 올릴 수 있기 때문이다. 이제 막 새롭게 만든 개발용 앱은 기존 앱과 전혀 별개의 앱으로 취급되기 때문에 우선 테스트 트랙이라도 올려서 승인을 받아야한다. 이 과정이 귀찮았던 나는 그냥 테스트 앱의 경우 APK로 빌드해서 업로드해주기로 했다.

./gradlew clean assembleStagingRelease

당장 테스트가 필요하다면 이런식으로 우회할 수도 있고, 추후 승인이 완료된 뒤, AAB 빌드로 바꾸면 된다.

마치며

이렇게 ios와 android staging app 분리 포스팅이 끝났다. 내가 까먹을거 같아서 기록용으로 작성하는 블로그지만, 다른 사람들이 보고 도움을 받았으면 좋겠다는 마음으로 조금 더 자세하게 작성해봤다. 찾아보면 staging 버전 앱인 경우 app iocn을 바꾼다거나, 인앱 화면에 dev 라벨을 띄운다거나 하는 식으로 조금 더 차별화를 더하는 방법도 있으니 필요하다면 찾아서 적용해봐도 좋다.
여담이지만, 알 수 없는 velog 오류로 3시간 걸려 작성한 ios 개발용 앱 분리하기 게시글이 증발해버리는 바람에 다시 2시간을 들여 업로드하는 헤프닝이 있었다. velog가 크게 업데이트 된 이후로 로그인이 풀린다거나, 특정 메뉴가 안들어가진다거나, 느려진다거나 하는 이슈가 많아진 느낌이었는데, 이번에 글이 날아가는 경험을 하면서 velog에 대한 회의감이 커졌다. 조만간 다른 플랫폼으로 이사갈지도 모르겠다.

profile
React-Native 개발블로그

2개의 댓글

comment-user-thumbnail
2024년 4월 2일

같이 가실래요?

1개의 답글