Background polling not working for large polling intervals?

[carloswabreu1]

Describe the bug
According to your documentation:

When the app is backgrounded, the stream connection terminates. The SDK polls for flag updates every hour (or another interval you configure) to stay in sync

I could confirm that the SDK works as expected in the foreground and that background polling is working as expected for both 15min and 1 hour intervals when the app is in the background. However, for large polling intervals (I've tried 12 and 24h), the flag is not being updated. I've included my testing implementation bellow. Can you please confirm this is an issue? Am I doing something wrong?

To reproduce

1. Setup LaunchDarkly client in the Application onCreate method with a large polling interval, e.g. 12h
2. Open the app, confirm that changing the flag remotely immediately reflects a flag change locally
3. Exit the app. Change the flag remotely one last time
4. Wait for 24h without opening the app. The flag is never updated locally. Usually the system kills the process during this period but the flag is not updated even when the process is brought to life in the background
5. Open the app, the flag is immediately updated

Expected behavior
The flag should be updated in the background for long polling periods on or around the background polling period defined

Logs
I have none but I'm happy to provide upon request

SDK version
implementation 'com.launchdarkly:launchdarkly-android-client-sdk:2.14.1'

OS/platform
Tested on a Pixel 3a, Android 11

Additional context
Bellow is the current implementation (Application class). You may notice that we have defined a secondary key as we wish to have flags synced from two different projects.

@Override
public void onCreate() {
        (...)
        Map<String, String> otherKeys = new HashMap<String, String>();
        otherKeys.put("secondaryIdentifier", "secondaryKey");

        LDConfig ldConfig = new LDConfig.Builder()
                .setMobileKey("mainKey")
                .setSecondaryMobileKeys(otherKeys)
                .setBackgroundPollingIntervalMillis(12 * 60 * 60 * 1000)
                .build();

        LDUser user = new LDUser.Builder("user")
                .build();

        LDClient appClient = LDClient.init(this, ldConfig, user, 0);
        appClient.registerAllFlagsListener(new LDAllFlagsListener() {
            @Override
            public void onChange(List<String> flagKey) {
                for (String flag : flagKey) {
                    //Persisting flag to disk
                }
            }
        });

        //Sdk-related setup
        try {

            LDClient ldSdkClient = LDClient.getForMobileKey("secondaryIdentifier");
            ldSdkClient.registerAllFlagsListener(new LDAllFlagsListener() {
                @Override
                public void onChange(List<String> flagKey) {
                    for (String flag : flagKey) {
                        //Persisting flag to disk
                    }
                }
            });
        } catch (LaunchDarklyException e) {
            e.printStackTrace();
        }
    }

[gwhelanLD]

Hi @carloswabreu1,

Thanks for the issue report. This does sound like unexpected behavior, from what you've provided the SDK setup seems appropriate. I believe logs may be helpful in determining why the background updating is not functioning in your application when using long intervals. You can send them to support@launchdarkly.com to avoid exposing any sensitive information if you'd like.

Thanks,
@gwhelanLD

[carloswabreu1]

Thanks for the reply, @gwhelanLD. What would be the best way to get those logs?

[gwhelanLD]

The SDK uses Timber for logging statements. If you register a Tree before initializing the client it will receive the log output from the SDK. DebugTree will send the output to logcat and is the simplest to setup:

Timber.plant(new Timber.DebugTree());

However I think that we really only care about the logs when the Application is started in the background, and given the long update interval we may prefer to avoid sifting the entire logcat output. It may be best to log to a file with something like the FileLoggingTree here. Additionally it would reduce the amount of logging done if the Tree is only registered when the Application is started in the background, something like:

ActivityManager.RunningAppProcessInfo appInfo = new ActivityManager.RunningAppProcessInfo();
ActivityManager.getMyMemoryState(appInfo);
if (appInfo.importance != IMPORTANCE_FOREGROUND && appInfo.importance != IMPORTANCE_VISIBLE) {
	Timber.plant(new Timber.FileLoggingTree());
}

Before initializing the SDK.

Also, to help narrow down the issue, I have a couple questions:

1. Have you observed this issue with both the primary and secondary environments?
2. I see you are using flag listeners and persisting the flag values to disk. Are you observing that the flag is not changed by viewing the persisted flag values?

Thanks,
@gwhelanLD

[carloswabreu1]

I'll add that FileLoggingTree. As for your questions:

Have you observed this issue with both the primary and secondary environments?

Yes, both environments are not being synced in the background.

I see you are using flag listeners and persisting the flag values to disk. Are you observing that the flag is not changed by viewing the persisted flag values?

That is correct.

[carloswabreu1]

@gwhelanLD, meanwhile, can you please elaborate on your background strategy? Are you using WorkManager?

[carloswabreu1]

@gwhelanLD, I've just emailed the logs to your support. This was the timeline of events:

• 28/04, around 2:20pm:
  • I opened the app, LD synced both main and secondary flags. Both were false
  • I closed the app. Changed both main and secondary flags to true remotely
• 29/04, 12:33pm, almost 24h later:
  • The app process was dead. Checked the flags in disk, both were still false
  • Brought the app process to life without opening the app. Checked the flags in disk, both were still false
  • Opened the app, flags were immediately synced to true