WLAN

Das WLAN-Modul ist aktualisierbar, d. h., es kann Funktionsupdates außerhalb des normalen Android-Releasezyklus erhalten. Dieses Modul enthält die folgenden Komponenten.

Komponenten des WLAN-Moduls

Abbildung 1. Komponenten und Architektur des WLAN-Moduls

Das WLAN-Modul bietet folgende Vorteile:

  • Endnutzer erhalten eine einheitliche WLAN-Nutzung auf allen Android-Geräten und können über Modulaktualisierungen Interoperabilitätsprobleme beheben.

  • App-Entwickler profitieren von einer geringeren Plattformfragmentierung.

  • OEMs können die Anforderungen der Mobilfunkanbieter erfüllen und gleichzeitig die Kosten für individuelle Anpassungen senken, da keine unterschiedlichen Implementierungen derselben Anforderungen erforderlich sind.

Modulgrenze für Android 12 und Android 13

  • packages/modules/Wifi
    • framework
      • java/
        • android/net/wifi (Dateien von frameworks/base/wifi/java)
      • tests/
        • android/net/wifi (Dateien von frameworks/base/wifi/tests)
      • aidl-export/
      • api/
      • Android.bp
    • service/
      • java/
        • com/android/server/wifi (Dateien von frameworks/opt/net/wifi/service/java)
      • tests/
        • com/android/server/wifi (Dateien von frameworks/opt/net/wifi/tests)
      • proto/
      • Android.bp
      • proguard.flags
      • wifi.rc
    • OsuLogin/ (Dateien von frameworks/base/packages/OsuLogin)
    • ServiceResources/ (neu in Android 12; Overlay-APK-Manifest wird hier gespeichert)
      • res/ (neu in Android 11, WLAN-Konfigurationen extrahiert aus frameworks/base/core/res/res)
      • AndroidManifest.xml
      • Android.bp
    • WifiDialog/ (Neu in Android 13: Die App zum Starten von vom Dienst angeforderten Nutzerdialogen wird hier gespeichert.)
      • src/
        • com/android/wifi/dialog (enthält die Aktivität, über die die Dialogfelder gestartet werden)
      • AndroidManifest.xml
      • Android.bp

Die oben genannten Verzeichnisse enthalten auch Code, der außerhalb der modularen Systemkomponente und an seinem aktuellen Speicherort verbleibt, z. B.:

  • wificond interface (Klassen im Paket android.net.wifi.nl80211, z. B. WifiNl80211Manager)
  • Beispiel-App für Ressourcen-Overlays
  • WifiTrackerLib
  • libwifi_hal
  • libwifi_system
  • libwifi_system_iface

OEMs können die Beispielbefehle verwenden, um ihre Patches aus den ursprünglichen Projektverzeichnissen in das neue Projektverzeichnis zu verschieben.

Patch von frameworks/base/wifi verschieben

Patchdatei in „root/frameworks/base/wifi“ generieren

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

Patchdatei auf „root/packages/modules/Wifi“ anwenden

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

Patch von frameworks/opt/net/wifi verschieben

Zum Verschieben des Patch von frameworks/opt/net/wifi sind komplexe Schritte erforderlich, da die Verzeichnishierarchie während der Migration geändert wurde.

Teilen Sie den Commit in frameworks/opt/net/wifi in zwei Commits auf, einen für service/ und einen für tests/.

HEAD-Commit migrieren

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

Zwei Commit-Patch-Dateien generieren

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

Die beiden Patches auf Pakete/Module/WLAN anwenden

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

Squashing der beiden Commits wieder zu einem Commit

git rebase -i

Ändern Sie den Vorgang des zweiten Commits in squash.

Bearbeiten Sie die Commit-Nachricht nach Bedarf.

Modulgrenze für Android 11

Der WLAN-Dienst wird weiterhin im Systemdienstprozess ausgeführt. Das WLAN-Modul enthält den gesamten Code in packages/modules/Wifi, einschließlich des folgenden.

  • SDK- und Dienstklassen für WifiService, WifiP2pService, WifiAwareService, WifiScannerService und WifiRttService
  • OsuLogin
  • ServiceWifiResources

Das Modul schließt die folgenden Komponenten aus, die Teil des AOSP-Builds des OEMs bleiben.

  • Native wificond-Komponente in system/connectivity/wificond
  • wificond-Schnittstelle (Klassen im Paket android.net.wifi.nl80211, z. B. WifiNl80211Manager)
  • android.net.wifi.SoftApConfToXmlMigrationUtil
  • android.net.wifi.WifiNetworkScoreCache
  • android.net.wifi.WifiMigration
  • WifiTrackerLib
  • libwifi_hal
  • libwifi_system
  • libwifi_system_iface

Unter Android 11 werden Dateien nicht verschoben, in zukünftigen Releases kann dies jedoch der Fall sein. Um den Aufwand für die Portierung von Änderungen des Dateispeicherorts zu verringern, empfehlen wir, möglichst viele Änderungen an AOSP vorgelagert zu machen (nach der Portierung auf Android 11 oder nach der Refaktorierung proprietärer Erweiterungen, um offizielle Android-APIs oder HAL-Erweiterungen des Anbieters zu verwenden, um sie vom AOSP-Code zu entkoppeln.)

Modulformat

Das WLAN-Modul (com.android.wifi) hat das APEX-Format und ist für Geräte mit Android 11 oder höher verfügbar. Die APEX-Datei enthält die folgenden Komponenten.

  • SDK-Bibliothek (framework-wifi.jar)
  • Dienstbibliothek (service-wifi.jar)
  • OsuLogin APK (OsuLoginGoogle.apk)
  • Ressourcen-APK (ServiceWifiResourcesGoogle.apk)
  • WFA-Zertifikate

Modulabhängigkeiten

Das WLAN-Modul hängt von den folgenden Komponenten ab.

  • Konnektivität
  • Telefonie
  • Proto-Bibliotheken
  • Sonstige Systemkomponenten
  • WLAN-HALs
  • wificond
  • bouncycastle
  • ksoap2
  • libnanohttpd

Dieses Modul interagiert mit dem Framework nur über stabile @SystemApi (keine @hide API-Nutzung) und ist mit einer Google-Signatur statt einer Plattformsignatur signiert.

Personalisierung

Das WLAN-Modul unterstützt keine direkte Anpassung. Sie können die Konfiguration jedoch mithilfe von Runtime Resource Overlays (RROs) oder Mobilfunkanbieterkonfigurationen anpassen.

WLAN-Anpassung

Abbildung 2: Anpassung des WLAN-Moduls

  • Für kleinere Anpassungen können Sie Einstellungen in der RRO config aktivieren oder deaktivieren.
  • Für mehr Kontrolle kannst du die Konfigurationswerte für jeden als @SystemAPI freigegebenen Konfigurationsschlüssel des Mobilfunkanbieters anpassen.

Laufzeitressourcen-Overlays verwenden

Sie können das WLAN-Modul anpassen, indem Sie die Standardkonfigurationen mithilfe von RROs überschreiben. Eine Liste der überlagerbaren Konfigurationen finden Sie unter packages/modules/Wifi/service/ServiceWifiResources/res/values/overlayable.xml. Weitere Informationen zum Konfigurationsverhalten finden Sie unter packages/modules/Wifi/service/ServiceWifiResources/res/values/config.xml. Eine Beispiel-Overlay-App finden Sie unter device/google/coral/rro_overlays/WifiOverlay/.

Da in der Datei device/google/coral/rro_overlays/WifiOverlay/AndroidManifest.xml das Attribut targetPackage auf com.android.wifi.resources gesetzt wird und das vom WLAN-Modul bereitgestellte Ressourcen-APK den Paketnamen com.google.android.wifi.resources hat, musst du die Overlay-APKs targetPackage auf com.google.android.wifi.resources festlegen, damit WLAN-Konfigurationen eingeblendet werden können.

Speicherformat für die Konfiguration migrieren

Das WLAN-Modul kann nur das AOSP-WLAN-Konfigurationsspeicherformat parsen. Wenn Sie das Speicherformat der WLAN-Konfiguration (einschließlich der gespeicherten Netzwerkliste des Nutzers) zuvor geändert haben, müssen Sie diese Daten in das AOSP-Format konvertieren, wenn Sie ein Gerät auf eine Android-Version aktualisieren, die das WLAN-Modul enthält. Die für diese Umwandlung erforderlichen Hooks befinden sich in der Klasse android.net.wifi.WifiMigration.

Implementieren Sie die Formatkonvertierung in den folgenden Methoden.

  • WifiMigration.convertAndRetrieveSharedConfigStoreFile(<storeFileId>)

    • Wird vom WLAN-Modul aufgerufen, um den Inhalt der WLAN-freigegebenen Speicherdatei abzurufen, die in das AOSP-Format konvertiert wurde.

    • Diese Dateien wurden zuvor (unter Android 10) auf dem Gerät im Ordner /data/misc/wifi gespeichert.

  • WifiMigration.convertAndRetrieveUserConfigStoreFile(<storeFileId>)

    • Wird vom WLAN-Modul aufgerufen, um nutzerspezifische WLAN-Store-Dateiinhalte abzurufen, die in das AOSP-Format konvertiert wurden.

    • Diese Dateien wurden zuvor (unter Android 10) im Ordner /data/misc_ce/<userId>/wifi auf dem Gerät gespeichert.

Auf verborgene Wi-Fi APIs zugreifen

Symbole (Klassen, Methoden, Felder usw.), die im WLAN-Modul mit @hide annotiert sind, sind nicht Teil der öffentlichen API-Oberfläche und können nicht auf Geräten mit installiertem Modul aufgerufen werden. Auf Geräten ohne WLAN-Modul können Sie die @hide WLAN-APIs mit den folgenden Schritten weiterhin verwenden.

  1. Heben Sie die Sichtbarkeitseinschränkungen für framework-wifi unter packages/modules/Wifi/framework/Android.bp auf, indem Sie das Attribut impl_library_visibility in „öffentlich“ ändern.

    java_sdk_library {
    name: "framework-wifi",
    ...
    impl_library_visibility: [
       "//visibility:public", // Add this rule and remove others.
    ],
    ...
}

  2. Ändern Sie die Build-Regel, um den Bibliothekzugriff auf @hide-Wi‑Fi APIs zuzulassen. Das folgende Beispiel zeigt eine Build-Regel für eine java_library.

    java_library {
    name: "foo-lib",

    // no sdk_version attribute defined

    libs: [
        "dependency1",
        "dependency2",
    ],
}

    Wenn Sie den Bibliothekzugriff für foo-lib zulassen möchten, ändern Sie die Build-Regel so:

    java_library {
    name: "foo-lib",

    sdk_version: "core_platform",

    libs: [
        "framework-wifi.impl",
        "framework",
        "dependency1",
        "dependency2",
    ],
}

  3. Achten Sie darauf, dass framework-wifi.impl in der Liste von libs vor framework steht. Die Reihenfolge der Abhängigkeiten im libs-Attribut ist wichtig.

Auf ausgeblendete Framework-APIs zugreifen

Auf Symbole, die außerhalb des WLAN-Moduls mit @hide gekennzeichnet sind, kann nicht über Code im WLAN-Modul zugegriffen werden. Geräte ohne WLAN-Modul können weiterhin @hide-externe APIs (z. B. von framework.jar) in service-wifi verwenden. Dazu müssen Sie die folgenden Änderungen an frameworks/opt/net/wifi/service/Android.bp vornehmen.

  1. Ändern Sie sowohl in wifi-service-pre-jarjar als auch in service-wifi das Attribut sdk_version in core_platform.

  2. Fügen Sie wifi-service-pre-jarjar und service-wifi beide dem libs-Attribut framework und android_system_server_stubs_current hinzu.

  3. Prüfen Sie, ob das Ergebnis dem folgenden Codebeispiel ähnelt.

    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",
    ],
}

Testen

Die Android Compatibility Test Suite (CTS) prüft die Funktionen des WLAN-Moduls, indem für jede Modulversion eine umfassende Reihe von CTS-Tests ausgeführt wird. Sie können auch die unter WLAN testen, debuggen und abstimmen beschriebenen Tests ausführen.