Wi-Fi

Wi-Fi モジュールは更新可能です。つまり、通常の Android リリース サイクル外で機能のアップデートを受信できます。このモジュールには、次のコンポーネントが含まれています。

Wi-Fi モジュールのコンポーネント

図 1. Wi-Fi モジュールのコンポーネントとアーキテクチャ

Wi-Fi モジュールには次のような利点があります。

  • エンドユーザーが、Android デバイス全体で一貫した Wi-Fi エクスペリエンスを得られ、モジュール アップデートを通じて相互運用性の問題を修正できる。

  • アプリ デベロッパーがプラットフォームの断片化を削減できる。

  • OEM が、携帯通信会社の要件を完全に満たしつつ、個別のカスタマイズのコストを削減できる(同じ要件を異なる方法で実装する必要がないため)。

Android 12 と Android 13 のモジュールの境界

  • packages/modules/Wifi
    • framework
      • java/
        • android/net/wififrameworks/base/wifi/java のファイル)
      • tests/
        • android/net/wififrameworks/base/wifi/tests のファイル)
      • aidl-export/
      • api/
      • Android.bp
    • service/
      • java/
        • com/android/server/wififrameworks/opt/net/wifi/service/java のファイル)
      • tests/
        • com/android/server/wififrameworks/opt/net/wifi/tests のファイル)
      • proto/
      • Android.bp
      • proguard.flags
      • wifi.rc
    • OsuLogin/frameworks/base/packages/OsuLogin のファイル)
    • ServiceResources/(Android 12 で新たに導入、オーバーレイ APK マニフェストはここに保存される)
      • res/(Android 11 で新たに導入、frameworks/base/core/res/res から抽出された Wi-Fi 構成)
      • AndroidManifest.xml
      • Android.bp
    • WifiDialog/(Android 13 アプリで新たに導入。サービスによってリクエストされたユーザー ダイアログを起動するための新機能がここに保存される)
      • src/
        • com/android/wifi/dialog(ダイアログの起動元となるアクティビティを格納する)
      • AndroidManifest.xml
      • Android.bp

上記のディレクトリには、モジュラー システム コンポーネントの外や現在の場所に残るコードも含まれます。以下に例を示します。

  • wificond interface(パッケージ android.net.wifi.nl80211 のクラス、WifiNl80211Manager など)
  • サンプル リソース オーバーレイ アプリ
  • WifiTrackerLib
  • libwifi_hal
  • libwifi_system
  • libwifi_system_iface

OEM は、サンプル コマンドを使用して、元のプロジェクト ディレクトリから新しいプロジェクト ディレクトリにパッチを移動できます。

パッチを frameworks/base/wifi から移動する

root/frameworks/base/wifi でパッチファイルを生成

git format-patch -1 commit --stdout > patch-file.txt

root/packages/modules/Wifi にパッチファイルを適用

git am -p2 --directory=framework/ patch-file.txt

パッチを frameworks/opt/net/wifi から移動する

移行においてディレクトリ階層が変更されたため、パッチを frameworks/opt/net/wifi から移動するには複雑な手順が必要になります。

frameworks/opt/net/wifi で、commit を 2 つに分割します(service/ 用と tests/ 用)。

HEAD コミットの移行

git reset HEAD^
git add service/
git commit # Enter your commit message. Call this commit service-commit
git add tests/
git commit # Enter your commit message. Call this commit test-commit

2 つの commit パッチファイルを生成

git format-patch -1 service-commit --stdout > service-patch.txt
git format-patch -1 test-commit --stdout > test-patch.txt

2 つのパッチを package/modules/Wifi に適用

git am service-patch.txt
git am -p1 --directory=service/ test-patch.txt

2 つの commit を 1 つに統合

git rebase -i

2 つ目の commit のオペレーションを squash に変更します。

必要に応じて commit メッセージを編集します。

Android 11 のモジュールの境界

Wi-Fi サービスは、システム サービス プロセス内で実行され続けます。Wi-Fi モジュールには、下記を含め、packages/modules/Wifi のすべてのコードが含まれています。

  • WifiServiceWifiP2pServiceWifiAwareServiceWifiScannerServiceWifiRttService の SDK とサービスクラス
  • OsuLogin
  • ServiceWifiResources

このモジュールでは、OEM の AOSP ビルドの一部として残る次のコンポーネントは除外されます。

  • system/connectivity/wificondwificond ネイティブ コンポーネント
  • wificond インターフェース(パッケージ android.net.wifi.nl80211 のクラス、WifiNl80211Manager など)
  • android.net.wifi.SoftApConfToXmlMigrationUtil
  • android.net.wifi.WifiNetworkScoreCache
  • android.net.wifi.WifiMigration
  • WifiTrackerLib
  • libwifi_hal
  • libwifi_system
  • libwifi_system_iface

Android 11 ではファイルは移動されていませんが、今後のリリースでは移動される可能性があります。ファイルの場所の変更を移植する手間を軽減するため、可能な限り多くの変更を AOSP にアップストリームすることをおすすめします(Android 11 に移植した後、または、正式な Android API かベンダーの HAL 拡張機能を使用して AOSP コードから切り離すために独自の拡張機能をリファクタリングした後)。

モジュールの形式

Wi-Fi モジュール(com.android.wifi)は APEX 形式であり、Android 11 以降を搭載したデバイスで利用できます。APEX ファイルには次のコンポーネントが含まれています。

  • SDK ライブラリ(framework-wifi.jar
  • サービス ライブラリ(service-wifi.jar
  • OsuLogin APK(OsuLoginGoogle.apk
  • リソース APK(ServiceWifiResourcesGoogle.apk
  • WFA 証明書

モジュールの依存関係

Wi-Fi モジュールは次のコンポーネントに依存します。

  • 接続
  • 電話
  • proto ライブラリ
  • その他のシステム コンポーネント
  • Wi-Fi HAL
  • wificond
  • bouncycastle
  • ksoap2
  • libnanohttpd

このモジュールは、@hide API は使用せず安定版の @SystemApi のみを使用してフレームワークと通信し、プラットフォーム署名ではなく Google 署名で署名されます。

カスタマイズ

Wi-Fi モジュールは直接のカスタマイズをサポートしていませんが、ランタイム リソース オーバーレイ(RRO)または携帯通信会社の構成を使用して構成をカスタマイズできます。

Wi-Fi のカスタマイズ

図 2. Wi-Fi モジュールのカスタマイズ

  • 小規模なカスタマイズの場合は、RRO config の設定を有効または無効にします。
  • 詳細な制御を行うには、@SystemAPI として公開される携帯通信会社の構成キーの構成値をカスタマイズします。

ランタイム リソース オーバーレイを使用する

RRO を使用してデフォルト構成をオーバーライドすることで、Wi-Fi モジュールをカスタマイズできます。オーバーレイ可能な設定のリストについては、packages/modules/Wifi/service/ServiceWifiResources/res/values/overlayable.xml をご覧ください。構成動作の詳細については、packages/modules/Wifi/service/ServiceWifiResources/res/values/config.xml をご覧ください。サンプル オーバーレイ アプリについては、device/google/coral/rro_overlays/WifiOverlay/ をご覧ください。

device/google/coral/rro_overlays/WifiOverlay/AndroidManifest.xml ファイルで targetPackage 属性が com.android.wifi.resources に設定され、Wi-Fi モジュールで配信されるリソース APK のパッケージ名が com.google.android.wifi.resources であるため、オーバーレイ APKS targetPackagecom.google.android.wifi.resources に設定して、Wi-Fi 構成を正しくオーバーレイする必要があります。

構成ストレージ形式を移行する

Wi-Fi モジュールがパースできる Wi-Fi 構成ストレージ形式は、AOSP のみです。以前に Wi-Fi 構成ストレージ形式(ユーザーが保存したネットワーク リストを含む)を変更した場合は、Wi-Fi モジュールを含む Android リリースにデバイスをアップグレードする際、そのデータを AOSP 形式に変換する必要があります。この変換に必要なフックは android.net.wifi.WifiMigration クラスにあります。

形式変換を実装するメソッドは次のとおりです。

  • WifiMigration.convertAndRetrieveSharedConfigStoreFile(<storeFileId>)

    • AOSP 形式に変換された Wi-Fi 共有ストアファイルのコンテンツを取得するために Wi-Fi モジュールによって呼び出されます。

    • これらのファイルは、以前(Android 10 の場合)はデバイスの /data/misc/wifi フォルダに保存されていました。

  • WifiMigration.convertAndRetrieveUserConfigStoreFile(<storeFileId>)

    • AOSP 形式に変換された Wi-Fi ユーザー固有ストアファイルのコンテンツを取得するために Wi-Fi モジュールによって呼び出されます。

    • これらのファイルは、以前(Android 10 の場合)はデバイスの /data/misc_ce/<userId>/wifi フォルダに保存されていました。

非公開の Wi-Fi API にアクセスする

Wi-Fi モジュール内で @hide アノテーションが付いたシンボル(クラス、メソッド、フィールドなど)は、公開 API サーフェスの一部ではなく、モジュールがインストールされたデバイスではアクセスできません。Wi-Fi モジュールを含まないデバイスでは、次の手順で引き続き @hide Wi-Fi API を使用できます。

  1. impl_library_visibility 属性を public に変更することで、packages/modules/Wifi/framework/Android.bpframework-wifi に配置されていた公開設定に関する制限を削除します。

    java_sdk_library {
        name: "framework-wifi",
        ...
        impl_library_visibility: [
           "//visibility:public", // Add this rule and remove others.
        ],
        ...
    }
    
  2. ライブラリによる @hide Wi-Fi API へのアクセスを許可するようにビルドルールを変更します。たとえば、java_library のビルドルールは次のとおりです。

    java_library {
        name: "foo-lib",
    
        // no sdk_version attribute defined
    
        libs: [
            "dependency1",
            "dependency2",
        ],
    }
    

    ライブラリによる foo-lib へのアクセスを許可するには、ビルドルールを次のように変更します。

    java_library {
        name: "foo-lib",
    
        sdk_version: "core_platform",
    
        libs: [
            "framework-wifi.impl",
            "framework",
            "dependency1",
            "dependency2",
        ],
    }
    
  3. libs のリストで framework の前に framework-wifi.impl が表示されていることを確認します。libs 属性内の依存関係の順序は重要です。

非表示のフレームワーク API にアクセスする

Wi-Fi モジュール外で @hide アノテーションが付いたシンボルは、Wi-Fi モジュール内のコードではアクセスできません。Wi-Fi モジュールを含まないデバイスでは、frameworks/opt/net/wifi/service/Android.bp に次の変更を行うことで、引き続き service-wifi@hide 外部 API(framework.jar など)を使用できます。

  1. wifi-service-pre-jarjarservice-wifi両方で、sdk_version 属性を core_platform に変更します。

  2. wifi-service-pre-jarjarservice-wifi両方で、libs 属性に frameworkandroid_system_server_stubs_current を追加します。

  3. 結果が次のコードサンプルのようになることを確認します。

    java_library {
        name: "wifi-service-pre-jarjar",
        ...
        sdk_version: "core_platform",
        ...
        libs: [
            ...
            "framework",
            "android_system_server_stubs_current",
        ],
    }
    ...
    java_library {
        name: "service-wifi",
        ...
        sdk_version: "core_platform",
        ...
        libs: [
            ...
            "framework",
            "android_system_server_stubs_current",
        ],
    }
    

テスト

Android 互換性テストスイート(CTS)は、すべてのモジュール リリースで包括的な CTS テストを実行し、Wi-Fi モジュールの機能を検証します。また、Wi-Fi のテスト、デバッグ、チューニングに記載されているテストも実行できます。