그것은 바로
이제 ADB ADB가 APK를 실제 휴대폰과 연결하는 가장 짧은 경로가 됩니다. Capacitor 또는 Ionic과 함께 작업하는 경우 이 명령어는 편의 명령어에서 벗어나 일반적인 피드백 루프의 일부가 됩니다. 브라우저가 알려주지 않는 native 플러그인, 권한, 스플래시 동작, 깊이 링크, WebView의 특이한 점, 그리고 모든 다른 것에 대한 확인 방법이 됩니다.
내용목록
- ADB 설치는 테스트를 위한 가장 직접적인 경로입니다.
- ADB 환경을 준비하는 방법
- ADB APK 설치 워크플로우의 핵심
- ADB 설치 플래그를 마스터하는 방법
- 일반적인 설치 실패 문제 해결
- Capacitor 개발자를 위한 완전한 예제
ADB 설치는 테스트에 가장 직접적인 경로입니다.
Android 앱을 개발할수록, Play 스토어를 테스트 경로로 사용하지 않게 됩니다. 이는 일상적인 반복 개발에서 너무 느립니다. 특히, 권한提示, 플러그인 브리지 문제, 또는 단일 장치에서만 나타나는 레이아웃 버그를 확인할 때尤其 그렇습니다.
ADB 2008년 Android 1.0에서부터 Android의 일부로 존재했습니다. __CAPGO_KEEP_0__그리고 여전히 APK를 장치로 직접 배포하는 표준 방법입니다. 2024년 Android의 글로벌 시장 점유율은 70%를 넘었습니다.이러한 워크플로우가 모바일 팀이 광범위한 장치 혼합에 작업하는 이유 중 하나는 공식 Android Debug Bridge 문서에서 언급한 것입니다. 실제 개발을위한 가치가 간단합니다:.
스토어의 마찰을 피합니다:
- 리뷰 큐가 없고 테스트 트랙 지연이 없습니다. 실제로 테스트하는 건 정확히 생성한 빌드입니다:
- debug, 릴리스 후보, 또는 한 번만 사용하는 branch 빌드. 실제로 즉각적인 feedback을 받습니다:
- 설치, 런칭, 로그를 검사, 반복. 실제 규칙:
__CAPGO_KEEP_0__ 이 APK가 물리적 안드로이드 기기에서 작동하는지 여부에 대한 질문이면
adb install일반적으로 첫 번째 대답이 되어야 합니다.
Capacitor와 Ionic 작업에서 이 점은 더욱 중요합니다. 브라우저 실행은 웹层 렌더링 여부를 알려주지만 안드로이드 권한 처리가 작동하는지, 플러그인 초기화가 깨끗하게 진행되는지, 기존 설치에 대한 앱 업데이트가 저장된 데이터를 깨뜨리지 않고 진행되는지 여부는 알려주지 않습니다.
명령어 자체는 간단합니다:
adb install path/to/app.apk
명령어의 문법이 유용한 이유는 아니지만, 제어권이 있습니다. 직접 설치할 수 있고 기존 앱 위에 재설치할 수 있으며, 이전 빌드 테스트 및 패키지 수준 오류 진단을 위해 터미널을 떠나지 않고 진행할 수 있습니다. 따라서 ‘getting started’ 단계가 끝난 후에도 ‘ADB 설치 APK’라는 구문이 실제 팀 워크플로우에서 계속 나타나는 이유입니다. ADB를 위한 환경 설정 ADB 설치 문제가 대부분 시작 단계에서 발생하는 것은 설치 문제가 아니라 환경 설정 문제입니다. 기계가 대상 기기를 찾을 수 없거나, 기기 권한이 인증되지 않았거나, OEM이 추가한 설정이 사용자에게 알려지지 않은 경우가 많습니다.
개발자를 위한 안드로이드 디버그 브리지 환경 설정을 위한 7단계 가이드입니다.
기계에 플랫폼 도구 설치 adb, the device isn’t authorized, or the OEM added one more toggle you didn’t know about.
Install Platform Tools on Your Machine
Android Studio를 완전히 설치할 필요가 없습니다. ADB를 실행하려면 SDK 플랫폼 도구가 필요합니다.
그리고 터미널에서 그들이 어디에 있는지 알 수 있어야 합니다.
- Windows, macOS, Linux에서 가장 깨끗한 설정은 동일합니다: Google에서 플랫폼 도구를 다운로드하세요.
- 압축을 풀어 안정적인 위치에 저장하세요.
- 폴더를 PATH에 추가하세요. 그럼
adb어디서든 터미널 창에서
If you’re setting up a Capacitor machine from scratch, this 안드로이드 Capacitor 앱 설정 가이드 __CAPGO_KEEP_0__은 더 광범위한 도구 체인에 유용한 동반자입니다.
터미널을 사용하여 명령어가 사용 가능한지 확인하세요:
adb version
버전이 반환되는 대신 “명령어를 찾을 수 없음”이 반환되면 잘 진행되고 있습니다.
몇 가지 플랫폼에 특화된 습관이 도움이 됩니다:
- Windows: Platform Tools를 변경되지 않는 경로에 넣고, 환경 변수에 해당 폴더를 추가하세요.
- macOS: shell 프로파일에 폴더 경로를 추가하세요.
.zshrc. - Linux: shell config에 동일한 경로를 추가하고, shell을 다시 로드하세요.
디바이스에서 올바른 설정을 활성화하세요
기기 측면도 중요합니다. 중요한 전제 조건은 USB 디버깅을 활성화하는 것입니다. USB 디버깅 을 통해 개발자 옵션, 개발자 옵션을 활성화하려면빌드 번호를 7번 탭하세요. Xiaomi 기기에서 MIUI를 사용하는 경우, USB를 통해 설치 를 활성화해야 할 수도 있습니다..
이 설명서에 설명된 대로
- ADB 설정에 대한 dev.to 참조를 참조하세요.이것은 짧은 체크리스트입니다.개발자 옵션을 활성화하세요. 7번 빌드 번호를 7번 탭하세요.
- USB 디버깅을 활성화하세요: 이 설정은 ADB가 필요합니다.
- OEM 추가 항목을 감지하세요: Xiaomi는 classic 예시입니다.
- 신뢰할 수 있는 케이블로 연결하세요. 충전 전용 케이블은 시간을浪費합니다.
폰의 프롬프트도 케이블과 마찬가지로 중요합니다. 'USB 디버깅을 허용합니까?'를 놓치면 컴퓨터는 장치를 볼 수 있지만 ADB는 여전히 사용할 수 없습니다.
첫 연결 시 안드로이드는 컴퓨터를 신뢰할지 여부를 묻습니다. 이를 수락하고, 개발용 컴퓨터라면 영구적으로 허용하세요. 이 프롬프트를 건너뛸 경우 나중에 워크플로우가 실패하고 더 이상 명확하지 않게 보일 것입니다.
ADB APK 설치 워크플로우의 핵심입니다.
설정이 완료되면 설치 경로는 짧습니다. 일반적인 실수는 다음 명령어에 성공할 가능성이 있는지 알려주는 한 가지 확인을 건너뛰는 것입니다.
설치하기 전에 장치 상태를 확인하세요.
먼저 이 명령어를 실행하세요.
adb devices
연결된 시리얼 번호와 건강한 장치 상태를 확인하고 싶습니다. 만약 장치가 비인가 상태로 보인다면, 설치를 시도하기 전에 권한을 설정하세요.
debug, QA, 및 릴리즈 후보 출력을 다루는 팀에게는, 어떤 종류의 빌드를 푸시하는지 명확하게 하기에도 도움이 됩니다. 이 설명서의 모바일 앱 빌드 유형 은 폴더에 비슷한 이름의 APK가 많을 때 좋은 참고 자료입니다.
설치 명령어를 실행하세요.
기본 명령어는 간단합니다:
adb install path/to/your-app.apk
경로에 공백이 포함된 경우, 쉘에서 따옴표로 경로를 감싸세요. APK가 현재 폴더에 있다면, 명령어는 더 짧아집니다:
adb install app-debug.apk
정상적인 실행은 터미널에 스트리밍 설치 메시지와 성공 메시지를 보여줍니다. 이 출력은 패키지 매니저가 APK를 수락하고 설치를 완료했음을 확인합니다.
실행 흐름을 직접 확인하고 싶다면, 이 설명서를 참조하세요:
스트리밍 설치가 수동 푸시 및 Pm 설치보다 좋은 이유
아래에서 보는 것과 같이, adb install 파일을 복사하는 것보다 더 많은 일을 하고 있습니다. 내부적으로 APK를 /data/local/tmp로 푸시하고 pm install를 호출하고, 그 후 임시 파일을 삭제합니다. 스트리밍 워크플로우는 다음 터미널 출력에 반영됩니다. “스트리밍 설치 중…” 를 따릅니다. “성공”이후, 구현 세부 사항이 이전 설정 참조에서 요약된대로입니다.
그것이 중요합니다. 그것은 이전에 두 단계의 습관인 adb push 를 호출하기 전에
- 를 호출하는 것보다 더 깨끗합니다. 일상적인 실무에서 스트리밍 설치에는 몇 가지 이점이 있습니다: 수동 작업이 덜 필요합니다: 한 명령어로 전송 및 설치를 처리합니다.
- 장치 클러스터를 줄이기: 임시 파일이 자동으로 삭제됩니다.
- 오류를 줄이기: 파일을 잘못 밀어 넣거나 다른 파일을 설치하는 일을 피할 수 있습니다.
사용할 수 있다면
adb install사용하세요. 수동 푸시 및 셸 설치는 특수한 경우에 유용하지만, 일반적인 앱 테스트를 위한 기본 경로는 아닙니다.
ADB 설치 APK 워크플로우의 핵심 루프는 다음과 같습니다: 장치 확인, 설치 실행, 성공 확인, 앱 실행, 다음 빌드 후 반복.
빠른 워크플로우를 위한 Adb Install Flags 마스터하기
기본 명령어는 APK를 폰에 가져옵니다. 플래그는 개발을 위한 실제 프로세스인지, 개발자가 싸우게 하는지 결정합니다.
일반적인 Adb Install Flags 및 사용 방법
| 플래그 | 설명 | 일반적인 사용 사례 |
|---|---|---|
-r |
이미 설치된 앱을 재설치하여 데이터를 유지할 수 있는 경우 | 일일 디버그 빌드에 대한 반복 |
-d |
버전 다운그레이드 허용 | rollback 시나리오 또는 이전 빌드 테스트 |
-g |
설치 시간에 런타임 권한 부여 | 카메라, 저장소, 위치 및 유사한 기능을 위한 테스트 속도 향상 |
정규 개발에서 가장 중요한 플래그는 -r.
그것을 사용하지 않으면 이미 설치된 패키지를 업데이트할 때 자주 실패하는 이유는 Android가 새로운 APK를 대체로 대체하려고 시도하는 대신 충돌 설치 시도로 간주하기 때문입니다. 따라서 많은 개발자들은 adb install -r app-debug.apk 기본적인 근육 기억으로 만듭니다.
일상 개발에서 중요한 플래그는
-r 테스트 중인 Capacitor 앱과 몇 시간에 걸쳐 여러 번 빌드할 때 앱을 매번 삭제하는 것은 느리고 유용한 지역 상태를 삭제합니다. 재설치하면 계속 진행할 수 있습니다.
-d 는 상황에 따라 사용되지만 정말 필요할 때는 정말 필요합니다. 그것은 회귀 테스트, 롤백 연습, 또는 이전 빌드가 레거시 데이터베이스를 올바르게 열 수 있는지 확인하는 데 유용합니다.
-g 는 삶의 질을 향상시키는 플래그입니다. 앱이 권한을 조기에 접촉하면 자동 승인은 장치 설정에서 반복적인 탭을 제거합니다. 그것은 권한 테스트를 대신할 수는 없지만 설치 및 런칭을 빠르게 진행할 때 유용합니다.
몇 가지 combination이 자주 발생합니다:
adb install -r app-debug.apk
adb install -r -g app-debug.apk
adb install -r -d older-build.apk
모든 플래그에는 트레이드 오프가 있습니다. 편리함은 실제 사용자 조건을 숨길 수 있습니다. 만약 자동 승인을 항상 사용하면 런타임 권한의 edge case를 놓치게 될 수 있습니다. 만약 항상 이전 데이터 위에 재설치하면 첫 번째 런칭 문제를 놓치게 될 수 있습니다.
경험이 많은 팀은 일반적으로 습관을 나누어 사용합니다:
- 빠른 루프 빌드: 사용
-r때때로-g. - 새로운 상태를 확인하는 경우: 먼저アンイン스톨하고, 그 다음에 새로 설치합니다.
- 롤백 테스트: 사용
-d버전 이동이 테스트 대상일 때만.
CLI 개발의 더 넓은 리프레시를 원한다면, Capacitor 개발에 대한 이 Capacitor __CAPGO_KEEP_1__ 명령어와 수정사항에 대한 안내서를 참조하세요. Capacitor CLI의 일반적인 명령어와 수정사항 일반적인 설치 오류 해결
ADB는 신뢰할만큼 안정적이지만, 반복적인 설치 오류는 일반적으로 특정 문제를 나타낸다. 문제를 해결하는 데 도움이 되는 것은 오류를 무작위로 처리하지 않는 것이다. 오류는 주로 인증, 패키지 교체 및 패키지 식별과 관련이 있다.
ADB 설치 오류와 개발자용 해결책을 위한 일반적인 Android Debug Bridge (ADB) 오류 해결 목록.
증상:
표시
adb devices원인: 전화가 컴퓨터를 아직 신뢰하지 않았거나, 프롬프트가 취소되었다.unauthorized
해결 방법은 이 순서로 진행하세요:
__CAPGO_KEEP_0__
- 장치에 다시 연결하세요. 그리고 잠금 화면을 닫으세요.
- 휴대폰에서 RSA 인증 요청을 찾으세요. 휴대폰에서.
- 인증 요청을 승인하세요., 개발 머신에 대해 항상 허용 옵션을 사용하는 것이 좋습니다.
- 아직도 복구되지 않으면 ADB 서버를 다시 시작하세요:
adb kill-server
adb start-server
이것은 터미널에서 문제를 기술적으로 보이게 하지만 실제로 문제는 휴대폰 자체에 종종 있습니다.
패키지가 이미 존재할 때
증상:
INSTALL_FAILED_ALREADY_EXISTS
이것은 일반적으로 existing 패키지에 대해 replace flag를 사용하지 않고 설치하려고 할 때 발생합니다. 이 일반적인 함정은 ADB 설치 오류에 대한 이 스택 오버플로우 토론에서 문서화되어 있습니다. Stack Overflow.
가장 빠른 해결책은:
adb install -r app-debug.apk
업그레이드 대신 정리 설치가 필요하다면 먼저 제거하세요:
adb uninstall your.package.name
정기적인 반복을 위해 재설치 경로를 사용하십시오. 제거는 지역 앱 상태를 지우거나 첫 번째 실행 동작을 확인하기 위해만 사용하십시오.
서명과 이전 패키지 상태가 충돌할 때
어떤 실패는 APK 파일 자체에 관한 것이 아닙니다. 그것은 패키지에 대한 Android가 기억하는 것에 관한 것입니다.
두 가지 패턴이 자주 나타납니다:
- 서명 불일치: 설치된 앱이 APK를 설치할 때 사용한 키와 다릅니다.
- 중복 패키지 상태: 패키지 잔해가 제거 후에도 다음 설치를 막습니다.
두 번째 하나는 특히 짜증스럽습니다. 성공적으로 제거된 것처럼 보이지만, 새로운 Android 버전에서 유산된 패키지 상태가 INSTALL_FAILED_DUPLICATE_PACKAGE를 트리거할 수 있습니다.
실질적인 진단 흐름은 다음과 같습니다:
- 먼저 패키지의 정체성을 확인하세요: 패키지 이름이 당신이 생각하는 것과 일치하는지 확인하세요.
- 다음으로 서명 일관성을 확인하세요: debug-signed 및 release-signed 빌드는 서로 깨끗하게 대체되지 않습니다.
- 그 다음 설치된 패키지를 제거하세요: 일반적인 언인스톨 경로를 사용하세요.
- 오류가 지속된다면: 이것을 오류로 간주하세요. 패키지 상태가 오래되어 있는 것이 아니라, ADB의 랜덤 오류입니다.
debug APK가 일반 개발 도구를 통하지 않고 분포되는 경우에 또 다른 문제가 있습니다. 일부 팀에서는 ADB를 통해 설치되는 동일한 빌드가 실패하는 것을 발견합니다. 하지만 메시징 또는 이메일을 통해 수동으로 시드 로드하는 경우에는 성공합니다. 이 문제는 Android의 debug-signed 앱에 대한 컨텍스트에 의한 검증과 관련이 있습니다. 이에 대한 자세한 설명은 Android 앱 설치 오류를 해결하는 방법에 대한 가이드에서 설명하고 있습니다. 실제로 QA 팀은 내부 디버그 배포를 위해 ADB를 사용하는 것이 좋습니다. ad hoc 수동 시드 로드에 의존하는 대신.guide to resolving app install errors on Android
Field note: ADB를 통해 빌드가 설치되지만 수동으로 탭을 클릭하여 설치되지 않으면 APK가 깨진 것으로 생각하지 마십시오. 서명 컨텍스트와 설치 경로를 먼저 확인하십시오.
Capacitor 프로젝트가 네이티브 및 웹层에서 빌드 및 배포 문제를 지속적으로 발생하는 경우, 이 Capacitor 프로젝트에서 발생하는 안드로이드 빌드 오류를 해결하는 데 도움이 되는 이 트러블 슈팅 가이드를 가까이 두고 있어야 합니다. Capacitor 안드로이드 빌드 오류 해결 가이드 __CAPGO_KEEP_0__ 개발자들을 위한 완전한 예시
Capacitor 프로젝트에서 터미널 루프는 일반적으로 짧습니다. 네이티브 파일을 동기화하고 안드로이드 앱을 빌드한 후 연결된 장치에 결과 APK를 푸시합니다. 안드로이드 스튜디오를 열지 않는 한 네이티브 디버깅이 필요하지 않습니다.
In a Capacitor project, the terminal loop is usually short. You sync native files, build the Android app, and push the resulting APK to a connected device without opening Android Studio unless you need native debugging.
일반적인 안드로이드 빌드 단계에서 디버그 APK를 빌드한 후 대체를 허용한 채로 설치하십시오.
npx cap sync android
이 워크플로우는 많은 팀이 사용하는 이유입니다. 이 워크플로우는 피드백 루프를 단단하게 유지하기 때문입니다.
adb install -r android/app/build/outputs/apk/debug/app-debug.apk
CapacitorJS 앱에서, 팀은 차등 업데이트를 배포합니다. CapacitorJS 앱 adb install __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ 설치 가이드입니다. Android 기반 모바일 팀의 78%가 실시간 JavaScript 및 CSS 수정을 위해 Play Store 제출보다 __CAPGO_KEEP_0__을 선호한다고 IBM 연구에서 발견했습니다. 이 비디오 참조는 __CAPGO_KEEP_0__ 기반 APK 설치에 대한 이니셔티브 워크플로우에 대한 설명입니다. 이 __CAPGO_KEEP_0__ 설치 가이드는 프로젝트 설정 단계를 설정하는 경우에 적합한 출발점입니다..
Capgo를 사용하는 팀이 JavaScript, CSS, config 및 asset 수정을 앱 스토어 리뷰 대기 없이 배포하고 싶다면 __CAPGO_KEEP_0__는 그 용도로 설계되었습니다. Capacitor CLI installation guide 작성자
If your team uses Capacitor and wants to ship JavaScript, CSS, config, and asset fixes without waiting on app store review, Capgo Capgo를 사용하는 팀이 JavaScript, CSS, config 및 asset 수정을 앱 스토어 리뷰 대기 없이 배포하고 싶다면 Capgo는 그 용도로 설계되었습니다.
