WifiChipAidlImpl: cache unsupported usable channel query

[CeRRiLLo89]

Summary

Cache an explicit ERROR_NOT_SUPPORTED response from the AIDL Wi-Fi HAL for
getUsableChannels().

After the HAL reports that the operation is unsupported, subsequent calls on
the same WifiChipAidlImpl instance return null without repeating the
unsupported Binder transaction.

Problem

The AIDL contract allows getUsableChannels() to return
WifiStatusCode.ERROR_NOT_SUPPORTED.

The current implementation handles that result as a generic
ServiceSpecificException, so later framework queries can repeatedly invoke
an operation which the HAL has already declared unsupported.

This affects compatibility with older vendor Wi-Fi implementations such as
the one used by Xiaomi Mi 9T Pro / Redmi K20 Pro (raphael).

Change

• Keep usable-channel queries enabled by default.
• Cache only an explicit ERROR_NOT_SUPPORTED response.
• Avoid later calls to the unsupported HAL operation for the lifetime of the
  WifiChipAidlImpl instance.
• Preserve the existing handling for remote, invalid-argument and other
  service-specific errors.
• Do not cache transient errors such as ERROR_BUSY.

This source change is intentionally narrower than the previous exact-build
binary workaround used on the affected device.

That workaround bypassed the usable-channel query more broadly, while this
pull request first calls the HAL and disables later calls only after receiving
an explicit ERROR_NOT_SUPPORTED result.

Tests

Added unit coverage verifying that:

• ERROR_NOT_SUPPORTED reaches the HAL once and is then cached.
• ERROR_BUSY is not cached and the HAL is queried again.

Local validation was completed with the lineage_raphael userdebug target and
a physical Xiaomi Mi 9T Pro / Redmi K20 Pro (raphael) running Android 16 /
crDroid 12.11.

Executed tests:

FrameworksWifiTests:com.android.server.wifi.hal.WifiChipAidlImplTest#testGetUsableChannelsNotSupportedIsCached

FrameworksWifiTests:com.android.server.wifi.hal.WifiChipAidlImplTest#testGetUsableChannelsTransientErrorIsNotCached

Result:

• FrameworksWifiTests compilation: passed.
• Instrumentation installation: passed.
• Tests selected: 2.
• Passed: 2.
• Failed: 0.
• ERROR_NOT_SUPPORTED caching: passed.
• Transient ERROR_BUSY retry: passed.

The tests use a mocked AIDL HAL. They validate the framework-side behavior but
do not replace runtime validation with the affected vendor HAL.

Pull request head

Current review head:

67dd45a81567d8cdcebcbfd721fb90fa08a9877c

This is the squashed review head.

Its source tree is identical to the previously validated head:

f157424b04f69f2e258a193dc458c5e20747b055

No functional or test changes were introduced by the squash, so the previous
source-build and targeted-test results remain applicable.

Device context

Device:

Xiaomi Mi 9T Pro / Redmi K20 Pro
Codename: raphael

Current official build used for reproduction:

crDroid Android 16
v12.11-20260831

The previous exact-build service-wifi.jar compatibility workaround from the
20260623 build is disabled and was not active during the current reproduction.

Runtime reproduction on current official build

The vendor/framework incompatibility was revalidated on the official crDroid
20260831 raphael build.

Starting SoftAP produced 13 consecutive getUsableChannels() failures with:

WifiChipAidlImpl: getUsableChannels failed with service-specific exception:
android.os.ServiceSpecificException: (code 4)

The 13 failures occurred in approximately 1.9 seconds.

code 4 corresponds to WifiStatusCode.ERROR_NOT_SUPPORTED, which is the
specific HAL result handled by this pull request.

SoftAP itself still started successfully:

frequency = 5180 MHz
wifiStandard = 5

Therefore, the reproduced issue is the repeated unsupported HAL query rather
than a SoftAP startup failure.

Validation status

• Controlled reproduction on official crDroid 20260623: completed.
• Reproduction on official crDroid 20260831 with the previous workaround
  disabled: completed.
• Source compilation: completed.
• Targeted unit tests: completed, 2 passed / 0 failed.
• Full lineage_raphael userdebug build containing this change: completed.
• Compilation, packaging, VINTF and ZIP integrity checks: passed.
• Runtime validation of this source change in an official crDroid build:
  pending.

The complete local ROM build containing this source change passed compilation,
packaging, VINTF and ZIP integrity checks.

The local ROM package was not installed because it is signed with the AOSP
test key, while the installed official crDroid ROM trusts the crDroid release
key.

The current official 20260831 build confirms that the original
vendor/framework incompatibility is still reproducible. It does not yet
contain this pull request, so runtime validation of the fix itself in an
official release remains pending.

This pull request is ready for maintainer review.

[CeRRiLLo89]

Ready for maintainer review.

The affected vendor/framework incompatibility was reproduced on the official
crDroid v12.11-20260623 installation.

Validation completed for the current pull request head:

targeted FrameworksWifiTests: 2 passed / 0 failed;
full lineage_raphael userdebug build: completed;
compilation, packaging, VINTF and ZIP integrity checks: passed;
ERROR_NOT_SUPPORTED is cached;
transient ERROR_BUSY remains retryable.

Runtime validation of a ROM containing the source change remains pending.

The locally built ROM cannot be installed as an update because it is signed
with the AOSP test key, while the installed official crDroid ROM trusts the
crDroid release key. I can validate the change on the affected device when it
is included in an official build.

[CeRRiLLo89]

Squashed the commit history into a single commit for review.

Current head: 67dd45a

The source tree is identical to the previously validated head f157424; no functional or test changes were made.

Previous validation therefore remains applicable.

[CeRRiLLo89]

Revalidated the issue on the official crDroid 20260831 raphael build with the previous exact-build workaround disabled.

Starting SoftAP produced 13 consecutive getUsableChannels() failures with ServiceSpecificException code 4 (ERROR_NOT_SUPPORTED) in approximately 1.9 seconds.

SoftAP itself still started successfully on 5 GHz (5180 MHz), confirming that the reproduced issue is the repeated unsupported HAL query rather than a SoftAP startup failure.

Updated the PR description with the current runtime evidence. No source changes were made.