commit | df6d61b1f9ba1626754d8e8af17ab68fcbe08386 | [log] [tgz] |
---|---|---|
author | Wade Guthrie <wdg@chromium.org> | Wed Jul 17 11:43:55 2013 -0700 |
committer | ChromeBot <chrome-bot@google.com> | Fri Jul 26 12:15:43 2013 -0700 |
tree | 6bc219b5cc8e4fb7f3b6cfb254fe60cfcdbfd938 | |
parent | 85d5b82605efd1e6c90cb0fcc48cbd3fa8513b66 [diff] |
shill: Cleans-up scan state machine to address field trial anomalies. The progressive scan field trial shows a few scan-to-connect times that extend much, much longer than expected (5% of one study group shows times that extend to multiple hours). I suspect that various timeouts in the scan/connect process (including the user being too frustrated to continue) would terminate this process long before we reached an hour and, therefore, that these anamolies are a function of measurement rather than operational problems. This would suggest that some operations that should terminate the scan state machine aren't being caught and, consequently, that occasionally some wifi connections are being linked to previous, unrelated, scans. This CL explores this possibility by rearranging the SetScanState calls to follow pending_service_ (an indicator of scan/connect state that has gotten a lot of testing and time in the field). This has the added benefit of insuring that different code that expresses the state of the scan/connect mechanism track each other more closely. One ramification of this CL is that scan-to-connect and scan-to-not-found state transitions occur earlier than before. The transition was moved to the actual cause of the transition (to the call to SetPendingService, for instance) rather than a convenient spot to view it (in ProgressiveScanTask). In certain cases (in PendingTimeoutHandler, for instance), SetScanState calls had to be moved relative to existing calls to SetPendingState (which now calls SetScanState) in order to reflect the actual scan state correctly. Similar reasoning instigated the creation kScanTransitionToConnecting to correctly document the scan state if, during the scan/connect process, we try to connect to a service that is not the pending_service_. Another change resets the WiFi connect timer (just as we reset the WiFi scan timer) when the scan state reaches 'kScanIdle'. BUG=chromium:260759 TEST=unittest Change-Id: Ib1c559b27d91df5b7408a42b187fb67cf03c8784 Reviewed-on: https://gerrit.chromium.org/gerrit/62131 Reviewed-by: mukesh agrawal <quiche@chromium.org> Commit-Queue: Wade Guthrie <wdg@chromium.org> Reviewed-by: Wade Guthrie <wdg@chromium.org> Tested-by: Wade Guthrie <wdg@chromium.org>