애플리케이션 기본 항목

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

Android 앱은 Kotlin, Java 프로그래밍 언어, C++ 언어를 사용하여 작성할 수 있습니다. Android SDK 도구는 APK 또는 Android App Bundle로 변환할 수 있습니다.

Android 패키지는 .apk 접미사가 있는 보관 파일이며 필요한 Android 앱의 콘텐츠로서, Android에서 제공한 앱을 설치하는 데 사용하는 기기 수

Android App Bundle은 접미사 .aab가 있는 보관 파일이며 Android 앱 프로젝트의 콘텐츠(여기에 필요하지 않은 일부 추가 메타데이터 포함)를 런타임 환경입니다 AAB는 게시 형식이며 Android 기기에 설치할 수 없습니다. 그것은 APK 생성 및 서명을 이후 단계로 연기합니다.

Google을 통해 앱을 배포하는 경우 예를 들어, Google Play의 서버는 리소스 및 리소스만 포함하는 최적화된 APK를 생성합니다. 앱 설치를 요청하는 특정 기기에서 요구하는 코드가 있어야 합니다.

각 Android 앱은 다음 Android 보안 기능을 사용할 수 있습니다.

• Android 운영체제는 멀티 사용자 Linux 시스템으로, 여기서 각 앱은 있습니다.
• 기본적으로 시스템은 각 앱에 고유한 Linux 사용자 ID를 할당하며 앱에 알려지지 않은 시스템일 수 있습니다. 시스템은 해당 앱에 할당된 사용자 ID만 액세스할 수 있습니다.
• 각 프로세스에는 자체 가상 머신 (VM)이 있으므로 앱의 코드가 사용할 수 있습니다.
• 기본적으로 모든 앱이 앱 자체의 Linux 프로세스에서 실행됩니다. Android 시스템이 시작됨 해당 프로세스를 실행해야 하는 모든 구성요소를 알 수 있으며 더 이상 또는 시스템이 다른 앱을 위해 메모리를 복구해야 하는 경우 일어날 수 있습니다.

Android 시스템은 최소 권한의 원칙을 구현합니다. 즉, 각 앱은 기본적으로 작업을 실행하는 데 필요한 구성 요소에만 액세스할 수 있으며, 더 이상 할 필요가 없습니다. 이렇게 하면 앱이 애플리케이션의 일부에 액세스할 수 없는 매우 안전한 환경이 만들어집니다. 권한을 부여받지 못한 시스템에 적용됩니다.

하지만 앱에서 여러 가지 방법으로 다른 앱과의 데이터, 그리고 시스템 서비스에 액세스할 수 있습니다.

• 두 개의 앱이 동일한 Linux 사용자 ID를 공유하도록 설정할 수 있습니다. 이 경우 서로의 파일에 액세스할 수 있습니다. 시스템 리소스를 절약하기 위해 동일한 사용자 ID가 동일한 Linux 프로세스에서 실행되고 동일한 VM을 공유하도록 구성할 수도 있습니다. 이 앱은 동일한 인증서로 서명되어야 합니다.
• 앱은 기기의 데이터(예: 위치, 카메라, 블루투스 연결이 필요합니다. 사용자는 명시적으로 권한을 부여할 수 있습니다. 권한에 대한 자세한 내용은 다음을 참조하세요. Android에서의 권한

이 문서의 나머지에서는 다음과 같은 개념을 소개합니다.

• 앱을 정의하는 핵심 프레임워크 구성 요소.
• 구성요소 및 필수 기기를 선언하는 매니페스트 파일 기능을 있습니다.
• 앱 코드와 분리되어 있으며 앱을 사용할 수 있게 하는 리소스 다양한 기기 구성에 맞게 동작을 단계적으로 최적화할 수 있습니다.

앱 구성요소

앱 구성요소는 Android 앱의 필수 빌딩 블록입니다. 각 구성요소는 시스템이나 사용자가 앱에 진입할 수 있는 진입점입니다. 다소 유용함 다른 구성 요소에 종속됩니다

앱 구성 요소에는 네 가지 유형이 있습니다.

• 활동
• 서비스
• broadcast receiver
• 콘텐츠 제공자

유형마다 용도가 뚜렷하게 정해져 있음 구성요소의 생성 및 소멸 방식을 정의하는 고유한 수명 주기가 있습니다. 다음 섹션에서는 앱 구성 요소의 네 가지 유형에 대해 설명합니다.

활동

활동은 사용자와 상호작용하기 위한 진입점입니다. 단일 사용자 인터페이스가 있는 화면입니다. 예를 들어 이메일 앱에는 새 이메일 주소 목록을 표시하는 활동이 이메일을 작성하는 활동, 이메일을 읽는 다른 활동이 있습니다. 하지만 여러 활동이 함께 작동하여 이메일 앱에서 일관된 사용자 환경을 형성합니다. 서로 독립적입니다

다른 앱에서 다음 중 하나를 시작할 수 있습니다. 활동을 허용할 수 있습니다. 예를 들어 카메라 앱이 사용자가 사진을 공유할 수 있도록 새 이메일을 작성하는 이메일 앱의 활동

액티비티는 다음과 같이 시스템과 앱의 주요 상호작용을 돕습니다.

• 사용자가 현재 관심을 두는 사항(화면에 있는 내용)을 추적하여 시스템은 활동을 호스팅하는 프로세스를 계속 실행합니다.
• 이전에 사용된 프로세스에 사용자가 돌아갈 수 있는 중지된 활동이 포함되어 있는지 파악 가용성 유지를 위해 해당 프로세스의 우선순위를 더 높게 설정합니다.
• 앱이 프로세스를 종료하도록 지원하여 사용자가 활동으로 돌아갈 수 있도록 지원 이전 상태가 복원된 것입니다
• 앱이 서로 사용자 플로우를 구현하고 시스템이 조율할 것입니다. 이것의 대표적인 예는 공유입니다.

활동은 Activity 클래스의 서브클래스로 구현합니다. 자세한 내용은 Activity 클래스에 관한 자세한 내용은 다음을 참고하세요. 활동 소개.

서비스

서비스는 앱을 백그라운드에서 계속 실행하기 위한 범용 진입점입니다. 할 수 있습니다. 백그라운드에서 실행되어 장기 실행 작업을 수행하는 원격 프로세스를 위해 작업을 수행하는 데 사용할 수 있습니다. 서비스는 사용자 인터페이스를 제공하지 않습니다.

대상 예를 들어 서비스에서 사용자가 다른 앱을 사용하는 동안 백그라운드에서 음악을 재생할 수 있습니다. 활동과의 사용자 상호작용을 차단하지 않고 네트워크를 통해 데이터를 가져올 수 있습니다. 다른 서비스를 시작할 수 있고 서비스를 시작하도록 두거나 상호작용합니다.

시스템에 앱을 관리하는 방법을 알려주는 서비스에는 시작된 서비스와 바인딩된 서비스입니다

시작된 서비스는 작업이 완료될 때까지 서비스를 계속 실행하도록 시스템에 지시합니다. 일부 데이터를 백그라운드에서 동기화하거나 사용자가 앱을 나간 후에도 음악을 재생하기 위한 것일 수 있습니다. 백그라운드에서 데이터를 동기화하거나 음악을 재생하는 것은 시스템에서 다르게 처리합니다.

• 음악 재생은 사용자가 직접 인지하는 것으로, 앱은 이를 시스템을 확인할 수 있습니다 이 경우 시스템은 해당 서비스의 프로세스가 실행 중이기 때문입니다. 이 프로세스가 사라지면 사용자는 좋지 않은 경험을 하게 되기 때문입니다.
• 일반적인 백그라운드 서비스는 사용자가 직접 알고 있는 것이 아니므로 시스템은 프로세스를 더 자유롭게 관리할 수 있습니다. 한 번 죽여 버리도록 할 수도 있고, 더 많은 작업을 위해 RAM이 필요한 경우 서비스를 다시 시작할 수 있습니다. 즉시 우려해야 합니다.

바인드된 서비스는 다른 앱 (또는 시스템)이 있습니다. 바인드된 서비스가 또 다른 프로세스에 API를 제공하고, 이러한 프로세스 사이에 종속 항목이 있다는 것을 알고 있습니다. 따라서 프로세스 A가 프로세스 B를 실행하면 시스템은 A를 위해 프로세스 B와 서비스를 계속 실행해야 한다는 것을 압니다. 또한 프로세스 A가 사용자가 관심을 가지면 프로세스 B를 사용자가 원하는 것으로 사용자가 관심을 가질 것이라고 생각합니다.

서비스는 유연성 덕분에 모든 종류의 상위 수준 시스템 개념의 구성 요소입니다. 라이브 배경화면, 알림 리스너, 화면 보호기, 입력 방법, 접근성 서비스 및 기타 여러 핵심 시스템 기능 모두 애플리케이션이 구현하는 서비스로 빌드되며 애플리케이션이 실행될 때 시스템이 바인딩됩니다.

서비스는 Service의 서브클래스로 구현됩니다. 자세한 내용은 Service 클래스에 관한 자세한 내용은 서비스 개요를 참조하세요.

참고: 앱이 Android 5.0 (API 수준 21) 이상을 타겟팅하는 경우 JobScheduler 클래스를 사용하여 작업을 예약합니다. JobScheduler에는 작업을 최적으로 예약하여 전력 소비를 줄여 배터리 절약 그리고 잠자기 API를 사용하여 작동합니다. 이 클래스 사용에 관한 자세한 내용은 JobScheduler를 참조하세요. 참조하세요.

broadcast receiver

broadcast receiver는 시스템이 이벤트를 앱이 시스템 전체 브로드캐스트에 응답할 수 있도록 일반적인 사용자 플로우 외부에 있는 앱 공지사항입니다. broadcast receiver도 앱으로 들어가는 또 다른 잘 정의된 항목이므로 시스템은 현재 실행되고 있지 않은 앱에도 브로드캐스트를 전달할 수 있습니다.

예를 들어 앱에서 알람을 예약하여 사용자에게 예정된 이벤트에 대해 알리는 알림을 게시합니다. 알람이 앱의 BroadcastReceiver로 전송되므로 앱에서 다음을 실행할 필요가 없습니다. 알람이 울릴 때까지 계속 실행됩니다.

화면이 꺼져 있다고 알리는 방송과 같이 많은 방송은 시스템에서 시작되며 배터리가 부족하거나 사진이 촬영됩니다. 또한 앱은 브로드캐스트를 시작하여 다른 앱에 일부 데이터가 기기에 다운로드되어 사용할 수 있도록 합니다.

브로드캐스트 수신자는 사용자 인터페이스를 표시하지 않으며 상태 표시줄 알림을 생성할 수 있습니다. 브로드캐스트 이벤트가 발생하면 사용자에게 알립니다. 그러나 일반적으로 broadcast receiver는 다른 구성요소로의 게이트웨이에 불과하며 극소량의 작업만 수행하도록 되어 있습니다.

예를 들어 broadcast receiver는 JobService를 예약하여 JobScheduler를 사용하여 이벤트에서 Broadcast receiver에는 앱이 서로 상호작용하는 경우가 많으므로 브로드캐스트의 보안에 미치는 영향을 고려해야 합니다.

broadcast receiver는 BroadcastReceiver의 서브클래스로 구현됩니다. 각 브로드캐스트는 Intent 객체로 전달됩니다. 자세한 내용은 BroadcastReceiver 클래스를 참고하세요.

콘텐츠 제공자

콘텐츠 제공자는 개발자가 저장할 수 있는 공유된 앱 데이터 집합을 관리합니다. 파일 시스템, SQLite 데이터베이스, 웹 또는 기타 영구 저장소 내 내 위치를 앱에서 액세스할 수 있습니다. 다른 앱은 콘텐츠 제공자를 통해 콘텐츠 제공자가 허용하는 경우 데이터에 액세스할 수 없습니다.

예를 들어 Android 시스템은 사용자의 연락처 정보를 관리하는 제공업체입니다. 올바른 운영체제가 있는 모든 앱 다음과 같이 콘텐츠 제공자를 쿼리할 수 있는 권한 ContactsContract.Data: 다음에 관한 정보를 읽고 씁니다 확인할 수 있습니다.

콘텐츠 제공자를 데이터베이스의 추상화라고 생각하고 싶은데, 왜냐하면 많은 API와 지원이 내장되어 있습니다. 그러나 이 둘은 핵심 목적을 달성하는 데 도움이 됩니다

시스템에서 콘텐츠 제공자는 이름이 지정된 데이터 항목을 게시하기 위한 앱으로 들어가는 진입점이 됩니다. 모든 리소스 요청을 처리합니다 따라서 앱은 포함된 데이터를 URI 네임스페이스는 이 URI를 다른 엔터티에 건네주고, 이 엔터티는 다시 이 URI를 사용해 데이터를 수집하는 데 사용됩니다 이를 통해 시스템이 앱을 관리할 수 있도록 하는 몇 가지 특별한 작업이 있습니다.

• URI를 할당하기 위해 앱을 계속 실행할 필요는 없습니다. 따라서 URI는 앱 소유가 종료됩니다. 시스템은 사용자가 소유한 앱이 해당 URI에서 앱의 데이터를 가져올 때도 계속 실행됩니다.
• 이 URI는 중요하고 조밀한 보안 모델을 제공합니다. 예를 들어 앱은 클립보드에 있는 이미지의 URI를 배치할 수 있지만 콘텐츠는 그대로 둡니다 다른 앱이 자유롭게 액세스할 수 없도록 잠겨 있습니다. 두 번째 앱에서 시스템은 앱이 해당 앱이 임시 URI 권한 부여를 사용하여 데이터 액세스 이 URI 뒤의 데이터에만 액세스하고 두 번째 앱의 다른 데이터에는 액세스하지 않습니다.

콘텐츠 제공자는 비공개 데이터를 읽고 쓰는 데도 공유하지 않습니다.

콘텐츠 제공자는 ContentProvider의 서브클래스로 구현됩니다. 다른 앱이 이 작업을 수행할 수 있도록 하는 표준 API 집합을 구현해야 합니다. 거래입니다. 자세한 내용은 콘텐츠 제공업체 개발자를 참고하세요. 참조하세요.

Android 시스템 디자인의 독특한 측면은 모든 앱이 앱의 구성요소로 이동합니다. 예를 들어 사용자가 이 작업을 수행하는 다른 앱이 있을 수 있습니다. 앱이 직접 사진을 캡처하는 활동을 개발하는 대신 사용할 수 있습니다. 하지 말아야 할 일 카메라 앱의 코드를 통합하거나 연결해야 합니다. 대신 카메라 앱에서 이미지를 캡처하는 활동을 시작할 수 있습니다. 사진 작업이 완료되면 사진이 앱으로 반환되기까지 하여 바로 사용할 수 있습니다. 사용자에게 카메라가 실제로 앱의 일부인 것처럼 보입니다.

시스템이 구성요소를 시작하면 그 앱의 프로세스를 시작합니다(시작되지 않은 경우). 구성 요소에 필요한 클래스를 인스턴스화합니다. 예를 들어 카메라 앱에서 사진을 캡처하는 활동을 시작하면 앱의 프로세스가 아닌 카메라 앱에 속한 프로세스에서 실행됩니다. 따라서 대부분의 다른 시스템의 앱과 달리 Android 앱에는 포인트: main() 함수가 없습니다.

시스템이 각 앱을 별개의 프로세스에서 실행하기 때문에 다른 앱에 대한 액세스를 제한하는 경우 앱이 사용할 수 있습니다. 하지만 Android 시스템에서는 가능합니다. 구성 요소를 인텐트를 지정하는 메시지를 시스템에 전송합니다. 특정 구성 요소를 시작할 수 있습니다. 그러면 시스템이 대신 해당 구성 요소를 활성화해줍니다.

구성요소 활성화

인텐트라는 비동기 메시지는 4가지 구성요소 유형인 활동, 서비스, broadcast receiver를 분해합니다. 인텐트는 런타임에서 각 구성 요소를 서로 바인딩합니다. Kubernetes에서 다른 컴포넌트로부터 작업을 요청하는 메신저로서 해당 컴포넌트가 속해 있는지 연결할 수 있습니다

인텐트는 Intent 객체로 만들어지며, 이 객체는 다음과 같은 메시지를 정의합니다. 특정 구성요소 (명시적 인텐트) 또는 특정 유형의 구성요소 활성화 (암시적 인텐트).

활동과 서비스의 경우 인텐트는 수행할 작업을 정의합니다. 예를 들면 다음과 같습니다. view 또는 전송할 수 있으며, 작업을 수행할 데이터의 URI를 지정할 수 있고, 특히 알아야 할 수도 있습니다.

예를 들어, 인텐트는 이미지를 표시하거나 웹페이지를 열기 위한 활동입니다. 경우에 따라 결과를 수신하기 위해 Activity가 반환되며, 이 경우 Activity도 다음을 반환합니다. 결과는 Intent입니다. 또한 인텐트를 발행하여 사용자가 개인 연락처를 선택하고 귀하에게 반환합니다. 반환 인텐트에는 선택된 연락처를 가리키는 URI입니다.

broadcast receiver의 경우 인텐트는 방송 공지 예를 들어, 기기 배터리가 부족함을 나타내는 브로드캐스트 배터리 부족을 나타내는 알려진 작업 문자열만 포함됩니다.

액티비티, 서비스 및 Broadcast Receiver와 달리 콘텐츠 제공자는 ContentResolver의 요청으로 타겟팅될 때 활성화됩니다. 콘텐츠 리졸버가 콘텐츠 제공자와의 모든 직접 트랜잭션을 처리하며 프로바이더로 트랜잭션을 수행할 때 ContentResolver 객체. 이로 인해 정보를 요청하는 구성 요소가 있을 수 있습니다.

각 유형의 구성 요소를 활성화하는 데는 각기 별도의 메서드가 있습니다.

• startActivity()에 Intent 전달 또는 활동이 결과를 반환하도록 하려면 startActivityForResult()입니다.
• Android 5.0 (API 수준 21) 이상에서는 JobScheduler 클래스를 사용하여 작업을 예약합니다. 이전 Android 버전의 경우 또는 진행 중인 서비스에 새로운 지침을 제공하는 Intent를 startService()에 전달합니다. Intent를 전달하여 서비스에 바인딩할 수 있습니다. bindService()입니다.
• 다음과 같은 메서드에 Intent를 전달하여 브로드캐스트를 시작할 수 있습니다. sendBroadcast() 또는 sendOrderedBroadcast()입니다.
• 다음을 호출하여 콘텐츠 제공자에 쿼리를 실행할 수 있습니다. query() (ContentResolver)

인텐트 사용에 관한 자세한 내용은 인텐트 및 인텐트 필터 문서를 참조하세요. 다음 문서에서는 특정 구성 요소 활성화에 대한 자세한 정보를 제공합니다. 활동 소개, 서비스 개요, BroadcastReceiver 및 콘텐츠 제공자.

매니페스트 파일

Android 시스템이 앱 구성 요소를 시작하려면 먼저 구성요소의 존재 여부를 확인하는 방법은 앱의 매니페스트 파일 AndroidManifest.xml을 읽으면 됩니다. 앱은 이 파일( 앱 프로젝트 디렉터리에 있습니다.

매니페스트는 앱의 구성 요소를 선언하는 것 외에도 많은 작업을 합니다. 다음과 같습니다.

• 앱이 요구하는 모든 사용자 권한 식별(예: 인터넷 액세스, 사용자의 연락처에 대한 읽기 액세스 권한이 있어야 합니다.
• 최솟값을 선언합니다. API 수준 앱에서 사용하는 API에 따라 앱에서 필요로 합니다.
• 앱에서 사용하거나 요구하는 하드웨어 및 소프트웨어 기능(예: 카메라, 블루투스 서비스 또는 멀티터치 화면입니다.
• 앱을 연결해야 하는 API 라이브러리를 선언합니다 (Android 프레임워크 제외). API)(예: Google 지도 라이브러리에 추가합니다.

구성요소 선언

매니페스트의 주요 작업은 시스템에 앱의 구성 요소를 알리는 것입니다. 대상 예를 들어 매니페스트 파일은 다음과 같이 활동을 선언할 수 있습니다.

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:icon="@drawable/app_icon.png" ... >
        <activity android:name="com.example.project.ExampleActivity"
                  android:label="@string/example_label" ... >
        </activity>
        ...
    </application>
</manifest>

<application>에 있음 요소의 경우 android:icon 속성은 있습니다.

<activity> 요소에서 android:name 속성은 Activity 서브클래스 및 android:label 속성은 문자열을 지정합니다. 활동에 대해 사용자에게 표시되는 라벨로 사용할 수 있습니다.

다음 요소를 사용하여 모든 앱 구성 요소를 선언해야 합니다.

• 요소 <activity>개 활동
• <service> 요소: 서비스
• 요소 <receiver>개 모든 디바이스에서
• 요소 <provider>개 콘텐츠 제공업체용

소스에 포함했지만 선언하지 않은 활동, 서비스 및 콘텐츠 제공자 매니페스트의 항목은 시스템에 표시되지 않으므로 실행될 수 없습니다. 하지만 방송 수신기는 매니페스트에서 선언하거나 코드에서 동적으로 생성할 수 있습니다. BroadcastReceiver 객체를 만들고 시스템에 등록되도록 registerReceiver()입니다.

앱의 매니페스트 파일을 구성하는 방법에 관한 자세한 내용은 앱 매니페스트 개요를 참고하세요.

구성요소 기능 선언

구성요소 활성화 섹션에서 설명한 것처럼, Intent: 활동, 서비스, broadcast receiver를 시작합니다. 수행할 작업 인텐트에서 구성요소 클래스 이름을 사용하여 대상 구성 요소의 이름을 명시적으로 지정합니다. 또한 암시적 인텐트를 사용할 수도 있습니다. 수행할 작업의 유형과 원하는 경우 수행하려는 데이터를 설명합니다. 작업을 수행할 수 있습니다 암시적 인텐트를 사용하면 시스템이 기기에서 구성 요소를 찾을 수 있음 실행할 수 있는 실행할 수 있습니다 인텐트에 따라 사용자가 어떤 인텐트를 사용할지 선택합니다.

주의: 인텐트를 사용하여 Service를 사용하는 경우 다음을 사용하여 앱이 안전한지 확인하세요. 음란물 인텐트를 지정할 수 있습니다. 암시적 인텐트를 사용하여 서비스를 시작하는 것은 어떤 서비스가 인텐트에 응답하는지 확신할 수 없기 때문에 사용자는 어떤 서비스가 시작하는지 볼 수 없습니다. Android 5.0 (API 수준 21)부터 시스템은 bindService()를 호출하면 예외가 발생합니다. 있습니다. 서비스에 대한 인텐트 필터를 선언하지 마세요.

시스템은 인텐트에 응답할 수 있는 구성 요소를 다른 앱의 매니페스트 파일에 제공된 인텐트 필터에 수신된 인텐트를 있습니다.

앱의 매니페스트에서 활동을 선언할 때 선택적으로 인텐트에 응답할 수 있도록 활동의 기능을 선언하는 인텐트 필터 다른 앱에서도 볼 수 있습니다. 다음을 수행합니다. <intent-filter> 요소를 구성요소의 선언 요소의 하위 요소로 추가합니다.

예를 들어, 새 이메일을 작성하는 활동이 포함된 이메일 앱을 빌드하는 경우 다음과 같은 작업을 할 수 있습니다. 'send'에 응답하는 인텐트 필터 선언 인텐트를 사용하여 새 이메일을 보내고, 다음과 같습니다.

<manifest ... >
    ...
    <application ... >
        <activity android:name="com.example.project.ComposeEmailActivity">
            <intent-filter>
                <action android:name="android.intent.action.SEND" />
                <data android:type="*/*" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </activity>
    </application>
</manifest>

다른 앱이 ACTION_SEND 작업으로 인텐트를 만들어 startActivity(), 사용자가 초안을 작성하여 보낼 수 있도록 시스템이 활동을 시작할 수 있습니다. 이메일

인텐트 필터 생성에 관한 자세한 내용은 인텐트 및 인텐트 필터 문서를 참고하세요.

앱 요구사항 선언

Android로 구동되는 다양한 기기가 있지만 모두 동일한 기능을 제공합니다 앱이 기기에 설치되지 않도록 하기 위해 앱에 필요한 기능이 부족한 경우 앱의 프로필을 명확하게 정의하는 것이 중요합니다. 앱에 기기 및 소프트웨어 요구사항을 선언하여 앱이 지원하는 기기 유형을 매니페스트 파일을 참조하세요.

이러한 선언은 대부분 정보 제공의 목적으로만 사용됩니다. 시스템에서 Google Play와 같은 외부 서비스에서 이를 읽고 필터링을 제공합니다. 사용자가 자신의 기기에서 앱을 검색할 때

예를 들어 앱에 카메라가 필요하고 Android 8.0 (API 수준 26)에 도입된 API를 사용한다고 가정해 보겠습니다. 이러한 요구사항을 선언해야 합니다. minSdkVersion 및 targetSdkVersion의 값은 앱 모듈의 build.gradle 파일에 있습니다.

android {
  ...
  defaultConfig {
    ...
    minSdkVersion 26
    targetSdkVersion 29
  }
}

참고: minSdkVersion 및 매니페스트 파일에 직접 targetSdkVersion 빌드 프로세스 중에 Gradle이 덮어쓰게 됩니다 자세한 내용은 API 수준 요구사항 지정

앱의 매니페스트 파일에서 카메라 기능을 선언합니다.

<manifest ... >
    <uses-feature android:name="android.hardware.camera.any"
                  android:required="true" />
    ...
</manifest>

이 예에 나와 있는 선언에서 선언적 요소가 없는 기기는 카메라를 사용하거나 Android 버전이 8.0 미만이면 Google Play에서 앱을 설치할 수 없습니다. 그러나 앱이 카메라를 사용한다고 선언할 수도 있지만 필요합니다. 이렇게 하려면 required 속성을 false로 설정하려면 런타임 시 기기에 카메라가 있고 필요에 따라 카메라 기능을 사용 중지합니다.

다양한 기기와의 앱 호환성을 관리하는 방법 자세히 알아보기 기기 호환성 개요를 참고하세요.

앱 리소스

Android 앱은 코드만으로 이루어진 것이 아니라 이를 위해서는 소스 코드와 별도로 처리되어야 합니다. 보여드리겠습니다. 예를 들어 애니메이션, 메뉴, 스타일, 색상, XML 파일과 활동 사용자 인터페이스의 레이아웃을 제공합니다.

앱 리소스를 사용하면 코드를 수정하지 않고도 앱의 다양한 특성을 업데이트할 수 있습니다. 제공 중 대체 리소스 집합을 사용하면 다양한 유형의 앱에 맞게 앱을 최적화할 수 있습니다. 다양한 언어 및 화면 크기 등의 기기 설정을 관리할 수 있습니다.

Android 프로젝트에 포함된 모든 리소스에 대해 SDK 빌드 도구는 고유한 정수 ID이며, 이 ID는 앱 코드에서 리소스를 참조하는 데 사용할 수 있습니다. 볼 수 있습니다 예를 들어 앱에 logo.png (res/drawable/ 디렉터리에 저장됨)로, SDK 도구는 R.drawable.logo라는 리소스 ID 이 ID는 앱별 정수에 매핑되며 를 사용하여 이미지를 참조하고 사용자 인터페이스에 삽입할 수 있습니다.

소스 코드와 별도로 리소스를 제공하는 가장 중요한 측면 중 하나는 다양한 기기에 대한 대체 리소스를 제공하는 기능입니다. 구성할 수 있습니다

예를 들어 XML로 UI 문자열을 정의하면 문자열을 다른 해당 문자열을 별도의 파일에 저장합니다. 그런 다음 Android는 적절한 언어 문자열 언어 한정자를 기반으로 UI에 적용하기 사용자가 리소스 디렉터리의 이름에 추가하는 파일(예: 프랑스어 문자열의 경우 res/values-fr/) 값 및 사용자의 언어 설정을 변경할 수 있습니다.

Android는 대체 리소스에 대해 다양한 한정자를 지원합니다. 이 한정자는 리소스 디렉터리의 이름에 포함하는 짧은 문자열입니다. 해당 리소스가 사용되는 기기 구성을 정의합니다.

대상 예를 들어, 활동 패턴에 따라 활동에 대해 다양한 레이아웃을 기기의 화면 방향 및 크기를 나타냅니다. 기기 화면이 세로 모드인 경우 (톨) 버튼이 수직으로 배열된 레이아웃을 원할 수 있지만 화면이 버튼을 가로 방향으로 정렬하는 것이 좋습니다. 레이아웃 변경하기 방향에 따라 두 개의 레이아웃을 정의하고 적절한 한정자를 각 레이아웃의 디렉터리 이름에 추가합니다. 그러면 시스템에서 자동으로 적절한 현재 기기 방향에 따라 레이아웃을 조정할 수 있습니다.

애플리케이션에 포함할 수 있는 다양한 종류의 리소스에 대한 자세한 내용과 다양한 기기 구성에 맞는 대체 리소스를 만들려면 앱 리소스 개요를 참고하세요. 받는사람 권장사항에 관해 알아보고 강력한 프로덕션 품질의 앱 설계하기 앱 아키텍처 가이드를 참고하세요.

추가 리소스

동영상 및 코드 튜토리얼을 사용한 Android 개발에 관해 알아보려면 다음을 참고하세요. Kotlin을 사용하여 Android 앱 개발 오신 것을 환영합니다