サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ブラックフライデー
source.android.com
eSIM を実装する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 埋め込み SIM(eSIM、eUICC)は、モバイル ユーザーが物理的な SIM カードを持っていなくても、携帯通信会社のプロファイルをダウンロードしてサービスを有効にできる技術です。GSMA が主導するグローバル仕様であり、モバイル デバイスのリモート SIM プロビジョニング(RSP)を可能にします。Android 9 以降の Android フレームワークには、eSIM にアクセスして eSIM のサブスクリプション プロファイルを管理するための標準 API が用意されています。サードパーティはこの eUICC API を使用して、eSIM 対応の Android デバイスで独自の携帯通信会社アプリとローカル プロファイル アシスタント(LPA)を開発できます。 LPA はスタンド
概要 Tethering モジュールは、接続されている他のクライアント デバイス(Wi-Fi、USB、Bluetooth、イーサネット経由でテザリング デバイスに接続可能)と、Android デバイスのインターネット接続を共有します。このモジュールには、テザリング コンポーネント(USB、Wi-Fi アクセス ポイント、Bluetooth など)とその依存関係(テザリング利用資格、IpServer、offloadController の操作)が含まれます。このモジュールは更新可能です。つまり、通常の Android リリース サイクル外で機能のアップデートを受信できます。 Tethering モジュールにより、OEM は Android エコシステム全体で、単一の標準リファレンス実装を使用できます。これには次のような利点があります。 エンドユーザーが、Android デバイス全体で一貫した
EGLSurface と OpenGL ES コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Android は OpenGL ES(GLES)API を使用してグラフィックをレンダリングします。GLES コンテキストを作成し、GLES レンダリング用のウィンドウ システムを提供するために、Android は EGL ライブラリを使用します。GLES 呼び出しはテクスチャのあるポリゴンをレンダリングし、EGL 呼び出しは画面にレンダリングを配置します。 GLES で描画する前に、GL のコンテキストを作成する必要があります。EGL では、これは EGLContext と EGLSurface を作成することを意味します。GLES オペレーションは、現在のコンテキストに適用されます。このコンテキストは、引数として渡されるのではなく、スレッド ローカルのストレ
3A モードと状態遷移 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このページでは、Android デバイスの 3A モードとステートマシンについて説明します。ステートマシンを高レベルで定義するカメラ HAL インターフェースにより、HAL 実装と Android フレームワークが 3A の現在の状態について通信し、3A イベントをトリガーできます。HAL 実装では、3A モード設定と状態遷移を制御する 3A アルゴリズムが行われます。 デバイスを開く場合、個々の 3A の状態がすべて STATE_INACTIVE である必要があります。3A はストリーム構成によってリセットされません。たとえば、ロックされたフォーカスは configure() の呼び出しの間も保持される必要があります。 3A アクションをトリガーするには、次に続くリクエストの設定で関
改良点 リリースノート セキュリティに関する最新の公開情報 最新の互換性定義ドキュメント(CDD) サイトの更新 スタート ガイド 基本情報 開始 ダウンロード ビルド テスト 作成 投稿 Community ツール、ビルド、関連リファレンス セキュリティ 概要 公開情報 機能 テスト ベスト プラクティス 主要トピック アーキテクチャ オーディオ カメラ 接続 データ 表示 フォント グラフィックス 操作 メディア パフォーマンス 権限 電源 ランタイム 設定 ストレージ テスト 最新情報 仮想化 互換性 互換性定義ドキュメント(CDD) 互換性テストスイート(CTS) Android デバイス Cuttlefish エンタープライズ テレビ Automotive 開始する 開発のガイドライン 開発ツール テストツールとインフラストラクチャ リリースの詳細 リファレンス HIDL HAL
MAC ランダム化の動作 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 MAC ランダム化機能を使用すると、デバイスは Wi-Fi ネットワークへの接続時に、ランダム化された MAC アドレスを使用できます。実装手順については、MAC ランダム化の実装をご覧ください。このページでは、Android における MAC ランダム化の動作について説明します。 デバイスは、Wi-Fi ネットワークまたはアクセス ポイントへの接続時に、MAC アドレスを使用します。これらの MAC アドレスは暗号化されずに送信されるため、キャプチャされてユーザーの位置情報のトラッキングに使用される可能性があります。従来、デバイスは Wi-Fi ネットワークへの関連付けを行う際に、出荷時 MAC アドレスを使用していました。出荷時 MAC アドレスはグローバルに一意であり、かつ静的
Pixel Update Bulletin—June 2024 Stay organized with collections Save and categorize content based on your preferences. Published June 11, 2024 The Pixel Update Bulletin contains details of security vulnerabilities and functional improvements affecting supported Pixel devices (Google devices). For Google devices, security patch levels of 2024-06-05 or later address all issues in this bulletin and a
Android 13 以降、Android には超広帯域無線(UWB)技術(サポートされているデバイス間で非常に安全かつ正確な距離測定を可能にする技術)のデフォルトのフレームワーク実装が含まれています。デバイス メーカーは、プラットフォーム AOSP UWB スタックをオプション モジュールとして使用できます。モジュールの詳細については、モジュール: UWB をご覧ください。 アーキテクチャ UWB スタックは、図 1 に示すように、UWB メインライン モジュールと UWB チップベンダーが提供する HAL 実装で構成されます。 図 1. UWB スタックのアーキテクチャ AOSP スタック AOSP UWB スタックは、オプション モジュール com.google.android.uwb としてパッケージ化されており、これには次のコンポーネントが含まれています。 UWB プラットフォー
ネットワーク タイム検出 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Android デバイスは自動的にネットワーク ソースから正しい Unix エポック時刻を取得しようとします。Android は SNTP プロトコルを使用します。SNTP プロトコルは UDP プロトコルを使用して時刻情報を取得します。 このページで説明するコンポーネントは、ネットワーク タイムオリジンと呼ばれる自動時刻検出システムの一部です。自動時刻検出がデバイスでサポートされており、time_detector サービスでその使用が設定されている場合は、ネットワーク タイムサーバーからのタイム信号を使用して、Android デバイスのシステム クロックが設定されます。 デフォルトでは Android はネットワーク タイムオリジンをメインの自動時刻検出オリジンとして使用します。
Google Pixel のアップデートに関する公開情報 - 2024 年 4 月 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 2024 年 4 月 2 日公開 Google Pixel のアップデートに関する公開情報には、サポート対象の Google Pixel デバイス(Google デバイス)に影響を与えるセキュリティの脆弱性や機能強化の詳細を掲載しています。Google デバイスでは、セキュリティ パッチレベル 2024-04-05 以降において、この公開情報に掲載されているすべての問題と、2024 年 4 月の Android のセキュリティに関する公開情報に掲載されているすべての問題に対処しています。デバイスのセキュリティ パッチレベルを確認するには、Android のバージョンを確認して更新する方法をご覧ください。 パッチレベル 2024
ブロードキャスト ラジオ スタックは、図 1 に示すコンポーネントで構成されています。 図 1. ブロードキャスト ラジオ アーキテクチャ。 ラジオ リファレンス アプリ ラジオの制御を実装する方法について詳しくは、ラジオの制御の実装をご覧ください。 Java ラジオアプリのサンプル(packages/apps/Car/Radio)はリファレンス実装として機能します。アプリサービスは、サービスの開始時に、ラジオ チューナーを開くようラジオ マネージャーにリクエストします。これにより、アプリはラジオ チューナーにリクエストを送信して、特定のラジオ放送局や周波数にチューニングするか、次に利用可能なラジオ放送局をシークすることができます。アプリは、ラジオのラジオ マネージャーとラジオ チューナーから、現在の番組情報、ラジオ番組リスト、構成、ベンダー定義パラメータなどに関する更新情報を受け取ります
コントリビューター向け AOSP Java コードスタイル コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このページのコードスタイルは、Android オープンソース プロジェクト(AOSP)に Java コードを投稿する際の厳格なルールです。通常、このルールを遵守していない場合、Android プラットフォームへの投稿は認められません。既存のすべてのコードがこのルールに準拠しているわけではありませんが、新しいコードに関しては準拠が必要です。多様性を受容するエコシステムにするために使用する用語や避けるべき用語の例については、不適切な表現の回避をご覧ください。 一貫性を保つ 非常にシンプルなルールとして、「一貫性を保つ」ことが挙げられます。コードを編集する場合、その前にまず、時間をかけてコード全体を確認して、スタイルを判別してください。既存のコードで if
Android 10 でデバイス ID の権限が変更され、すべてのデバイス ID が READ_PRIVILEGED_PHONE_STATE 権限によって保護されるようになりました。Android 10 より前は、永続的なデバイス ID(IMEI / MEID、IMSI、SIM、ビルドシリアル)が READ_PHONE_STATE ランタイム権限で保護されていました。READ_PRIVILEGED_PHONE_STATE 権限は、プラットフォーム キーで署名されたアプリと特権システムアプリにのみ付与されます。 新しい権限の要件について詳しくは、TelephonyManager.java と Build.java の Javadoc ページをご覧ください。 この変更は、次の API に影響します。 TelephonyManager#getDeviceId TelephonyManager#g
A/B アップデートの実装 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 A/B システム アップデートを実装しようとする OEM や SoC ベンダーは、ブートローダーが boot_control HAL を実装し、正しいパラメータをカーネルに渡すようにします。 ブート コントロール HAL の実装 A/B 対応ブートローダーは、boot_control HAL を hardware/libhardware/include/hardware/boot_control.h に実装する必要があります。実装をテストするには、system/extras/bootctl ユーティリティおよび system/extras/tests/bootloader/ を使用します。 次の状態マシンも実装する必要があります。 図 1. ブートローダーの状態マシン カーネルのセ
ブートイメージ ヘッダー コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Android 9 では、ブートイメージ ヘッダーにバージョン フィールドが導入され、下位互換性を維持しながらヘッダーを更新できるようになりました。ブートローダーはヘッダー バージョン フィールドを確認し、それに応じてヘッダーを解析する必要があります。以下に、デバイスとブートイメージ ヘッダー バージョンの対応を示します。 Android 13 を搭載したデバイスは、ブートイメージ ヘッダー バージョン 3 または 4 を使用できます。汎用カーネル イメージ(GKI)アーキテクチャをサポートするデバイスの場合、バージョン 4 がプライマリ ブートイメージであり、ブートイメージ ヘッダーの os_version フィールドがゼロでなければなりません。デバイスのブートローダーは、代わりに
Android は、業界最高レベルのセキュリティ機能を搭載することで、Android のプラットフォームとエコシステムの安全を維持しています。Android の強固なセキュリティ モデルと厳格なセキュリティ プログラムの詳細をご覧ください。
Android セキュリティ情報 - 2023 年 12 月 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 2023 年 12 月 4 日公開 | 2024 年 1 月 22 日更新Android セキュリティ情報には、Android デバイスに影響を与えるセキュリティ脆弱性の詳細が含まれています。セキュリティ パッチ レベル 2023-12-05 以降では、これらすべての問題に対処します。デバイスのセキュリティ パッチ レベルを確認する方法については、 「 Android バージョンを確認して更新する 」を参照してください。 Android パートナーには、公開の少なくとも 1 か月前にすべての問題が通知されます。これらの問題に対するソース コード パッチは Android オープン ソース プロジェクト (AOSP) リポジトリにリリースされており、
Android のオーディオ ハードウェア抽象化レイヤ(HAL)は、android.media の高レベルのオーディオ固有フレームワーク API を基盤となるオーディオ ドライバとハードウェアに接続します。このセクションでは、実装の手順とパフォーマンス改善のヒントについて説明します。 Android のオーディオ アーキテクチャでは、音声機能の実装方法の定義と、実装に関連するソースコードが示されます。 図 1. Android オーディオ アーキテクチャ アプリケーション フレームワーク アプリケーション フレームワークには、android.media API を利用してオーディオ ハードウェアと通信するアプリコードが含まれています。このコードは対応する JNI グルークラスを内部で呼び出して、オーディオ ハードウェアと通信するネイティブ コードにアクセスします。 JNI android.
プロファイルに基づく最適化(PGO)の使用 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Android ビルドシステムは、ブループリント ビルドルールを持つネイティブ Android モジュールにおいて、Clang のプロファイルに基づく最適化(PGO)の使用をサポートします。このページでは、Clang の PGO について説明し、PGO に使用するプロファイルを継続的に生成して更新する方法と、PGO とビルドシステムを統合する方法を(ユースケースとともに)示します。 注意: このドキュメントでは、Android プラットフォームでの PGO の使用について説明します。Android アプリから PGO を使用する方法については、こちらのページをご覧ください。 Clang の PGO について Clang は、2 種類のプロファイルを使用して、プロファ
Android は、各種のフォーム ファクタを持つさまざまなデバイス用に作成されたオープンソースのソフトウェア スタックです。プラットフォームの構築やコントリビューションに関する詳細をご覧ください。
Android Flash Tool コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Android Flash Tool を使用すると、開発とテスト用に Android ビルドをデバイスにフラッシュできます。フラッシュを行うには、開発用のマシンと Android デバイスが必要です。 Flash Tool を実行するための最小要件 開発マシンは、次の要件を満たす必要があります。 ブラウザ: WebUSB をサポートする任意のブラウザ(例: Chrome、Edge 79 以降) プラットフォーム:Linux macOS ChromeOS Windows(USB ドライバの追加が必要) Windows ドライバをインストールする Windows マシン上で Fastboot を使用してデバイスをフラッシュするには、Android SDK のカスタム USB
SELinux ポリシーの作成 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Android Open Source Project(AOSP)は、すべての Android デバイスに共通するアプリケーションとサービスに堅牢な基本ポリシーを提供します。このポリシーは、AOSP のコントリビューターによって定期的に改訂されます。デバイス上の最終的なポリシーは、約 90~95% がコアポリシー、残りの 5~10% がデバイス固有のカスタマイズで構成されることが期待されます。この記事では、デバイス固有のカスタマイズと、デバイス固有のポリシーの作成方法を主に説明しています。また、それに伴う注意点も説明しています。 デバイスの起動 デバイス固有のポリシーを作成するには、次の手順に従います。 permissive モードで実行する デバイスが permissive
Arm Memory Tagging 拡張機能 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Arm v9 では、タグ付きメモリのハードウェア実装である Arm Memory Tagging 拡張機能(MTE)が導入されました。 大まかに言うと、MTE は各メモリ割り当て / 割り当て解除に追加のメタデータをタグ付けし、タグをメモリ位置に割り当てます。タグは、そのメモリ位置を参照するポインタに関連付けることができます。CPU は実行時に、ポインタとメタデータのタグが読み込みと保存のそれぞれで一致するかどうかをチェックします。 Android 12 では、カーネルとユーザー空間のヒープメモリ アロケータによって各割り当てをメタデータで拡張できます。これにより、コードベースにおけるメモリ安全性のバグの最も一般的な原因である、解放後の使用とバッファ オーバーフ
独自のクラウド エミュレータを作成する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 この記事では、ウェブサービスとして AAOS エミュレータを実行し、ウェブブラウザでリモートからアクセスできるようにする方法を説明します。それにより、Google Cloud Compute Engine を通じて、エンドツーエンドかつ最小限の実行可能なリファレンスを配信できるようになります。そのサービスは、任意のパブリックまたはプライベートのクラウド プラットフォーム上で使用できます。 目的 構成と設定を一元化することで、会社全体、サプライヤー、在宅勤務の開発者が AAOS エミュレータにアクセスできるようにします。それにより、AAOS エミュレータを効率的に管理およびアップグレードできるようになり、個々のユーザーが使用するローカルマシンをセットアップおよび管理する時
HDMI-CEC コントロール サービス コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 High-Definition Multimedia Interface Consumer Electronics Control(HDMI-CEC)標準では、マルチメディア関連の消費者製品が相互に通信と情報交換を行うことができます。HDMI-CEC は、Remote Control Passthrough や System Audio Control など、多くの機能をサポートしていますが、最も多く利用されているのは One Touch Play です。One Touch Play を使用すると、メディアソース デバイスを使用してテレビをオンにしたり、入力ポートを自動的に切り替えたりできます。そのため、Chromecast からブルーレイ プレーヤーに切り替えるとき
Android Flash Tool コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Android Flash Tool を使用すると、開発やテスト用に Android ビルドをデバイスにフラッシュできます。フラッシュを行うには、開発用のマシンと Android デバイスが必要です。 Flash Tool を実行するための最小要件 開発マシンは、次の要件を満たす必要があります。 ブラウザ: WebUSB をサポートする任意のブラウザ(例: Chrome、Edge 79 以降) プラットフォーム:Linux macOS Chrome OS Windows(USB ドライバの追加が必要) Windows ドライバをインストールする Windows マシン上で Fastboot を使用してデバイスをフラッシュするには、Android SDK のカスタム USB
Wi-Fi 低レイテンシ モード コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 Android 10 では Wi-Fi lock API が拡張され、遅延に左右されるアプリで Wi-Fi を低遅延モードに設定できます。低遅延モードは、次のすべての条件が満たされると開始されます。 Wi-Fi が有効で、デバイスがインターネットに接続されている。 アプリが作成、獲得した Wi-Fi ロックがフォアグラウンドで実行されている。 画面が ON になっている。 デバイスで低遅延モードをサポートするには、デバイス メーカーが WLAN ドライバとベンダー HAL を更新する必要があります。低遅延モードでは、省電力モード(IEEE 802.11 標準では Doze 状態とも呼ばれます)がフレームワークによって明示的に無効になります。ドライバレイヤとファームウェア レイ
アプリに署名することで、開発者は複雑なインターフェースや権限を作成しなくてもアプリの作成者を特定し、アプリを更新できます。Android プラットフォームで実行されるすべてのアプリには、デベロッパーによる署名が必要です。署名なしでアプリのインストールを試みた場合は、Google Play または Android デバイスのパッケージ インストーラによってインストールが拒否されます。 Google Play におけるアプリ署名は、Google が保証するデベロッパーの信頼性と、デベロッパーが保証するアプリの信頼性をつなぐ役割を果たします。開発されたアプリが、修正などが施されないまま Android デバイスにインストールされることをデベロッパーに対して証明します。アプリの動作についてデベロッパーの責任を明確にする役目もあります。 Android では、アプリをアプリ サンドボックスに配置する
次のページ
このページを最初にブックマークしてみませんか?
『Android Open Source Project』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く