Android 권장 요구 사항
우리는 PlayStore에 실제로 배포하기 전에 QA를 하거나 여러 사용자에게 테스트를 해봐야 할 필요가 있습니다.
그래서 앱을 실제 게시하기 전에 데모 APK를 배포하여 테스트합니다.
데모 APK를 배포하는 방법으로는 크게 Play Store의 내부테스트를 이용하는 것과 Firebase 베타 테스터 배포가 있습니다.
저희는 우선 Firebase를 이용했습니다. 모두 데모 APK 배포가 처음이었기에 더 쉽다는 Firebase를 선택했습니다.
APK를 추출하여 Firebase에 올리면 등록된 테스터가 해당 APK를 다운 받는 방식으로, 공유 방식 자체는 슬랙에 APK를 올리는 것과 다르지 않습니다. 테스터를 등록하고 그룹으로 관리하며 메일을 보내 알려준다는 점에서 차이가 있다고 생각합니다.
하지만 추후 데모 APK 배포 방식을 PlayStore 내부테스트로 변경했습니다.
APK 파일을 직접 다운 받아 설치하는 방식보다 PlayStore에서 바로 설치할 수 있는 점이 장점이라고 생각됐기 때문입니다.
당시 진행했던 테스트 링크
그러므로 향후 데모 APK 배포는 PlayStore 내부테스트로 진행하게 될 예정입니다.
저희는 도메인 테스트와 뷰모델 테스트를 고려했지만 시간 상의 문제로 뷰모델 테스트는 진행하지 못했습니다.
그래서 도메인 유닛 테스트만 진행하였습니다.
github action을 통해 테스트 검사를 자동화 시켰으며 yml파일 에 규칙이 작성되어있습니다.
도메인 유닛 테스트뿐만 아니라 ktlint, 빌드 테스트 또한 자동화 시켰습니다.
검사는 각 feature 브랜치에서 develop 브랜치로 pull request를 생성했을 때 발생합니다.
이를 통해 ktlint가 맞지 않거나, 빌드가 성공하지 않거나, 유닛 테스트가 성공하지 않으면 develop 브랜치에 머지하지 않도록 합니다.
- 커스텀 데이터 로깅을 통해 사용자의 앱 사용 통계 제공
- 앱의 비정상 종료를 목록화해 상황 정보 제공
- 이를 통해 비정상 종료 원인 유추 가능
- 모니터링을 위한 커스텀 데이터 로깅 설계 필요
- 서버 통신 모니터링
서버 연결 시 발생할 수 있는 다양한 상황들을 지속적으로 모니터링함으로써 유지보수에 도움을 받음 서버 연결 에러 시 해당 에러 LiveData의 observer에 로깅 달기
나아가 안드로이드 팀은 proguard를 통해 난독화를 진행했습니다.
난독화 툴에 대해 찾아본 결과 proguard, dexguard, allatori가 대표적이었습니다.
dexguard와 allatori는 유료이므로 안드로이드 스튜디오에서 무료로 제공하는 proguard를 사용했습니다.
proguard는 식별자를 난독화해줍니다.
proguard는 build.gradle에서 설정할 수 있으며 저희는 릴리즈 모드에서만 적용되도록 설정했습니다.
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
}하지만 난독화를 하면 안 되는 파일들도 존재하는데요, 해당 파일들을 proguard-rules.pro 파일에서 제외해줍니다. 저희는 외부 라이브러리인 `kakao sdk`, `OkHttp3`, `Retrofit2`, `Glide`에 대해서 처리를 해주었습니다.
저희는 아래와 같은 형식으로 버전을 기록하고 있습니다.
Major.Minor.Patch (ex 1.0.0)
- 이전 버전과 호환되는 버그 픽스의 경우 Patch를 증가시킵니다.
- 이전 버전과 호환되는 새로운 기능의 경우 Minor를 증가시킵니다. (Patch를 0으로 변경)
- 이전 버전과 호환되지 않는 변경의 경우 Major를 증가시킵니다. (Minor와 Patch를 0으로 변경)