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 アプリの開発をご覧ください。
関連情報:
- インテントとインテント フィルタ
Intent
API を使用して、アクティビティやサービスなどのアプリ コンポーネントを有効にする方法と、他のアプリがアプリ コンポーネントを使用できるようにする方法について説明します。- アクティビティの概要
Activity
クラスのインスタンスを作成する方法を学びます。このクラスは、ユーザー インターフェースを備えたアプリの個別の画面を提供します。- アプリリソースの概要
- 特定のデバイス構成に対して代替リソースを提供する方法など、アプリのリソースをアプリコードと分離するための Android アプリの構造について説明します。
その他の情報:
- デバイスの互換性の概要
- さまざまなデバイスで Android が動作する仕組みと、デバイスごとにアプリを最適化する方法や、デバイスごとにアプリを利用可能に制限する方法を学びます。
- Android での権限
- アプリが特定の API を使用するためにユーザーの同意を求める権限システムにより、Android がアプリによる特定の API へのアクセスを制限する仕組みについて説明します。