3편까지는 어떤 크래시가 있고 어떻게 막는지를 다뤘다.그런데 운영 중 더 자주 부딪히는 건 이미 크래시가 난 상태에서 원인을 찾는 일이다.특히 막막한 시나리오가 있다.release 빌드, 사용자 단말, Crashlytics에서 받은 native 크래시 로그, 심볼은 stripped 상태.손에 있는 건 이렇게 생긴 시그널 번호와 fault 주소, 그리고 주소만 찍힌 backtrace뿐이다.signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0backtrace: #00 pc 0000000000041a70 /system/lib64/libc.so #01 pc 00000000000123bc /data/app/com.example/lib/arm64/libnat..

얼마 전 운영중인 앱이 native 코드 문제로 런타임에 죽었다.버퍼를 다루는 함수였다.Ghidra로 디스어셈블해 들어가다 __stack_chk_fail 호출 경로를 발견했다.스택 카나리가 buffer overflow를 잡아 죽인 거였다.크래시는 한 곳에서 막는 게 아니라 여러 층에서 걸러진다.카나리가 잡은 건 그중 한 층이었다.이번 편은 나도 공부하면서 그 층들을 정리해본다.미리 말하자면, 이번 편은 가볍게 읽고 넘어가도 된다. 이유는 이 것들을 본 순간 이미 당신의 앱은 죽어있다.본론으로 들어가, 2편에서 본 크래시들(SIGSEGV, SIGABRT, SIGBUS 등)을 막는 방어는 세 층으로 나뉜다.1층은 컴파일러와 런타임이 자동으로 해주는 것. NDK 빌드 시 이미 켜져 있음.2층은 도구로 잡는 것..

native 크래시를 처음 만났을 때 가장 막막했던 건 어디서 났는지가 안 보인다는 점이었다.Java/Kotlin이었으면 NullPointerException이 어느 파일 몇 번 라인에서 났는지 stack trace에 다 찍힌다.native는 signal 11 (SIGSEGV) 같은 시그널 번호와 메모리 주소만 있었다.NDK 코드를 직접 안 짜도 이 로그는 만난다.의존하는 라이브러리가 내부적으로 native면 거기서 터진 게 시그널로 올라온다.이번 편은 그 시그널 종류를 정리해본다.시그널이 뭔지부터native 크래시는 전부 시그널로 옴.그래서 시그널이 뭔지부터 봄.시그널은 Unix 계열 OS가 프로세스에게 뭔가 잘못됐다고 알리는 메커니즘임.Android도 Linux 기반이라 같은 메커니즘을 씀.nativ..

요새 온디바이스 AI 작업을 하고 있다.모델 추론 코드를 iOS와 Android에서 공용으로 쓰려고 native 모듈로 빼는 중.HAL 쪽도 native가 필요.오랜만에 NDK를 다시 만지다 보니 한동안 잊고 있던 것들이 다시 보였다.그래서 정리해봤다. 이번 편은 NDK를 왜 쓰는지, Java/Kotlin과 뭐가 다른지까지이다.NDK를 왜 쓰는가대부분의 Android 개발은 NDK 없이 끝남.화면 그리고 네트워크 호출하고 데이터 다루는 데는 Java/Kotlin만으로 부족함이 없음.그러다 어느 시점에 NDK가 강제되는 상황을 만남.보통 네 가지 중 하나임.첫째는 성능. AI 모델 추론, 미디어 인코딩/디코딩, 암호화 같은 무거운 연산은 JVM 위에서 한계가 있음. TensorFlow Lite, ONNX ..

Google Play Console에서 Android 개발자 인증 관련 메일이 왔다. 2025년 8월에 발표된 제도가 Play Console에 실제 등록 UI로 열렸길래, 앱 개발자 입장에서 뭘 해야 하는지만 추려서 정리했다.핵심 3줄2026년 9월부터 브라질·싱가포르·인도네시아·태국에서는 등록 안 된 앱은 인증 안드로이드 기기에 설치할 수 없다. 한국 포함 나머지는 2027년 이후.Play 스토어에만 배포하면 자동 등록이라 거의 할 게 없다.Play 외부(사이드로딩·제3자 스토어)로도 배포한다면 직접 등록해야 한다.왜 이 제도가 생겼나 (짧게)Google 발표문은 "Play 외부 사이드로딩 소스의 멀웨어가 Play 대비 50배 이상"이라는 숫자를 근거로 든다. 이 격차의 상당 부분은 Play의 권한 심..

1편에서 양자화로 모델을 92% 줄였고, 2편에서 프루닝과 지식 증류까지 실험해봤다. 경량화는 끝났다.그러면 주제인 온디바이스는?Python에서 77.88% 나온 INT8 모델이 Android 단말에서도 같은 정확도와 속도를 낼지, 직접 올려봤다.프레임워크 선택내가 고른 건 LiteRT(구 TensorFlow Lite)다. 이유는 단순했다. 학습을 Keras로 했으니 변환이 .tflite 한 번으로 끝나고, INT8 양자화된 모델을 그대로 들고 올 수 있고, GPU Delegate까지 바로 붙는다. 선택이라기보다는 기본값이었다.선택지를 비교하긴 했다. Android 모바일 배포에서는 LiteRT / ONNX Runtime / ExecuTorch 셋이 주로 꼽힌다.구분LiteRTONNX RuntimeExe..

Google Play의 새 배터리 정책, WorkManager의 숨겨진 wake lock, 그리고 다시 foreground service로 돌아간 이야기.무슨 일이 있었나2025년 11월, Google이 Android Vitals에 새로운 core vitals 지표를 추가했다. "Excessive partial wake locks" — 과도한 부분적 wake lock 사용.기준은 이렇다. 24시간 중 partial wake lock 누적 사용 시간이 2시간을 넘으면 해당 세션을 "excessive"로 판단한다. 28일 동안 전체 사용자 세션의 5%가 이 기준을 넘으면, Play Store 추천에서 제외되고 스토어 페이지에 "배터리를 많이 소모하는 앱"이라는 경고가 붙는다.2026년 3월 1일부터 시행. ..

셀카 정리 앱을 만들었다. 개발 1주, 수정 1주. 출시하고 3개월 됐다. 다운로드 10회, 매출 0원.같은 고민을 하고 있을 누군가에게 도움이 될 수도 있을 것 같아서 과정을 정리해본다.타겟을 다시 정하고, 이름 바꾸고, 기술적으로 손보면서 깨달았다. 처음부터 순서가 틀렸다.셀카픽 - Google Play심심하면 한번 써봐주세요...아이디어: 비슷한 사진을 찾아주자구글 포토나 삼성 갤러리에 "비슷한 사진 정리" 기능이 있다. 직접 써봤다. "완전히 똑같은 사진"만 잡는다. 연사로 찍어도 조금씩 다르니까 못 잡는다.여기서 기회가 보였다. "똑같은 사진"이 아니라 "비슷한 사진"을 찾아주면 연사 셀카를 잡을 수 있겠다 싶었다. 10장 찍고 1장 고르는 그 과정을 AI가 대신해주는 앱.나중에 알았는데 갤럭시..