入手する使ってみる初めてのアプリを作成することから始めてみましょう。コースを活用して理解を深めるほか、ご自身でアプリ開発を習得することもできます。↗️デバイスごとに拡張するスマートフォン、タブレット、スマートウォッチなど、さまざまなデバイスでシームレスなエクスペリエンスをユーザーに提供するアプリを作成します。独自の規範となるガイダンスに沿って、ユースケース向けにビルドする方法を学習します。アプリ最新情報を確認する年間を通して最新リリースのお知らせをお届けします。プログラムにご参加いただき、ご意見をお寄せください。設計を今すぐ始めましょう。インターフェースをデザインします。TVアーキテクチャ堅牢かつテストと保守が容易なアプリのロジックとサービスを設計します。ストアのガイドラインに沿って、アプリの品質をプランニングします。アプリを作成できます。必要な機能のサンプルとドキュメントを入手します。使用してアプリを作成、ビルドするか、独自のパイプラインを作成します。ファクタ向けのコードを記述する。デバイスの接続とデータの共有。ドキュメントを確認します。よって翻訳されました。必要に応じて、コンテンツの保存と分類を行います。サービス(FGS)を含む)通知を送信するための実行時の権限(POST_NOTIFICATIONS)がサポートされています。この変更は、ユーザーが重要な通知に集中するのに役立ちます。以降をターゲットに設定することを強くおすすめします。32)以下をターゲットとする場合、アプリの機能のコンテキストに応じて権限をリクエストするための柔軟性が失われます。権限をリクエストする必要はありません。同様に、アプリに通知を表示させる必要があります。ターゲットに設定し、以下のセクションで説明しているように、他の実行時の権限をリクエストする場合と同様のプロセスを実施します。スニペットに示します。</application></manifest>アプリの機能は権限ダイアログでのユーザーの選択によって異なる権限ダイアログでは、ユーザーは次のアクションを実行できます。選択するどちらのボタンも押さずにダイアログをスワイプして閉じる以下のセクションでは、ユーザーが選択したアクションに基づくアプリの動作について説明します。選択した場合、アプリは次のことを実行できます。すべての通知チャンネルが許可されます。サービスに関する通知を送信する。この通知は通知ドロワーに表示されます。選択した場合は、除外対象である場合を除き、アプリは通知を送信できません。少数の特定のロールを除いて、すべての通知チャンネルがブロックされます。これは、ユーザーがシステム設定でアプリの通知をすべて手動でオフにした場合の動作と似ています。一度でもタップすると、次のいずれかの条件が発生するまでは権限のプロンプトが表示されなくなります。以上をターゲットとするようにアプリをアップデートしたユーザーがダイアログをスワイプして閉じた場合ユーザーがダイアログをスワイプして閉じた場合、つまり、どちらのボタンも選択されなかった場合です。通知権限の状態は許可されません。以降を搭載したデバイスにユーザーがアプリをインストールした場合、アプリの通知はデフォルトでオフになります。アプリにその権限を付与します。バージョンによって異なります。以上をターゲットとするアプリは、権限ダイアログが表示されるタイミングを完全に制御できます。この機会を利用して、アプリがこの権限を必要とする理由をユーザーに説明し、権限を付与するようすすめます。32)以下をターゲットとする場合、権限ダイアログは、通知チャンネルの作成後にアプリが最初にアクティビティを開始したとき、または、アプリがアクティビティを開始して最初の通知チャンネルを作成したときに表示されます。通常、これはアプリの起動時です。以降にアップグレードした時点で、自動的にすべての対象アプリに通知権限が事前付与されます。これらのアプリは引き続きユーザーに通知を送信できますが、ユーザーには実行時の権限のプロンプトが表示されません。以下を搭載したデバイスに対象アプリがインストールされており、その古いデバイスでユーザーが通知を許可していた場合について考えてみましょう。以降を搭載した新しいデバイスを入手し、バックアップと復元機能を使用してアプリを復元しました。この状況では、システムはアプリを「既存のアプリ」と見なすため、アプリが引き続き通知を送信できるように、アプリに権限が自動的に付与されます。以下を搭載したデバイスでユーザーがアプリの通知を明示的に無効にしていないことが必要です。以上にアップグレードされても、ユーザーの拒否は引き続き有効です。除外このセクションでは、通知権限の動作の変更から除外される通知とアプリを示します。ユーザーが通知権限を拒否しても、関連する通知は引き続き表示されます。セッションに関する通知は、この動作変更から除外されます。権限は必要ありません。アプリで次のことが行われた場合、システムはアプリが通話を自己管理するように構成されているとみなします。インターフェースを実装する。呼び出して、デバイスの通信プロバイダに登録する。以降を搭載したデバイスでは、通知権限をデバイス上のアプリに最初に使用したときの影響を評価できます。ユーザーの選択とデバイスのアップグレードという最も一般的なシーケンスをシミュレートできます。user-fixedおすすめの方法このセクションでは、新しい通知権限をアプリで最も効果的に使用するためのいくつかの方法について説明します。以降をターゲットに設定します。通知権限プロンプトを表示するまで通知の送信を控えるユーザーに権限の付与をリクエストする前に、アプリに関する十分な説明をユーザーに提供します。新規ユーザーは、多くの場合、アプリを操作しながら個々の通知リクエストのメリットを直接確かめようとします。アクションから権限プロンプトをトリガーすることができます。通知権限プロンプトをいつ表示すればよいかについて、いくつかの例を次に示します。ユーザーが「警報ベル」ボタンをタップしたとき。アカウントをフォローすることを選択したとき。ユーザーが料理の宅配を注文したとき。通知権限をリクエストする際の推奨されるワークフローを示しています。notified!」の画面)を表示する必要はありません。代わりに、ユーザーがアプリに慣れてからリクエストが表示されるように設定できます。回起動した後に初めて表示することもできます。通知権限をリクエストする際のユーザー主導のワークフロー。返す場合にのみ必要です。コンテキストに応じて権限をリクエストするアプリ内で通知権限をリクエストする場合は、適切なコンテキストでリクエストし、通知の用途とユーザーがオプトインした方がよい理由を明確に示します。メールアプリには、新着メールごとに通知を送信するオプションや、そのユーザーが唯一の受信者であるメールについてのみ通知を送信するオプションが含まれていることがあります。この機会を利用して通知の意図を明確に示すと、ユーザーがアプリに通知権限を付与する可能性が高まります。アプリから通知を送信できるかどうかを確認するアプリから通知を送信する前に、ユーザーがアプリの通知を有効にしているかどうかを確認します。責任を持って権限を使用する通知を送信する承認が得られたら、責任を持って権限を使用してください。日あたりの通知の数を確認できます。いつでも権限を取り消すことができます。ライセンスに記載のライセンスに従います。関連会社の商標または登録商標です。