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 頻道避免方案可以描述為一系列四個抽象步驟：
- 數據機報告蜂窩頻率變化
- Coex 迴避演算法計算不安全的 Wi-Fi 頻道
- Coex 避免演算法通知 Wi-Fi 服務
- 框架或驅動程式執行適當的 Wi-Fi 操作
圖 1.通道迴避方案
報告蜂窩頻率的變化
電話服務報告目前使用的蜂窩通道。當操作的蜂窩頻率發生變化時，數據機會透過IRadio::PhysicalChannelConfig將此資訊報告給電話服務。此資訊包括許可輔助存取 (LAA) 和載波聚合 (CA) 的指示。
從 Android 12 開始， 1.6 IRadio::PhysicalChannelConfig中的以下欄位提供調變解調器必須填入的 coex 公式所需的資訊。
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 頻道
當數據機報告蜂窩頻率變化時，coex 頻道演算法會計算蜂巢和 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（5GHz 40MHz 頻道） -
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 頻段的上部有風險
- 透過將 wifiVictimMhz 減去小區上行鏈路的最低頻率來找到不安全頻道的下限。
- 尋找上緣與限制重疊的第一個 Wi-Fi 頻道。
- 將 Wi-Fi 通道、包含該通道的每個較大通道（例如，40M hz、80 Mhz）以及同一頻段的每個較高通道標記為不安全通道。
如果存在
cellVictimMhz且小區頻道具有下行鏈路。- 使用
cellVictimMhz作為閾值執行步驟 3，並與小區下行鏈路而不是小區上行鏈路進行比較。
- 使用
將表格條目的功率上限應用於計算出的不安全通道。
圖3.相鄰頻道幹擾的不安全頻道計算
諧波/互調失真
對於諧波/互調失真，coex 引擎計算諧波/互調訊號的範圍，並評估其與潛在受害通道的重疊百分比。如果重疊超過重疊閾值，則演算法認為這是不安全的情況。使用以下公式計算受害通道上諧波/互調失真的重疊百分比：
在諧波失真情況下，演算法會考慮損害 Wi-Fi 通道的小區上行鏈路通道的諧波失真。然後，它用基於小區上行鏈路頻率和諧波度$N$的諧波值來取代高失真和低失真。
圖 4.諧波失真的不安全通道計算
在互調情況下，演算法考慮了小區上行鏈路和 Wi-Fi 通道的互調失真對小區下行鏈路通道的影響。然後，它用基於小區上行頻率、Wi-Fi頻率和兩個互調係數$M$、$N$的互調值來取代高失真和低失真。
圖 5.互調失真的不安全頻道計算
您可以在查找表中為每個幹擾細胞帶指定 $M$、$N$ 和重疊值。如果某個頻段沒有乾擾，則該頻段條目的值將從表中省略。可以獨立定義 Wi-Fi 2.4 GHz 和 5 GHz 頻段的兩組這些值。
與相鄰幹擾演算法類似，此演算法重複使用每個幹擾小區頻帶定義的相同功率上限值。
對於每個活動小區通道，演算法的行為如下：
- 對於小區頻道的頻帶，它嘗試尋找查找表條目。如果未找到表格條目，則傳回此頻道且不包含不安全頻道。
如果定義了參數，則從諧波中尋找不安全的 2.4 GHz 通道。
- 找出 2.4 GHz 的諧波次數 N。
- 根據N和小區上行鏈路計算諧波高頻和諧波低頻。
- 尋找位於下方諧波下限內的第一個 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和小區上行鏈路計算諧波高頻和諧波低頻。
尋找不安全的 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% 的重疊，則平均值為60 40 Mhz 通道的重疊百分比）。
如果定義了參數，則從互調中尋找不安全的 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 通道。
- 返回最後一組不安全通道。
尋找表格式
查找表以位於可覆蓋配置字串config_wifiCoexTableFilepath中的 XML 檔案表示，並由下列 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 並將它們視為平等。
許可輔助訪問
許可證輔助存取 (LAA) 被識別為頻段 #46。此演算法對此頻段的處理與其他頻段的處理類似。在這種情況下，可以將完整的 5 Ghz 通道設定為查找表中的覆蓋清單。
根據營運商的要求，頻道避免演算法對整個 5 GHz Wi-Fi 頻段的 SoftAP 和 Wi-Fi Direct (P2P) 設定強制限制。對於處理此用例的演算法，必須定義運營商配置值restrict_5g_softap_wifi_direct_for_laa 。如果小區頻道位於 LAA 上且restrict_5g_softap_wifi_direct_for_laa為true ，則演算法將傳回整個 5 Ghz 頻段的不安全頻道集，並設定 SoftAP 和 Wi-Fi Direct (P2P) 的強制限制標誌。
通知 Wi-Fi 服務
在 coex 通道演算法計算出不安全通道後，為了向您的系統應用程式提供不安全通道及其限制，請使用 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);
軟AP
SoftAP 是避免不安全頻道的主要用例。以下部分概述了可透過 ACS 應用頻道避免的關鍵 SoftAp 場景。這些場景描述了通道避免演算法和驅動程式或韌體的行為。
在啟用 ACS 的情況下啟動 SoftAP（尚未啟動 SoftAP）
如果聲道不安全且有 SoftAP 限制
- 該框架從 ACS 清單中刪除不安全的通道。
- 如果清單為空，框架將停止 SoftAP。
如果通路不安全且沒有限制
- 供應商驅動程式/韌體優先考慮安全通道而不是不安全通道。
SoftAP 已啟用並啟用 ACS，並且更新了不安全通道
如果 SoftAP 頻道不安全且有 SoftAP 限制
- 該框架透過刪除不安全通道來更新 ACS 清單。
- 如果清單為空，框架將關閉 SoftAP。
如果SoftAP頻道不安全且沒有限制
- 該框架不採取任何行動。供應商驅動程式/韌體會處理避免不安全的通道或在避免不可行的情況下應用功率上限。
Wi-Fi 直連 (P2P)
如果存在受 Wi-Fi Direct (P2P) 限制的不安全通道。
- 框架使用 HAL 方法
ISupplicantP2pIface::setDisallowedFrequencies()請求wpa_supplicant避免不安全通道。
- 框架使用 HAL 方法
如有不安全通路無限制。
- 如果使用沒有 Wi-Fi Direct (P2P) 限制的不安全通道，供應商驅動程式/韌體會套用功率上限。
Wi-Fi 感知 (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)
-