We noticed with @FedericoCeratto, @aanorbel, @jbonisteel, and @agrabeli that ooni/probe-android 3.8.4 and 3.8.5 honour the maximum runtime both for foreground and background Web Connectivity runs. This change was introduced in https://github.com/ooni/probe-android/pull/572, where we were trying to unify the codepaths for calling the check-in API.
In retrospect, though, applying a timeout for background runs is not what we want. The rationale of the timeout for foreground runs is because the backend returns possibly thousands of URLs. Measuring all these URLs by default would be impractical for interactive runs. This is the reason why we introduced a timeout parameter for allowing users to control the overall duration.
On the contrary, when testing in the backtground, the backend returns between 20 and 100 URLs, depending on the current phone configuration (Wi-Fi/mobile and charging/not charging). In such a scenario, enforcing a timeout is not required and actually is not optimal because it reduces the total amount of data we're able to collect.
(See probe_services.py#L235 for more details about the backend algorithm implementation.
We noticed with @FedericoCeratto, @aanorbel, @jbonisteel, and @agrabeli that ooni/probe-android 3.8.4 and 3.8.5 honour the maximum runtime both for foreground and background Web Connectivity runs. This change was introduced in https://github.com/ooni/probe-android/pull/572, where we were trying to unify the codepaths for calling the check-in API.
In retrospect, though, applying a timeout for background runs is not what we want. The rationale of the timeout for foreground runs is because the backend returns possibly thousands of URLs. Measuring all these URLs by default would be impractical for interactive runs. This is the reason why we introduced a timeout parameter for allowing users to control the overall duration.
On the contrary, when testing in the backtground, the backend returns between 20 and 100 URLs, depending on the current phone configuration (Wi-Fi/mobile and charging/not charging). In such a scenario, enforcing a timeout is not required and actually is not optimal because it reduces the total amount of data we're able to collect.
(See probe_services.py#L235 for more details about the backend algorithm implementation.