tree 763bc9ea3b8a78c6eae8acaa1a1f528e0c1002f9
parent 006ac5d8d1a1603555a601861bceec63ade14dca
author Xiao Ma <xiaom@google.com> 1676001699 +0900
committer Xiao Ma <xiaom@google.com> 1680863023 +0900

Apply the IPC call from IpClientCallbacks to update maximum DTIM multiplier.

Move the DtimMultiplierController logic to IpClient which has natural
members to check the current network environment such as IPv4/IPv6 only
network or dual-stack, IpClient also has information from APF filter,
which allows us to adjust the DTIM multiplier dynamically to receive RAs
more reliable.

Generally It's hard to make DTIM multiplier work reliable without the
information such as the max beacon listening interval, upstream AP DTIM
config and beacon interval, we can calculate the expected multiplier
to use based on these information. For example, previously we select
9 as multiplier for IPv4-only networks, assuming the upstream AP config
is DTIM3 and beacon interval is 100ms, then total sleep interval
is 9 * 3 * 100ms = 2.7sec, although some chip vendors already do limit
the sleep interval less than 1s, we can still try to improve the proper
DTIM multiplier selection once we're able to get the necesssary
information. Alternative approach would be to deliver a maximum DTIM
multiplier to driver and allow OEMs to set their customized value as
long as the multiplier doesn't exceed the maximum one, otherwise, it
may cause high packet loss rate and break network connectivity.

This CL applies the new IpClientCallbacks method to pass the expected
maximum DTIM multiplier to driver via HAL API instead of depending on
the DtimMultiplierController implementation.

Bug: 266256943
Test: atest com.android.server.wifi.ClientModeImplTest
Test: manually connect to IPv4/v6-only or dual-stack network or hold the
      multicast lock to check the DTIM multiplier value to be set
Change-Id: I6c54fbce793a9217abe5af09ef77fa41676c5a41