WLAN

Das WLAN-Modul ist aktualisierbar. Das bedeutet, dass es außerhalb des normalen Android-Releasezyklus Updates für Funktionen erhalten kann. 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 profitieren von einer einheitlichen WLAN-Erfahrung auf allen Android-Geräten und von Fehlerkorrekturen bei Interoperabilitätsproblemen durch Modul-Updates.

  • App-Entwickler profitieren von einer geringeren Plattformfragmentierung.

  • OEMs können die Anforderungen von Mobilfunkanbietern erfüllen und gleichzeitig die Kosten für individuelle Anpassungen senken, da sie nicht verschiedene Implementierungen derselben Anforderungen auf unterschiedliche Weise benötigen.

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, die aus frameworks/base/core/res/res extrahiert wurden)
      • AndroidManifest.xml
      • Android.bp
    • WifiDialog/ (Neu in Android 13: Die App zum Starten von vom Dienst angeforderten Nutzerdialogfeldern wird hier gespeichert.)
      • src/
        • com/android/wifi/dialog (Enthält die Aktivität, über die die Dialogfelder gestartet werden)
      • AndroidManifest.xml
      • Android.bp

Die vorherigen 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 aus frameworks/base/wifi verschieben

Patch-Datei 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 aus frameworks/opt/net/wifi verschieben

Um den Patch aus frameworks/opt/net/wifi zu verschieben, sind komplexe Schritte erforderlich, da die Verzeichnishierarchie während der Migration geändert wurde.

Teile 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 packages/modules/Wifi anwenden

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

Die beiden Commits in einem Commit zusammenfassen

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 weiterhin Teil des AOSP-Builds des OEM sind.

  • wificond-native 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 keine Dateien verschoben, in zukünftigen Versionen ist das aber möglich. Um den Aufwand für die Übertragung von Änderungen am Dateispeicherort zu verringern, empfehlen wir, so viele Änderungen wie möglich in AOSP zu übertragen, nachdem sie auf Android 11 übertragen oder proprietäre Erweiterungen so umgestaltet wurden, dass sie formale Android-APIs oder Vendor-HAL-Erweiterungen verwenden, um sie vom AOSP-Code zu entkoppeln.

Modulformat

Das WLAN-Modul (com.android.wifi) ist im APEX-Format verfügbar und kann auf Geräten mit Android 11 oder höher verwendet werden. 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 nur über stabile @SystemApi mit dem Framework (keine @hide-API-Nutzung) und ist mit einer Google-Signatur anstelle einer Plattformsignatur signiert.

Personalisierung

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

WLAN-Anpassung

Abbildung 2: Anpassen des WLAN-Moduls

  • Bei kleineren Anpassungen können Sie Einstellungen im RRO config aktivieren oder deaktivieren.
  • Wenn Sie mehr Kontrolle haben möchten, können Sie Konfigurationswerte für jeden als @SystemAPI angezeigten Konfigurationsschlüssel des Mobilfunkanbieters anpassen.

Laufzeit-Ressourcen-Overlays verwenden

Sie können das WLAN-Modul anpassen, indem Sie die Standardkonfigurationen mit 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 festgelegt ist und das vom WLAN-Modul bereitgestellte Ressourcen-APK den Paketnamen com.google.android.wifi.resources hat, müssen Sie das Overlay-APK targetPackage auf com.google.android.wifi.resources festlegen, um WLAN-Konfigurationen erfolgreich zu überschreiben.

Konfigurationsspeicherformat migrieren

Das WLAN-Modul kann nur das AOSP-Speicherformat für die WLAN-Konfiguration parsen. Wenn Sie das Speicherformat für die WLAN-Konfiguration (einschließlich der Liste der gespeicherten Netzwerke 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 Konvertierung 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 gemeinsam genutzten WLAN-Speicherdatei abzurufen, der in das AOSP-Format konvertiert wurde.

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

  • WifiMigration.convertAndRetrieveUserConfigStoreFile(<storeFileId>)

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

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

Auf ausgeblendete WLAN-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 auf Geräten, auf denen das Modul installiert ist, nicht aufgerufen werden. Auf Geräten ohne WLAN-Modul können Sie die @hide-WLAN-APIs weiterhin verwenden. Gehen Sie dazu so vor:

  1. Entfernen Sie die Sichtbarkeitseinschränkungen für framework-wifi unter packages/modules/Wifi/framework/Android.bp, indem Sie das Attribut impl_library_visibility auf „ö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 Bibliothekszugriff auf die @hide-WLAN-APIs zuzulassen. Das Folgende ist beispielsweise eine Build-Regel für ein java_library.

    java_library {
    name: "foo-lib",

    // no sdk_version attribute defined

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

    Wenn Sie den Bibliothekszugriff 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 vor framework in der Liste der libs angezeigt wird. Die Reihenfolge der Abhängigkeiten im Attribut libs ist wichtig.

Auf ausgeblendete Framework-APIs zugreifen

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

  1. Ändern Sie in beiden Dateien, wifi-service-pre-jarjar und service-wifi, das Attribut sdk_version in core_platform.

  2. Fügen Sie sowohl wifi-service-pre-jarjar als auch service-wifi dem Attribut libs die Werte framework und android_system_server_stubs_current hinzu.

  3. Das Ergebnis sollte in etwa so aussehen wie im folgenden Codebeispiel.

    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) überprüft die Funktionen des WLAN-Moduls, indem bei jeder Modulversion eine umfassende Reihe von CTS-Tests ausgeführt wird. Sie können auch die unter WLAN testen, debuggen und optimieren beschriebenen Tests ausführen.