Deflake and fix testIpClientClearingIpAddressState.
This test is flaky (at least when run on device) because often IpClient is started before it has heard about the IP address that the test adds to the interface. Then, when provisioning is started, it succeeds immediately because due to historical reasons the presence of an IPv4 address is sufficient to declare a network provisioned. Attempt to configure the address in a way that will avoid this sort of race. Because IpClient does not expose information about its inner state, or send any callbacks while it's stopped, do this by tapping in to the same observer registry that the test IpClient instance uses, and adding two addresses on the assumption that when the second one is observed, all observers, including IpClient, will have seen the first one be added. Also, the test was not very realistic. It configured an IPv4 address, and then ran DHCP, and expected that the IPv4 address would be cleared by ClearingIpAddressesState. But DHCP clears the address as well, because netd only supports configuring one IPv4 address per interface, so the test is not very useful. Use IPv6 instead. Bug: 139314310 Bug: 152723363 Test: atest NetworkStackIntegrationTests:IpClientIntegrationTest#testIpClientClearingIpAddressState --iterations 100 Change-Id: Ibf2fa0260df313c604ec0be3d04f49319f02d60e
Loading
Please register or sign in to comment