WLAN

Das Wi-Fi-Modul ist aktualisierbar, was bedeutet, dass es außerhalb des normalen Android-Release-Zyklus Funktionsupdates erhalten kann. Dieses Modul enthält die folgenden Komponenten.

Komponenten des Wi-Fi-Moduls

Abbildung 1. Komponenten und Architektur des Wi-Fi-Moduls

Das Wi-Fi-Modul bietet die folgenden Vorteile.

  • Endbenutzer erhalten ein konsistentes WLAN-Erlebnis auf allen Android-Geräten und können durch Modulaktualisierungen Interoperabilitätsprobleme beheben.

  • App-Entwickler profitieren von einer geringeren Plattformfragmentierung.

  • OEMs können die Anforderungen der Netzbetreiber erfüllen und gleichzeitig die Kosten für individuelle Anpassungen senken (da sie keine unterschiedlichen 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 aus frameworks/base/wifi/java )
      • tests/
        • android/net/wifi (Dateien aus frameworks/base/wifi/tests )
      • aidl-export/
      • api/
      • Android.bp
    • service/
      • java/
        • com/android/server/wifi (Dateien aus frameworks/opt/net/wifi/service/java )
      • tests/
        • com/android/server/wifi (Dateien aus frameworks/opt/net/wifi/tests )
      • proto/
      • Android.bp
      • proguard.flags
      • wifi.rc
    • OsuLogin/ (Dateien aus frameworks/base/packages/OsuLogin )
    • ServiceResources/ (neu in Android 12, Overlay-APK-Manifest wird hier gespeichert)
      • res/ (neu in Android 11, Wi-Fi-Konfigurationen aus frameworks/base/core/res/res extrahiert)
      • AndroidManifest.xml
      • Android.bp
    • WifiDialog/ (neu in Android 13 App zum Starten von Benutzerdialogen, die vom Dienst angefordert werden, wird hier gespeichert.)
      • src/
        • com/android/wifi/dialog (Enthält die Aktivität, von der aus die Dialoge gestartet werden)
      • AndroidManifest.xml
      • Android.bp

Die oben genannten Verzeichnisse enthalten auch Code, der außerhalb der modularen Systemkomponente und an ihrem aktuellen Speicherort verbleibt, zum Beispiel:

  • wificond interface (Klassen im Paket android.net.wifi.nl80211 , zum Beispiel WifiNl80211Manager )
  • Beispiel-Ressourcen-Overlay-App
  • 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.

Verschieben eines Patches von „frameworks/base/wifi“.

Generieren der Patch-Datei in root/frameworks/base/wifi

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

Anwenden der Patch-Datei auf root/packages/modules/Wifi

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

Verschieben eines Patches von „frameworks/opt/net/wifi“.

Um den Patch von frameworks/opt/net/wifi zu verschieben, 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/ .

Migration des HEAD-Commits

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

Generieren von zwei Commit-Patch-Dateien

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

Anwenden der beiden Patches auf Pakete/Module/WLAN

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

Die beiden Commits wieder zu einem Commit zusammenfassen

git rebase -i

Ändern Sie die Operation des zweiten Commits in squash .

Bearbeiten Sie die Commit-Nachricht entsprechend.

Modulgrenze für Android 11

Der Wi-Fi-Dienst wird weiterhin innerhalb des Systemdienstprozesses ausgeführt. Das Wi-Fi-Modul enthält den gesamten Code in packages/modules/Wifi einschließlich des Folgenden.

  • SDK und Serviceklassen 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.

  • native wificond Komponente in system/connectivity/wificond
  • wificond Schnittstelle (Klassen im Paket android.net.wifi.nl80211 , zum Beispiel WifiNl80211Manager )
  • android.net.wifi.SoftApConfToXmlMigrationUtil
  • android.net.wifi.WifiNetworkScoreCache
  • android.net.wifi.WifiMigration
  • WifiTrackerLib
  • libwifi_hal
  • libwifi_system
  • libwifi_system_iface

Android 11 verschiebt keine Dateien, zukünftige Versionen könnten dies jedoch tun. Um den mit der Portierung von Dateispeicherortänderungen verbundenen Aufwand zu reduzieren, empfehlen wir, so viele Änderungen wie möglich in AOSP vorzulagern (nachdem sie auf Android 11 portiert wurden oder proprietäre Erweiterungen umgestaltet wurden, um formale Android-APIs oder HAL-Erweiterungen von Anbietern zu verwenden, um sie vom AOSP-Code zu entwirren.

Modulformat

Das Wi-Fi-Modul ( com.android.wifi ) liegt im APEX- Format vor 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 Wi-Fi-Modul ist von den folgenden Komponenten abhängig.

  • Konnektivität
  • Telefonie
  • Proto-Bibliotheken
  • Verschiedene Systemkomponenten
  • WiFi-HALs
  • wificond
  • bouncycastle
  • ksoap2
  • libnanohttpd

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

Anpassen

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

Wi-Fi-Anpassung

Abbildung 2. Anpassung des Wi-Fi-Moduls

  • Für kleine Anpassungen aktivieren oder deaktivieren Sie die Einstellungen in der RRO- config .
  • Passen Sie für mehr Kontrolle die Konfigurationswerte für jeden als @SystemAPI bereitgestellten Netzbetreiber-Konfigurationsschlüssel an.

Verwendung von Laufzeitressourcen-Overlays

Sie können das Wi-Fi-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 . Einzelheiten 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/ .

Weil die Datei device/google/coral/rro_overlays/WifiOverlay/AndroidManifest.xml das Attribut targetPackage auf „ com.android.wifi.resources “ setzt und die vom Wi-Fi-Modul bereitgestellte Ressourcen-APK den Paketnamen com.google.android.wifi.resources , müssen Sie das Overlay-APKS- targetPackage auf com.google.android.wifi.resources setzen, um WLAN-Konfigurationen erfolgreich zu überlagern.

Konfigurationsspeicherformat wird migriert

Das Wi-Fi-Modul kann nur das AOSP-Wi-Fi-Konfigurationsspeicherformat analysieren. Wenn Sie zuvor das Speicherformat der Wi-Fi-Konfiguration (einschließlich der gespeicherten Netzwerkliste des Benutzers) 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 Wi-Fi-Modul enthält. Die für diese Konvertierung benötigten Hooks befinden sich in der Klasse android.net.wifi.WifiMigration .

Implementieren Sie die Formatkonvertierung in den folgenden Methoden.

  • WifiMigration.convertAndRetrieveSharedConfigStoreFile(<storeFileId>)

    • Wird vom Wi-Fi-Modul aufgerufen, um die Inhalte der gemeinsam genutzten Wi-Fi-Speicherdatei abzurufen, die in das AOSP-Format konvertiert wurden.

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

  • WifiMigration.convertAndRetrieveUserConfigStoreFile(<storeFileId>)

    • Wird vom Wi-Fi-Modul aufgerufen, um benutzerspezifische Wi-Fi-Speicherdateiinhalte abzurufen, die in das AOSP-Format konvertiert wurden.

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

Zugriff auf versteckte WLAN-APIs

Symbole (Klassen, Methoden, Felder usw.), die im Wi-Fi-Modul mit @hide annotiert sind, sind nicht Teil seiner öffentlichen API-Oberfläche und können auf Geräten, auf denen das Modul installiert ist, nicht aufgerufen werden. Geräte, die nicht über das Wi-Fi-Modul verfügen, können mit den folgenden Schritten weiterhin @hide Wi-Fi-APIs verwenden.

  1. Entfernen Sie die Sichtbarkeitsbeschränkungen für framework-wifi unter packages/modules/Wifi/framework/Android.bp indem Sie das Attribut „ impl_library_visibility in „public“ ä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 @hide Wi-Fi APIs zu ermöglichen. Das Folgende ist beispielsweise eine Build-Regel für eine java_library .

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

    Um den Bibliothekszugriff für foo-lib zu ermöglichen, ändern Sie die Build-Regel wie unten gezeigt.

    java_library {
        name: "foo-lib",
    
        sdk_version: "core_platform",
    
        libs: [
            "framework-wifi.impl",
            "framework",
            "dependency1",
            "dependency2",
        ],
    }
    
  3. Stellen Sie sicher, dass framework-wifi.impl vor framework in der Liste der libs erscheint. Die Reihenfolge der Abhängigkeiten im libs Attribut ist von Bedeutung.

Zugriff auf versteckte Framework-APIs

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

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

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

  3. Stellen Sie sicher, dass 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) überprüft die Funktionalität des Wi-Fi-Moduls, indem sie bei jeder Modulversion eine umfassende Reihe von CTS-Tests durchführt. Sie können auch die unter Testen, Debuggen und Optimieren von WLAN beschriebenen Tests ausführen.