1004682 - Disable background data for mobile images/emulators

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Testing, defect, P3)

Description

[Ed Morley [:emorley]]

Broken out from bug 1004668 comment 3.

(In reply to Richard Newman [:rnewman] from comment #3)
> Well, if the machines don't have network access to the FHR upload endpoints,
> then the upload service will time out. That's expected. The uploader will
> run unless you've opted out of upload, but it shouldn't be running soon
> after an install…

We should be preffing off FHR rather than relying on network blocks.

Please could you make sure this is preffed off in automation, both for the Android client, and also desktop?

Comment 1

[Geoff Brown [:gbrown]]

Note that http://hg.mozilla.org/mozilla-central/annotate/35f9431188ca/testing/profiles/prefs_general.js#l124 has:

// Point Firefox Health Report at a local server. We don't care if it actually
// works. It just can't hit the default production endpoint.
user_pref("datareporting.healthreport.documentServerURI", "http://%(server)s/healthreport/");

Comment 2

[Richard Newman [:rnewman]]

Gecko prefs don't do anything for Java features. That pref turns off desktop's FHR.

We need a mechanism for setting SharedPreferences, or we need to figure out why FHR is deciding to upload. It shouldn't be. 

Do we have the former already?

Are we reinstalling packages (which preserves prefs from earlier installs), rather than uninstalling and installing?

Comment 3

[Geoff Brown [:gbrown]]

(In reply to Richard Newman [:rnewman] from comment #2)
> We need a mechanism for setting SharedPreferences, or we need to figure out
> why FHR is deciding to upload. It shouldn't be. 
> 
> Do we have the former already?

There is testSharedPreferences.js

I'd like to figure out why FHR is trying to upload. Is there a relationship between FHR upload and toolkit.telemetry.enabled, which is normally disabled, but enabled in this test (and never re-disabled)?

> Are we reinstalling packages (which preserves prefs from earlier installs),
> rather than uninstalling and installing?

We uninstall/install once per test job ("robocop-5"). Each robocop test ("testUITelemetry") runs in a new browser instance. The profile is deleted and re-created between each robocop test:

robocop-5 start
  uninstall org.mozilla.fennec
  install fennec.apk
  delete profile
  push new profile
  testJNI start
    start fennec via am instrument
    run test
    quit fennec
  testJNI end
  delete profile
  push new profile
  testOrderedBroadcast start
    start fennec via am instrument
    run test
    quit fennec
  testOrderedBroadcast end
  ...
robocop-5 end

Comment 4

[Richard Newman [:rnewman]]

(In reply to Geoff Brown [:gbrown] from comment #3)

> I'd like to figure out why FHR is trying to upload. Is there a relationship
> between FHR upload and toolkit.telemetry.enabled, which is normally
> disabled, but enabled in this test (and never re-disabled)?

No. FHR on Android has nothing to do with Gecko. The only things that control whether FHR uploads:

* Whether background data is enabled
* When the next scheduled upload is set for (not applicable in the case of the first attempt)
* Whether upload is enabled
* When Android decides to send us our first alarm-driven intent.

Disabling background data on the test machines seems like the best way to communicate with our background services that they shouldn't do any work.

Comment 5

[Ed Morley [:emorley]]

(In reply to Richard Newman [:rnewman] from comment #4)
> No. FHR on Android has nothing to do with Gecko. The only things that
> control whether FHR uploads:
> 
> * Whether background data is enabled
> * When the next scheduled upload is set for (not applicable in the case of
> the first attempt)
> * Whether upload is enabled
> * When Android decides to send us our first alarm-driven intent.
> 
> Disabling background data on the test machines seems like the best way to
> communicate with our background services that they shouldn't do any work.

What pref needs to be toggled to disabled background data? Or do you mean at the Android level?

Comment 6

[Ed Morley [:emorley]]

sigh, "disable"

Comment 7

[Richard Newman [:rnewman]]

I mean at the Android level: Settings > Data usage > Menu > Auto-sync data. Turning that off will stop all kinds of background things from trying to work -- not just FHR, but also the updater and various Googly services.

There's currently no way to configure Android services via Gecko prefs, so unless you can run additional Java code, or modify SharedPreferences XML in the app dir after install, this is the best way forward.

Comment 8

[Ed Morley [:emorley]]

Geoff, it sounds like we need to disable background data on our Android images - who's the best person to take a look at that? :-)

Comment 9

[Geoff Brown [:gbrown]]

This might be helpful:

http://stackoverflow.com/questions/8009273/general-sync-settings-auto-sync-checkbox-programtically

http://developer.android.com/reference/android/content/ContentResolver.html#setMasterSyncAutomatically%28boolean%29

Comment 10

[Geoff Brown [:gbrown]]

...or not! 

I tried calling setMasterSyncAutomatically(false) in sutagent and then checked BackgroundService.backgroundDataIsEnabled() -- it still reports True on both ICS and pre-ICS.

I also tried http://stackoverflow.com/questions/18683455/programatically-toggle-restrict-background-data: call ConnectivityManager.setMobileDataEnabled(). That does not work either.

Comment 11

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

A terrible idea: perhaps you can use reflection to start up the Android settings Activity in Robotium and click your way through to disabling it. Caveats:
  * I'm not sure if you can observe checked state from Robotium (to know you're not enabling the setting instead)
  * The UI path that you'd be taking is guaranteed to change across devices

Comment 12

[Geoff Brown [:gbrown]]

Another terrible idea:

Manually change the setting on a clean {Panda, Android 2.3 emulator image, and Android x86 emulator image}, then use those system images to update all the Pandas and the emulator images.

Comment 13

[Geoff Brown [:gbrown]]

I noted this as another thing to consider in bug 989343 -- improvements to the 2.3 emulator image. I feel like that's the next thing to try.

Comment 14

[Chris Cooper [:coop] (he/him)]

Geoff: should this be under Release Engineering or under Testing:General like bug 989343? Not sure who twiddles the image knobs these days.

Comment 15

[Geoff Brown [:gbrown]]

I'm not sure either. I think an argument could be made for either classification.

Comment 16

[Geoff Brown [:gbrown]]

(In reply to Richard Newman [:rnewman] from comment #7)
> I mean at the Android level: Settings > Data usage > Menu > Auto-sync data.
> Turning that off will stop all kinds of background things from trying to
> work -- not just FHR, but also the updater and various Googly services.

I see Settings > Data usage > Menu > Auto-sync data on all of my phones, but on the Android emulator (at least Android 4.1, 4.2, 4.3, 4.4), I see no Settings > Data usage and can find no Auto-sync option anywhere.

Comment 17

[Geoff Brown [:gbrown]]

I found the Auto-sync option in Settings on the Android 2.3 emulator, and, after looking more closely, on 4.4. Still no sign of it on 4.1, 4.2, or 4.3.

Comment 18

[Geoff Brown [:gbrown]]

http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android-apps/4.3_r1/com/android/settings/DataUsageSummary.java#461

Comment 19

[Geoff Brown [:gbrown]]

Background data is now turned off in the Android 2.3 emulator tests -- bug 989343.

Comment 20

[Chris Cooper [:coop] (he/him)]

Do we still want to investigate making this change to the Android 4.X devices/emulators?

Comment 21

[Richard Newman [:rnewman]]

If we can, it'll avoid spurious test failures.

Comment 22

[Justin Wood (:Callek)]

:gbrown, :rnewman.

Should we spin c#20 and c#21 out to a new bug, keep going here, or just resolve as "done" entirely?

Comment 23

[Geoff Brown [:gbrown]]

I would like to keep a bug open for this, even though I don't see a way forward for the 4.2 and 4.3 emulators: Either keep this one, or open a new one.

Comment 24

[Richard Newman [:rnewman]]

What Geoff said.

Comment 25

[Chris AtLee [:catlee]]

Is this still an issue?

Comment 26

[Geoff Brown [:gbrown]]

No change since comment 23. I don't have any plans to resolve this, but the bug is a nice reminder of the issue.

Comment 27

[Chris AtLee [:catlee]]

I'm not sure that this is the right component for this bug any more then. The emulator images are all defined in docker now, right?

Comment 28

[Geoff Brown [:gbrown]]

I'll look after it!

Comment 29

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.