Android 12 推出的 Wi-Fi/行動網路共存頻道迴避功能,可識別並避免使用不安全的 Wi-Fi 頻道,以免行動網路頻道受到干擾或干擾行動網路頻道。這包括 STA、SoftAp、Wi-Fi Direct (P2P)、Wi-Fi Aware (NAN) 等介面。
本頁面將說明下列事項:
- 行動數據機必須向 Android 架構回報的資訊
- Wi-Fi 架構用來計算要避開的 Wi-Fi 頻道之演算法
- 裝置製造商必須為 Wi-Fi 架構提供的設定表
- 與頻道迴避功能相關的系統 API、設定和 HAL API
- 架構行為:處理頻道迴避
- 晶片供應商處理頻道迴避行為的方式
- 避免顯示特定頻道的廣告的實作詳細資料
- 測試,用於驗證頻道迴避行為
背景
如果裝置使用 LTE、5G NR 和授權輔助存取 (LAA) 等行動網路技術,使用的行動網路頻道可能會干擾 Wi-Fi 頻道。如果行動網路和 Wi-Fi 頻道之間的頻率間隔很短 (相鄰頻道),或是發生諧波和互調干擾,就會出現這種情況。
如果一個天線正在傳輸,另一個天線同時接收,就會發生這類干擾問題。在此情況下,傳輸天線會淹沒接收天線,影響接收品質。
本文將干擾發射器稱為「侵擾者」,而受到干擾的接收器則稱為「受害者」。造成干擾或受到干擾的 Wi-Fi 頻道稱為「不安全」頻道。
Wi-Fi/行動網路共存頻道迴避功能提供一致的頻道迴避方法,減少與 Wi-Fi 架構不同的專屬程式碼需求。此外,裝置製造商還能透過這項功能設定、啟用、停用及覆寫這項功能。
這項功能會控制 Wi-Fi 頻道,以避開頻道。Wi-Fi 頻道迴避機制可分為四個抽象步驟:
- 數據機回報行動網路頻率變化
- 共存迴避演算法會計算不安全的 Wi-Fi 頻道
- 共存迴避演算法會通知 Wi-Fi 服務
- 架構或驅動程式執行適當的 Wi-Fi 動作
圖 1. 頻道迴避機制
回報手機頻率變更
電話服務會回報目前使用的行動網路通道。作業蜂巢式頻率變更時,數據機透過 IRadio::PhysicalChannelConfig
將這項資訊回報給電話服務。這項資訊包括授權輔助存取 (LAA) 和載波聚合 (CA) 的指標。
從 Android 12 開始,1.6 IRadio::PhysicalChannelConfig
中的下列欄位會提供數據機必須填入的共存公式必要資訊。
struct PhysicalChannelConfig {
/** Connection status for cell. Valid values are PRIMARY_SERVING and SECONDARY_SERVING */
CellConnectionStatus status;
/** The radio technology for this physical channel */
RadioTechnology rat;
/** Downlink Absolute Radio Frequency Channel Number */
int32_t channelNumberDownlink;
/** Uplink Absolute Radio Frequency Channel Number */
int32_t channelNumberUplink;
/** Downlink cell bandwidth, in kHz */
int32_t cellBandwidthDownlink;hte
/** Uplink cell bandwidth, in kHz */
int32_t cellBandwidthUplink;
}
計算不安全的 Wi-Fi 頻道
當數據機回報行動網路頻率有變更時,共存通道演算法會計算行動網路和 Wi-Fi 通道之間的干擾,並判斷哪些 Wi-Fi 通道不安全。
干擾類型有多種,需要使用不同公式:鄰近和諧波/互調。由於裝置的天線和配置在實體上有所差異,因此每個裝置的相鄰和諧波/互調干擾模式也不同。為此,裝置製造商必須提供查閱表,將參數插入兩種干擾的通用公式。這些參數是依據每個儲存格頻帶定義,並由有效儲存格通道的頻帶參照。
您可以在查閱表中定義最大功率上限。如果定義了最大功率上限,不安全的頻道會以提供的功率上限傳輸。如果沒有功率上限,頻道會以全功率傳輸。
一般來說,頻道迴避功能會盡量避免使用不安全的 Wi-Fi 頻道,以提升效能。但在某些情況下 (例如因應電信業者要求),某些介面必須避免特定蜂巢式頻段使用不安全的通道。在這種情況下,強制限制會以位元遮罩表示,其中包含是否禁止特定管道的值,例如 Wi-Fi Direct (P2P)、SoftAp 和 Wi-Fi Aware (NAN)。不安全管道會建議您不要將該管道用於所有用途,而強制限制則會標示出必須避免的特定用途。
如果 2.4 GHz 或 5 GHz 頻帶的每個通道都標示為不安全,查閱表可以根據干擾的蜂巢式頻帶,將預設 2.4 GHz 通道或預設 5 GHz 通道定義為最安全的選擇。如果樂團的其他頻道回報為不安全,這些預設頻道不會回報為不安全。
覆寫清單
如果干擾情況與頻寬高度相關 (因此頻寬較大的通道可能不安全,但頻寬較小的通道則不然),公式化方法就會受到限制。在某些情況下 (例如 LAA),略過計算並使用指定的不安全頻道清單會很有幫助。
如要這麼做,您可以在特定項目的查閱表中,指定不安全管道的覆寫清單。表格項目中的覆寫清單表示系統會略過該特定儲存格通道的計算,且相符儲存格通道的不安全 Wi-Fi 通道是由覆寫清單指定。
如果頻寬用量是重要考量,您可以在覆寫清單中指定特定頻寬的特定管道,有選擇性地避免使用特定頻寬。這是因為每個 Wi-Fi 頻道號碼都對應特定頻寬。
覆寫清單會以每個 Wi-Fi 頻段的頻道號碼或預先定義的類別關鍵字清單表示:
2g 類別:
all
(整個 2.4 GHz 頻帶)
5G 類別:
all
(整個 5 GHz 頻帶)20mhz
(5 GHz 20 MHz 頻道)40mhz
(5 GHz 40 MHz 頻道)80mhz
(5 GHz 80 MHz 頻道)160mhz
(5 GHz 160 MHz 頻道)
相鄰頻道干擾
為判斷相鄰頻道干擾,共存迴避演算法會確保攻擊者和受害者頻道之間的距離 ΔF 不會低於指定門檻。
圖 2. 加害者和受害者頻道之間的距離
門檻取決於裝置的實體設定,以及每個干擾頻帶的查閱表項目中提供的門檻值。如果頻帶被視為不會干擾,就不會有表格項目,且不需要計算不安全的通道 (這是大多數情況)。
相鄰干擾參數
wifiVictimMhz
:Wi-Fi 受害者 (行動網路上行) 的 MHz 距離門檻cellVictimMhz
:受害儲存格的 MHz 距離閾值 (儲存格下行)
演算法會針對每個有效的小區通道執行下列操作:
- 針對頻道的頻帶,嘗試尋找查閱表項目。如果找不到任何表格項目,則會傳回該儲存格管道沒有不安全管道。
- 根據行動網路頻帶,找出有風險的 Wi-Fi 頻帶,以及干擾來源的頻帶位置 (例如較低的 2.4 GHz 頻道、較高的 2.4 GHz 頻道、較低的 5 GHz 頻道)。
如果
wifiVictimMhz
存在,且蜂巢式通道有上行和如果 Wi-Fi 頻帶的下半部分有風險
- 將最高頻率加到細胞上行鏈路,找出不安全通道的上限。
wifiVictimMhz
- 找出下緣與限制重疊的前 20 MHz Wi-Fi 頻道。
- 標示 Wi-Fi 頻道、包含該頻道的所有較大頻寬頻道 (例如 40 MHz、80 MHz),以及與不安全頻道位於相同頻帶的所有較低頻道。
- 將最高頻率加到細胞上行鏈路,找出不安全通道的上限。
如果 Wi-Fi 頻段的上限部分有風險
- 從 Cell 上行鏈路最低頻率減去 wifiVictimMhz,即可找出不安全通道的下限。
- 找出上限重疊的第一個 Wi-Fi 頻道。
- 標示 Wi-Fi 頻道、包含該頻道的所有較大頻道 (例如 40 MHz、80 MHz),以及與不安全頻道位於相同頻帶的所有較高頻道。
如果
cellVictimMhz
存在,且手機頻道有下行鏈路。- 使用
cellVictimMhz
做為門檻執行步驟 3,並與 Cell 下行鏈路比較,而非 Cell 上行鏈路。
- 使用
將資料表項目的功率上限套用至計算出的不安全通道。
圖 3. 計算相鄰頻道干擾時,頻道不安全
諧波或互調失真
如果是諧波或互調失真,共存引擎會計算諧波或互調信號的範圍,並評估與潛在受害通道的重疊百分比。如果重疊超過重疊門檻,演算法會將此視為不安全的情況。諧波或互調失真在受害通道上的重疊百分比計算方式如下:
在諧波失真案例中,演算法會考量蜂巢式上行通道的諧波失真,而這會影響 Wi-Fi 通道。然後根據 cell 上行頻率和諧波度 $ N $,以諧波值取代高失真和低失真。
圖 4. 諧波失真不安全通道計算
在互調案例中,演算法會考量 Cell 上行鏈路的互調失真,以及 Wi-Fi 頻道對 Cell 下行鏈路頻道的影響。然後根據 Cell 上行頻率、Wi-Fi 頻率和兩個互調係數 $ M $、$ N $,將失真高和失真低替換為互調值。
圖 5. 互調失真導致通道計算不安全
您可以在查閱表中,為每個干擾儲存格頻帶指定 $ M $、$ N $ 和重疊值。如果頻段沒有干擾,該頻段項目的表格就會省略值。Wi-Fi 2.4 GHz 和 5 GHz 頻帶的這兩組值可以獨立定義。
與相鄰干擾演算法類似,此演算法會重複使用每個干擾訊號格頻帶定義的相同功率上限值。
演算法會針對每個有效的小區通道執行下列操作:
- 對於蜂巢式通道的頻帶,系統會嘗試尋找查閱表項目。 如果找不到資料表項目,則會傳回這個頻道沒有不安全的管道。
如果已定義參數,系統會從諧波中找出不安全的 2.4 GHz 頻道。
- 找出 2.4 GHz 的諧波次數 N。
- 根據 N 和 Cell Uplink 計算諧波高頻和諧波低頻。
- 找出低於下方諧波下限的第一個 20 MHz Wi-Fi 頻道。
- 計算諧波在 Wi-Fi 頻道上的重疊程度,如果重疊程度超過 2.4 GHz Wi-Fi 重疊門檻,就會將頻道標示為不安全。
- 找出位於上方諧波上限內的第一個 20 MHz Wi-Fi 頻道。
- 計算諧波在 Wi-Fi 頻道上的重疊程度,如果重疊程度超過 2.4 GHz Wi-Fi 重疊門檻,就會將頻道標示為不安全。
- 將中間每 20 MHz 的頻道標示為不安全。
如果定義了參數,則會從諧波中找出不安全的 5 GHz 頻道。
- 找出 5 GHz 的諧波度數 N。如果 N 為 0,則跳至步驟 5。
- 根據 N 和 Cell Uplink 計算諧波高頻和諧波低頻。
找出不安全的 20 MHz 頻道。
- 找出低於下方諧波下限的第一個 20 MHz Wi-Fi 頻道。
- 計算諧波在 Wi-Fi 頻道上的重疊程度,如果重疊程度超過 2.4 GHz Wi-Fi 重疊門檻,就會將頻道標示為不安全。
- 找出位於上方諧波上限內的第一個 20 MHz Wi-Fi 頻道。
- 計算諧波在 Wi-Fi 頻道上的重疊程度,如果重疊程度超過 2.4 GHz Wi-Fi 重疊門檻,就會將頻道標示為不安全。
- 將中間的每個 20 MHz 頻道標示為不安全,並設有指定的功率上限。
找出不安全的 40 MHz、80 MHz、160 MHz 頻道
- 重複步驟 3a,但使用 40 MHz、80 MHz 和 160 MHz。
- 系統會重複使用較小組成通道的重疊計算結果,而非計算諧波邊緣的通道重疊 (舉例來說,如果兩個 20 MHz 通道組成 40 MHz 通道,且重疊率分別為 30% 和 90%,則 40 MHz 通道的平均重疊率為 60%)。
如果定義了參數,則會從互調中找出不安全的 2.4 GHz 頻道。
- 找出 2.4 GHz 的互調係數 N 和 M。
針對每個 2.4 GHz Wi-Fi 頻道:
- 根據 N、M、行動網路上行和 Wi-Fi 頻道,計算互調低頻和互調高頻。
- 計算細胞下行鏈路上的互調重疊,如果重疊超過 2.4 GHz 細胞重疊門檻,就會將頻道標示為不安全。
如果定義了參數,則會從互調中找出不安全的 5 GHz 頻道。
- 使用 5 GHz Wi-Fi 頻道和 5 GHz 儲存格重複步驟 4。 重疊門檻。
將資料表項目的功率上限套用至計算出的不安全通道。
最終結果
計算出相鄰和諧波干擾的不安全頻道後,系統會合併兩組頻道 (如有衝突,則選取較低的功率上限),並從該組頻道中移除預設頻道 (如未套用強制限制),計算出最終的頻道組。
演算法的運作方式如下:
- 如果所有 2.4 GHz Wi-Fi 頻道都標示為不安全,請從設定中移除預設的 2.4 GHz Wi-Fi 頻道。
- 如果所有 5 GHz Wi-Fi 頻道都標示為不安全,請從設定中移除預設的 5 GHz Wi-Fi 頻道。
- 傳回最終的不安全頻道組合。
對照表格式
查閱表以 XML 檔案表示,位於可疊加的設定字串 config_wifiCoexTableFilepath
中,並由下列 XSD 定義。
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
version="1.0">
<xsd:element name="table">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="entry" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="entry">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="rat" type="ratType"/>
<xsd:element name="band" type="xsd:int"/>
<xsd:element name="powerCapDbm" type="xsd:int" minOccurs="0"/>
<xsd:choice>
<xsd:element ref="params"/>
<xsd:element ref="override"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:simpleType name="ratType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="LTE"/>
<xsd:enumeration value="NR"/>
</xsd:restriction>
</xsd:simpleType>
<!-- Define coex algorithm parameters -->
<xsd:element name="params">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="neighborThresholds" minOccurs="0"/>
<xsd:element name="harmonicParams2g" type="harmonicParams" minOccurs="0"/>
<xsd:element name="harmonicParams5g" type="harmonicParams" minOccurs="0"/>
<xsd:element name="intermodParams2g" type="intermodParams" minOccurs="0"/>
<xsd:element name="intermodParams5g" type="intermodParams" minOccurs="0"/>
<xsd:element ref="defaultChannels" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="neighborThresholds">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="wifiVictimMhz" type="xsd:int" minOccurs="0"/>
<xsd:element name="cellVictimMhz" type="xsd:int" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="harmonicParams">
<xsd:sequence>
<xsd:element name="N" type="xsd:int"/>
<xsd:element name="overlap" type="xsd:int"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="intermodParams">
<xsd:sequence>
<xsd:element name="N" type="xsd:int"/>
<xsd:element name="M" type="xsd:int"/>
<xsd:element name="overlap" type="xsd:int"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="defaultChannels">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="default2g" type="xsd:int" minOccurs="0"/>
<xsd:element name="default5g" type="xsd:int" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- Define algorithm override lists -->
<xsd:element name="override">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="override2g" minOccurs="0"/>
<xsd:element ref="override5g" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="override2g">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="category" type="overrideCategory2g" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="channel" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="override5g">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="category" type="overrideCategory5g" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="channel" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:simpleType name="overrideCategory2g">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="all"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="overrideCategory5g">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="all"/>
<xsd:enumeration value="20Mhz"/>
<xsd:enumeration value="40Mhz"/>
<xsd:enumeration value="80Mhz"/>
<xsd:enumeration value="160Mhz"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
XML 資料表範例
以下是 XML 查閱表範例:
<table>
<!-- Entry using algorithm parameters -->
<entry>
<rat>LTE</rat>
<band>40</band>
<powerCapDbm>50</powerCapDbm>
<params>
<neighborThresholds>
<wifiVictimMhz>25</wifiVictimMhz>
<cellVictimMhz>40</cellVictimMhz>
</neighborThresholds>
<harmonicParams2g>
<N>3</N>
<overlap>50</overlap>
</harmonicParams2g>
<harmonicParams5g>
<N>3</N>
<overlap>50</overlap>
</harmonicParams5g>
<intermodParams2g>
<N>-2</N>
<M>1</M>
<overlap>75</overlap>
</intermodParams2g>
<intermodParams5g>
<N>-2</N>
<M>1</M>
<overlap>75</overlap>
</intermodParams5g>
<defaultChannels>
<default2g>6</default2g>
<default5g>36</default5g>
</defaultChannels>
</params>
</entry>
<!-- Entry using the override list -->
<entry>
<rat>LTE</rat>
<band>41</band>
<powerCapDbm>50</powerCapDbm>
<override>
<override2g>
<channel>6</channel>
<channel>11</channel>
...
</override2g>
<override5g>
<category>40Mhz</category>
<channel>34</channel>
...
</override5g>
</override>
</entry>
</table>
載波聚合
對於載波聚合 (CA),每個上行或下行的諧波或互調範圍可能不會產生足夠的重疊,導致獨立干擾,但合併時可能會產生足夠的重疊。演算法會分別考量每個諧波或互調範圍,並取回傳不安全通道的聯集。就互調案例而言,這表示要評估每個 UL 對每個 DL 的互調範圍。
演算法不會區分 PCELL、PSCELL 或 SCELL,而是將其視為相等。
授權 Assisted Access
授權輔助存取 (LAA) 頻帶為 #46。演算法會將此樂團視為其他樂團。在這種情況下,完整的 5 GHz 頻道可以設為查閱表中的覆寫清單。
視電信業者需求而定,頻道迴避演算法會對整個 5 GHz Wi-Fi 頻帶的 SoftAP 和 Wi-Fi Direct (P2P) 設定強制限制。如要讓演算法處理這個用途,必須定義運算子設定值 restrict_5g_softap_wifi_direct_for_laa
。如果 Cell 頻道位於 LAA,且 restrict_5g_softap_wifi_direct_for_laa
為 true
,演算法會傳回不安全頻道組合,其中包含整個 5 GHz 頻段,並為 SoftAP 和 Wi-Fi Direct (P2P) 設定強制限制標記。
通知 Wi-Fi 服務
共存通道演算法計算出不安全通道後,請使用 Android 架構中定義的下列 @SystemApi 資料結構,為系統應用程式提供不安全通道及其限制。
public final class CoexUnsafeChannel {
public static final int POWER_CAP_NONE
public @WifiAnnotations.WifiBandBasic int getBand();
public int getChannel();
// Returns the specified power cap in dBm, or POWER_CAP_NONE if not specified.
public int getPowerCapDbm();
}
使用下列 WifiManager
@SystemApi 方法和回呼,讓應用程式在不安全管道變更時取得更新值。
public static final int COEX_RESTRICTION_WIFI_DIRECT;
public static final int COEX_RESTRICTION_SOFTAP;
public static final int COEX_RESTRICTION_WIFI_AWARE;
// Register a CoexCallback to listen on onCoexUnsafeChannelsChanged callbacks. The callback will be called whenever the unsafe channels change, as well as immediately after registering to get the current values.
public void registerCoexCallback(Executor executor, CoexCallback callback);
public void unregisterCoexCallback(CoexCallback callback);
public abstract static class CoexCallback {
//Gets called whenever getCoexUnsafeChannels()/getCoexRestrictions() have updated values
public void onCoexUnsafeChannelsChanged(List<CoexUnsafeChannels> unsafeChannels, int restrictions);
}
執行 Wi-Fi 動作
Wi-Fi 服務收到不安全頻道組的相關資訊後,會採取適當行動,確保避開這些頻道。本節說明 Wi-Fi 服務在不同情境下的行為。
通知駕駛
由於駕駛人在執行頻道迴避作業時扮演重要角色,因此務必將不安全的頻道傳達給駕駛人和韌體。如要執行這項操作,請使用下列 IWifiChip
HAL API。
AIDL:
void setCoexUnsafeChannels(in CoexUnsafeChannel[] unsafeChannels,
in int restrictions)
適用於 HIDL (1.5 以上版本):
setCoexUnsafeChannels(vec<CoexUnsafeChannel> unsafeChannels,
bitfield<IfaceType> restrictions);
SoftAP
SoftAP 是避免使用不安全通道的主要用途。以下章節將說明可透過 ACS 避免頻道干擾的主要 SoftAp 情境。這些情境說明通道迴避演算法和驅動程式/韌體的行為。
啟用 ACS 後啟動 SoftAP (目前尚未啟動 SoftAP)
如果頻道不安全,且有 SoftAP 限制
- 架構會從 ACS 清單中移除不安全的管道。
- 如果清單為空白,架構會停止 SoftAP。
如果頻道不安全且沒有限制
- 供應商驅動程式或韌體會優先處理安全通道,而非不安全通道。
SoftAP 已啟動,並啟用 ACS,且已更新不安全的頻道
如果 SoftAP 頻道不安全,且有 SoftAP 限制
- 架構會移除不安全的管道,更新 ACS 清單。
- 如果清單為空白,架構會關閉 SoftAP。
如果 SoftAP 頻道不安全且沒有任何限制
- 架構不會採取任何行動。如果無法避開不安全的通道,供應商驅動程式或韌體會負責避開這些通道,或套用功率上限。
Wi-Fi Direct (P2P)
如果 Wi-Fi Direct (P2P) 受到限制,且有不安全的頻道。
- 架構會要求
wpa_supplicant
,避免使用 HAL 方法ISupplicantP2pIface::setDisallowedFrequencies()
的不安全管道。
- 架構會要求
如果沒有限制不安全的頻道。
- 如果使用不安全的通道,且沒有 Wi-Fi Direct (P2P) 限制,供應商驅動程式或韌體就會套用電力上限。
Wi-Fi Aware (NAN)
架構不會參與 Wi-Fi Aware (NAN) 的管道選取程序,也不會採取任何架構動作。廠商驅動程式或韌體負責 Wi-Fi Aware (NAN) 頻道迴避。
停用演算法
如要停用預設演算法實作,並傳遞自己的不安全頻道清單以避免顯示,請設定疊加層 config_wifiDefaultCoexAlgorithmEnabled
。如果疊加設為 false,預設演算法會停用。然後,您可以使用自己的頻外專屬演算法,產生不安全管道的清單,並透過下列系統 API 傳送至架構。
public void setCoexUnsafeChannels(Set<CoexUnsafeChannel> coexUnsafeChannels,
int coexRestrictions);
驗證導入狀態
如要驗證 Wi-Fi/行動網路共存通道迴避功能導入作業,請使用下列測試。
CTS 測試
WifiManagerTest.java
testCoexMethodsShouldFailNoPermission()
testListenOnCoexUnsafeChannels()
ACTS 測試
WifiManagerTest.py
test_set_get_coex_unsafe_channels()
VTS 測試
如果實作 AIDL:
wifi_chip_aidl_test.cpp
TEST_P(WifiChipAidlTest, SetCoexUnsafeChannels)
如果實作 HIDL:
wifi_chip_hidl_test.cpp
TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)