このページは Cloud Translation API によって翻訳されました。

アプリの基礎

Android アプリは、Kotlin、Java プログラミング言語、C++ 言語を使用して記述できます。Android SDK Tools は、データやリソースファイルとともにコードを APK または Android App Bundle にコンパイルします。

Android パッケージ（.apk というサフィック��が付いたアーカイブファイル）には、実行時に必要な Android アプリのコンテンツが含まれています。Android パッケージは、Android デバイスがアプリをインストールする際に使用するファイルです。

Android App Bundle は、.aab という接尾辞の付いたアーカイブファイルであり、実行時に不要な追加のメタデータなど、Android アプリプロジェクトのコンテンツが含まれています。AAB は公開形式であるため、Android デバイスにインストールすることはできません。APK の生成と署名は後の段階に委ねられます。

たとえば、Google Play を通じてアプリを配信する場合、Google Play のサーバーは、アプリのインストールをリクエストしている特定のデバイスが必要とするリソースとコードのみを含む、最適化された APK を生成します。

各 Android アプリは独自のセキュリティサンドボックス内にあり、次の Android セキュリティ機能によって保護されています。

Android オペレーティングシステムはマルチユーザーの Linux システムであり、各アプリはそれぞれ異なるユーザーです。
デフォルトでは、システムは各アプリに一意の Linux ユーザー ID を割り当てます。この ID はシステムのみが使用し、アプリでは認識されません。アプリ内のすべてのファイルには権限が設定され、そのアプリに割り当てられたユーザー ID のみがアクセスできるようになります。
各プロセスには独自の仮想マシン（VM）があるため、アプリのコードは他のアプリから独立して実行されます。
デフォルトでは、すべてのアプリはそれぞれの Linux プロセスで実行されます。Android システムは、アプリのコンポーネントのいずれかの実行が必要になったときにプロセスを開始し、プロセスが不要になったとき、または他のアプリのメモリを回復する必要があるときにシャットダウンします。

Android システムは、最小権限の原則を実装しています。つまり、デフォルトでは、各アプリは作業を行うために必要なコンポーネントにのみアクセスでき、それ以上のアクセスはできません。これにより、権限が付与されていないシステムの一部にアプリはアクセスできない、非常に安全な環境が構築されます。

ただし、アプリが他のアプリとデータを共有する方法や、システムサービスにアクセスする方法があります。

2 つのアプリが同じ Linux ユーザー ID を共有し、互いのファイルにアクセスできるようにすることも可能です。システムリソースを節約するために、同じユーザー ID を持つアプリを同じ Linux プロセスで実行し、同じ VM を共有することもできます。また、アプリは同じ証明書で署名する必要があります。
アプリは、デバイスの位置情報、カメ��、Bluetooth 接続などのデバイスデータにアクセスする権限をリクエストできます。ユーザーはこれらの権限を明示的に付与する必要があります。権限について詳しくは、Android での権限をご覧ください。

このドキュメントの以降の部分では、次のコンセプトについて説明します。

アプリを定義するコアフレームワークコンポーネント。
マニフェストファイルでは、アプリに必要なコンポーネントとデバイス機能を宣言します。
アプリコードとは別個のリソース。これにより、さまざまなデバイス構成に合わせてアプリの動作を適切に最適化できます。

アプリコンポーネント

アプリコンポーネントは、Android アプリに不可欠な構成要素です。各コンポーネントは、システムやユーザーがアプリを起動するためのエントリポイントです。一部のコンポーネントは、他のコンポーネントに依存しています。

アプリコンポーネントには次の 4 種類があります。

アクティビティ
サービス
ブロードキャストレシーバ
コンテンツプロバイダ

種類ごとに目的が異なり、コンポーネントの作成方法と破棄方法を定義するライフサイクルも異なります。以下のセクションでは、4 種類のアプリコンポーネントについて説明します。

アクティビティ

アクティビティは、ユーザーとやり取りするためのエントリポイントです。ユーザーインターフェースを含む 1 つの画面を表します。たとえば、メールアプリには、新しいメールのリストを表示するアクティビティ、メールを作成するアクティビティ、メールを読むためのアクティビティがあるとします。メールアプリでは、これらのアクティビティが連携して一貫したユーザーエクスペリエンスを形成しますが、各アクティビティは他のアクティビティから独立しています。

メールアプリで許可されていれば、別のアプリはこれらのアクティビティのいずれかを開始できます。たとえば、カメラアプリがメールアプリでアクティビティを開始し、ユーザーが写真を共有できるように新しいメールを作成する場合があります。

アクティビティは、システムとアプリ間の次のような重要なインタラクションを容易にします。

ユーザーが現在関心を持っていること（画面上に何があるのか）を追跡し、アクティビティをホストしているプロセスを実行し続ける。
以前に使用したプロセスに、ユーザーが戻ってくる停止アクティビティが含まれているかどうかを把握し、それらのプロセスの優先順位を高くして可用性を維持します。
アプリのプロセスの強制終了の処理をサポートし、ユーザーが以前の状態が復元されたアクティビティに戻れるようにします。
アプリ間でユーザーフローを実装し、システムがこれらのフローを調整できるようにする。その主な例が共有です。

アクティビティは、Activity クラ��のサブクラスとして実装します。Activity クラスの詳細については、アクティビティの概要をご覧ください。

サービス

サービスは、さまざまな理由でアプリをバックグラウンドで実行し続けるための汎用のエントリポイントです。これは、長時間実行オペレーションやリモートプロセスの作業を行うためにバックグラウンドで実行されるコンポーネントです。サービスはユーザーインターフェースを提供していません。

たとえば、ユーザーが別のアプリを操作している間にバックグラウンドで音楽を再生するサービスや、アクティビティでのユーザー操作をブロックすることなくネットワーク経由でデータを取得するサービスなどがあります。アクティビティなどの別のコンポーネントがサービスを開始し、サービスを実行またはバインドして操作できます。

アプリの管理方法をシステムに指示するサービスには、開始されたサービスとバインドされたサービスの 2 種類があります。

開始されたサービスは、処理が完了するまでサービスの実行を継続するようシステムに指示します。たとえば、ユーザーがアプリを離れた後でも、一部のデータをバックグラウンドで同期したり、音楽を再生したりできます。バックグラウンドでのデータの同期や音楽の再生は、開始されたさまざまな種類のサービスを表し、システムによって処理されます。

音楽の再生はユーザーが直接認識しているものであり、アプリは、フォアグラウンドで動作することを宣言し、再生中であることを示す通知を使用して、これをシステムに伝えます。この場合、停止するとユーザーエクスペリエンスが低下するため、システムはサービスのプロセスの実行を優先します。
通常のバックグラウンドサービスはユーザーが直接認識できないため、システムはそのプロセスをより自由に管理できます。ユーザーにとって差し迫った関心事のために RAM が必要な場合は、強制終了して、後でサービスを再開できます。

バインドされたサービスは、他のアプリ（またはシステム）がサービスを利用するように指示した場合に実行されます。バインドされたサービスは別のプロセスに API を提供し、システムはこれらのプロセス間に依存関係があることを認識します。プロセス A がプロセス B のサービスにバインドされている場合、システムはプロセス B とそのサービスを A 用に実行し続ける必要があることを認識します。さらに、プロセス A がユーザーにとって重要なものである場合、プロセス B をユーザーも重視しているものとして扱うことが認識されます。

その柔軟性から、サービスはあらゆる高レベルのシステムコンセプトの有用な構成要素となります。ライブ壁紙、通知リスナー、スクリーンセーバー、入力方法、ユーザー補助サービス、その他の多くのコアシステム機能はすべて、アプリが実装し、その実行時にシステムがバインドされるサービスとして構築されます。

サービスは、Service のサブクラスとして実装されます。Service クラスの詳細については、サービスの概要をご覧ください。

注: アプリが Android 5.0（API レベル 21）以降をターゲットとしている場合は、JobScheduler クラスを使用してアクションのスケジュールを設定できます。JobScheduler には、消費電力を削減するようにジョブを最適にスケジュールし、Doze API を使用することで、バッテリーを節約できるという利点があります。このクラスの使用方法について詳しくは、JobScheduler リファレンスドキュメントをご覧ください。

ブロードキャストレシーバ

ブロードキャストレシーバは、アプリがシステム全体のブロードキャスト通知に応答できるように、通常のユーザーフローの外でシステムがイベントをアプリに配信できるようにするコンポーネントです。ブロードキャストレシーバは、明確に定義されたアプリに対する別のエントリであるため、現在実行されていないアプリにもブロードキャストを配信できます。

そのため、たとえば、アプリはユーザーに今後のイベントを知らせるため、アラームのスケジュールを設定して通知を投稿できます。アラームはアプリ内の BroadcastReceiver に配信されるため、アラームが鳴るまでアプリを実行し続ける必要はありません。

画面がオフになっている、バッテリー残量が少ない、画像がキャプチャされたなどを知らせるブロードキャストなど、多くのブロードキャストはシステムから発信されています。また、一部のデータがデバイスにダウンロードされ、使用可能であることを他のアプリに知らせるなど、アプリはブロードキャストを開始することもできます。

ブロードキャストレシーバはユーザーインターフェースを表示しませんが、ステータスバーの通知を作成して、ブロードキャストイベントが発生したときにユーザーに警告できます。ただし、より一般的には、ブロードキャストレシーバは他のコンポーネントへのゲートウェイであり、最小限の作業を実行することを目的としています。

たとえば、ブロードキャストレシーバは、JobScheduler を使用してイベントに基づいて処理を実行するように JobService をスケジュールする場合があります。ブロードキャストレシーバには、相互通信を行うアプリが関わることが多いため、セットアップする際はセキュリティへの影響に注意することが重要です。

ブロードキャストレシーバは BroadcastReceiver のサブクラスとして実装され、各ブロードキャストは Intent オブジェクトとして配信されます。詳細については、BroadcastReceiver クラスをご覧ください。

コンテンツプロバイダ

コンテンツプロバイダは、ファイルシステム、SQLite データベース、ウェブ、アプリがアクセスできる他の永続ストレージの場所に保存できるアプリデータの共有セットを管理します。コンテンツプロバイダが許可している場合、他のアプリはコンテンツプロバイダを介してデータをクエリまたは変更できます。

たとえば、Android システムは、ユーザーの��絡先情報を管理するコンテンツプロバイダを提供しています。適切な権限を持つアプリは、ContactsContract.Data を使用するなどして、コンテンツプロバイダに対してクエリを行い、特定のユーザーに関する情報の読み取りと書き込みを行うことができます。

コンテンツプロバイダには、一般的なケース向けの API とサポートが数多く組み込まれているため、データベースを抽象化したと考えたくなるかもしれません。ただし、システム設計の観点からは、それぞれ主要な目的が異なります。

システムにとって、コンテンツプロバイダは名前付きデータアイテムを公開するためのアプリへのエントリポイントであり、URI スキームで識別されます。このようにしてアプリは、データに含まれているデータを URI 名前空間にマッピングする方法を決定し、その URI を他のエンティティに渡し、エンティティが他のエンティティを使用してその URI を使用してデータにアクセスできます。これにより、システムはアプリの管理において次のような特定の操作を行えるようになります。

URI を割り当てるのに、アプリを実行し続ける必要はなく、URI を所有するアプリの終了後も URI を保持できます。システムは、対応する URI からアプリのデータを取得するときに、所有するアプリが引き続き実行されていることを確認するだけで済みます。
これらの URI は、重要なきめ細かいセキュリティモデルも提供します。たとえば、クリップボードに画像の URI を配置しても、他のアプリがそれに自由にアクセスできないようにコンテンツプロバイダはロックしたままにしておくことができます。別のアプリがクリップボード上の URI にアクセスしようとすると、システムは、そのアプリに一時的な URI 権限の付与を使用してデータへのアクセスを許可できます。これにより、その URI の背後にあるデータにのみアクセスし、2 つ目のアプリのデータにはアクセスできません。

また、コンテンツプロバイダは、アプリに対して非公開で、共有されないデータの読み取りと書き込みを行う際にも有用です。

コンテンツプロバイダは、ContentProvider のサブクラスとして実装され、他のアプリがトランザクションを実行できるようにする標準 API セットを実装する必要があります。詳細については、コンテンツプロバイダのデベロッパーガイドをご覧ください。

どのアプリでも別のアプリのコンポーネントを起動できることが、Android システム設計に固有の特徴です。たとえば、ユーザーにデバイスのカメラで写真を撮影してもらう場合、その処理を行う別のアプリが存在する可能性があります。アプリは、自分で写真を撮影するアクティビティを開発する代わりに、それを使用できます。カメラアプリのコードを組み込む必要や、コードにリンクする必要はありません。代わりに、写真を撮影するカメラアプリでアクティビティを開始できます。完了すると、写真がアプリに返され、使用できるようになります。ユーザーには、カメラが実際にアプリの一部であるかの��うに見えます。

システムがコンポーネントを起動すると、そのアプリのプロセスがまだ実行されていない場合は、そのプロセスを開始し、コンポーネントに必要なクラスをインスタンス化します。たとえば、写真を撮影するアクティビティをカメラアプリで開始した場合、そのアクティビティはアプリのプロセスではなく、カメラアプリに属するプロセスで実行されます。したがって、他のほとんどのシステムのアプリとは異なり、Android アプリには単一のエントリポイントがなく、main() 関数がありません。

システムは、他のアプリへのアクセスを制限するファイル権限を使用して、各アプリを個別のプロセスで実行するため、アプリが別のアプリのコンポーネントを直接有効にすることはできません。ただし、Android システムはできます。別のアプリのコンポーネントを有効にするには、特定のコンポーネントを開始するインテントを指定するメッセージをシステムに送信します。コンポーネントが自動的に有効になります。

コンポーネントを有効にする

インテントと呼ばれる非同期メッセージは、4 つのコンポーネントタイプ（アクティビティ、サービス、ブロードキャストレシーバ）のうちの 3 つを有効にします。インテントは、実行時に個々のコンポーネントを相互にバインドします。これは、コンポーネントが自分のアプリにあるか別のコンポーネントに属しているかにかかわらず、他のコンポーネントにアクションを要求するメッセンジャーと考えることができます。

インテントは、Intent オブジェクトを使用して作成します。このオブジェクトは、特定のコンポーネント（明示的インテント）または特定のタイプのコンポーネント（暗黙的インテント）をアクティブにするメッセージを定義します。

アクティビティとサービスの場合、インテントは、何かの表示や送信などの実行するアクションを定義します。また、起動されるコンポーネントが知っておく必要がある情報など、処理するデータの URI を指定することもあります。

たとえば、インテントでアクティビティに対して画像を表示するリクエストやウェブページを開くリクエストを伝える場合があります。アクティビティを開始して結果を受け取ることができる場合もあります。その場合、アクティビティは Intent で結果も返します。また、ユーザーが個人の連絡先を選択して返すようにするインテントを発行することもできます。戻りインテントには、選択された連絡先を指す URI が含まれます。

ブロードキャストレシーバの場合、インテントはブロードキャスト通知を定義します。たとえば、デバイスのバッテリー残量が少ないことを示すブロードキャストには、バッテリー残量が少ないことを示す既知のアクション文字列のみが含まれます。

アクティビティ、サービス、ブロードキャストレシーバとは異なり、コンテンツプロバイダは、ContentResolver からのリクエストでターゲットとされたときに有効になります。コンテンツリゾルバは、コンテンツプロバイダとのすべての直接トランザクションを処理し、プロバイダとトランザクションを実行するコンポーネントは ContentResolver オブジェクトのメソッドを呼び出します。これにより、コンテンツプロバイダと情報を要求するコンポーネントとの間にセキュリティ上の理由から抽象化レイヤが残ります。

各タイプのコンポーネントを有効化する方法は異なります。

Intent を startActivity() に渡すか、アクティビティから結果を返すように startActivityForResult() することで、アクティビティを開始したり、新しい処理を実行したりできます。
Android 5.0（API レベル 21）以降では、JobScheduler クラスを使用してアクションのスケジュールを設定できます。以前のバージョンの Android では、Intent を startService() に渡すことで、サービスを開始するか、進行中のサービスに新しい指示を与えることができます。サービスにバインドするには、Intent を bindService() に渡します。
ブロードキャストを開始するには、Intent を sendBroadcast() や sendOrderedBroadcast() などのメソッドに渡します。
コンテンツプロバイダへのクエリを実行するには、ContentResolver に対して query() を呼び出します。

インテントの使用方法について詳しくは、インテントとインテントフィルタのドキュメントをご覧ください。特定のコンポーネントの有効化について詳しくは、アクティビティの概要、サービスの概要、BroadcastReceiver、コンテンツプロバイダの各ドキュメントをご覧ください。

マニフェストファイル

Android システムがアプリコンポーネントを起動できるようにするには、アプリのマニフェストファイル（AndroidManifest.xml）を読み取って、コンポーネントが存在することをシステムが認識する必要があります。アプリのすべてのコンポーネントをこのファイル内で宣言します。このファイルは、アプリプロジェクトディレクトリのルートにあります。

マニフェストは、アプリのコンポーネントを宣言するだけでなく、次のようなさまざまなことを行います。

インターネットアクセスやユーザーの連絡先への読み取りアクセス権など、アプリが必要とするユーザー権限を特定します。
アプリで使用する API に基づいて、アプリに必要な最小 API レベルを宣言します。
カメラ、Bluetooth サービス、マルチタッチスクリーンなど、アプリが使用または必要とするハードウェア機能とソフトウェア機能を宣言します。
Google マップライブラリなど、アプリのリンクが必要な API ライブラリ（Android フレームワーク API は除く）を宣言する。

コンポーネントを宣言する

マニフェストの主なタスクは、アプリのコンポーネントをシステムに知らせることで��。たとえば、マニフェストファイルでアクティビティを次のように宣言できます。

<?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 を使用してアクティビティ、サービス、ブロードキャストレシーバを起動できます。そのためには、対象となるコンポーネントに、インテントのコンポーネントクラス名を使用して明示的に名前を付けます。暗黙的インテントを使用することもできます。暗黙的インテントは、実行するアクションの種類と、必要に応じてアクションを実行するデータを記述します。暗黙的インテントを使用すると、システムは、そのアクションを実行して開始できるデバイス上のコンポーネントを見つけることができます。インテントに記述されたアクションを実行できるコンポーネントが複数ある場合、ユーザーは使用するコンポーネントを選択します。

注意: インテントを使用して Service を開始する場合は、明示的インテントを使用して、アプリが安全であることを確認してください。暗黙的インテントを使用してサービスを開始すると、どのサービスがインテントに応答するかを判断できず、ユーザーはどのサービスが開始するかを確認できないため、セキュリティ上の危険があります。Android 5.0（API レベル 21）以降では、暗黙的インテントを使用して bindService() を呼び出すと、例外がスローされます。サービスのインテントフィルタを宣言しないでください。

システムは、受け取ったインテントを、デバイス上の他のアプリのマニフェストファイルで指定されているインテントフィルタと比較することで、インテントに応答できるコンポーネントを識別します。

アプリのマニフェストでアクティビティを宣言する場合、必要に応じて、アクティビティの機能を宣言するインテントフィルタを含めると、他のアプリからのインテントに応答できます。そのためには、コンポーネントの宣言要素の子として <intent-filter> 要素を追加します。

たとえば、新しいメールを作成するアクティビティを備えたメールアプリを作成する場合は、次の例に示すように、「送信」インテントに応答するインテントフィルタを宣言して、新しいメールを送信します。

<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 ファイルを使って定義できます。

アプリリソースを使用すると、コードを変更することなく、アプリのさまざまな特性を簡単に更新できます。代替リソースのセットを用意することで、言語や画面サイズなどのさまざまなデバイス構成に合わせてアプリを最適化できます。

SDK ビルドツールは、Android プロジェクトに含めるすべてのリソースに対して一意の整数 ID を定義します。この ID を使用して、アプリコードや XML で定義された他のリソースからリソースを参照できます。たとえば、アプリに logo.png という名前の画像ファイル（res/drawable/ ディレクトリに保存されています）が含まれている場合、SDK Tools は R.drawable.logo という名前のリソース ID を生成します。この ID はアプリ固有の整数にマッピングされます。この ID を使用して、画像を参照してユーザーインターフェースに挿入できます。

ソースコードとは別にリソースを提供するうえで最も重要なことの 1 つは、さまざまなデバイス構成に対して代替リソースを提供できることです。

たとえば、UI 文字列を XML で定義することで、文字列を他の言語に翻訳して、別のファイルに保存できます。次に、リソースディレクトリ名に付加する言語修飾子（フランス語文字列の値の場合は res/values-fr/ など）とユーザーの言語設定に基づいて、適切な言語文字列を UI に適用します。

Android では、代替リソース用に多くの修飾子がサポートされています。この修飾子は、リソースディレクトリの名前に指定する短い文字列で、リソースを使用するデバイス構成を定義します。

たとえば、デバイスの画面の向きとサイズに応じて、アクティビティの異なるレイアウトを作成できます。デバイス画面が縦向き（トール）の場合はボタンを垂直方向に配置し、画面が横向き（ワイド）の場合はボタンを水平方向に配置することをおすすめします。向きに応じてレイアウトを変更する��は、2 つのレイアウトを定義し、各レイアウトのディレクトリ名に適切な修飾子を適用します。その後、現在のデバイスの向きに応じて、適切なレイアウトが自動的に適用されます。

アプリに含めることができるさまざまな種類のリソースと、デバイス構成ごとに代替リソースを作成する方法について詳しくは、アプリリソースの概要をご覧ください。おすすめの方法と、製品版の品質を備えた堅牢なアプリの設計について詳しくは、アプリアーキテクチャガイドをご覧ください。

参考情報

動画とコードチュートリアルを使って Android 開発について学ぶには、Udacity コース Kotlin を使用した Android アプリの開発をご覧ください。

その他の情報:

デバイスの互換性の概要: さまざまなデバイスで Android が動作する仕組みと、デバイスごとにアプリを最適化する方法や、デバイスごとにアプリを利用可能に制限する方法を学びます。
Android での権限: アプリが特定の API を使用するためにユーザーの同意を求める権限システムにより、Android がアプリによる特定の API へのアクセスを制限する仕組みについて説明します。