[Improvement] limit refresh User and GET IAMs to foreground

[jkasten2]

Description

One Line Summary

Limit refresh User and GET IAMs to foreground to save resources.

Details

Motivation

There are a number of background events that can start an app in the background (example push received), however were wasting resources (both on the device and OneSignal's backend) if the app is never foregrounded.

Scope

Only affect when we fetch IAMs and when refresh the User cache.

Testing

Manual testing

Tested on an Android 14 emulator, ensure we don't fetch IAMs and call GET User until the app is foregrounded.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

---

This change is 

[jinliu9508]

Tested with Android emulator Pixel 3a API 34 that when the app is swiped up (in background,) the app does not call to refresh user.

[nan-li]

I'm running into wonky behavior testing this PR when session time is sent after the app is swiped away. Haven't dug into why.

1. View IAMs during the session.
2. Swipe kill app away and it logs OSBackgroundSync scheduleSyncServiceAsJob:atTime: 30000.
3. About 50 seconds later, the SDK initializes (noticed it does not call fetch IAM or get user).
4. It calculates session time wrong as 0 which is the value sent to POST outcomes and PATCH user.

D  [Thread-15] SessionService.backgroundRun()
D  [Thread-15] SessionService: Session ended. activeDuration: 0
D  [Thread-15] OperationRepo.enqueue(operation: {"name":"track-session-end","appId":"<id>","onesignalId":"<id>","sessionTime":0}, flush: false)

D  [DefaultDispatcher-worker-7] HttpClient: POST outcomes/measure - {"app_id":"<id>","onesignal_id":"<id>","subscription":{"id":"<id>","type":"AndroidPush"},"id":"os__session_duration"}
D  [DefaultDispatcher-worker-7] HttpClient: POST outcomes/measure - FAILED STATUS: 400
W  [DefaultDispatcher-worker-7] HttpClient: POST RECEIVED JSON: {"errors":["There was a problem in the JSON you submitted","\"session_time\" must be positive when submitting os__session_duration"],"success":false}
W  [Thread-16] OutcomeEventsController.sendAndCreateOutcomeEvent: Sending outcome with name: os__session_duration failed with status code: 400 and response: {"errors":["There was a problem in the JSON you submitted","\"session_time\" must be positive when submitting os__session_duration"],"success":false}
Outcome event was cached and will be reattempted on app cold start


D  [OpRepo] UpdateUserOperationExecutor(operation: [{"name":"track-session-end","appId":"<id>","onesignalId":"<id>","sessionTime":0,"id":"<id>"}])
D  [DefaultDispatcher-worker-7] HttpClient: PATCH apps/<id>/users/by/onesignal_id/<id> - {"refresh_device_metadata":false,"deltas":{"session_time":0}}
D  [DefaultDispatcher-worker-7] HttpClient: PATCH apps/<id>users/by/onesignal_id/<id> - STATUS: 202 JSON: {"properties":{}}

If I test this same flow without the changes in this PR, the session time seems to be calculated correctly and sent.

D  [Thread-15] SessionService.backgroundRun()
D  [Thread-15] SessionService: Session ended. activeDuration: 96363
D  [DefaultDispatcher-worker-2] HttpClient: POST outcomes/measure - {"app_id":"<id>","onesignal_id":"<id>","subscription":{"id":"<id>","type":"AndroidPush"},"id":"os__session_duration","session_time":96}
D  [DefaultDispatcher-worker-3] HttpClient: PATCH apps/<id>-c72e141824ef/users/by/onesignal_id/<id> - {"refresh_device_metadata":false,"deltas":{"session_time":96}}

[jkasten2]

@nan-li Hmm, I am not able to reproduce this bug from some reason. I tried it a few times on an Android 14 emulator, both as a clean install and and existing install. It looks like you are using the default app_id we have in our example app for the 2nd test (ending in -c72e141824ef) did you use the same one in that first test? Can you also consistently reproduce the issue?

[nan-li]

I had tested two fresh installs on Android 13 emulator that reproduced the session time of 0 when I posted the comment above. Then another fresh install without the changes in this PR. All with same default app_id.

But now, trying it again, I am still running new installs and only reproduced it in 1 out of 5 new app installs. Might be random and not related to the changes in this PR.

[jkasten2]

From looking at the session code I don't see how this PR could be related to the issue, so going to merge this PR in.

Good find on this bug though, I think it might be related to the time not always getting written to disk before the app is killed.
SessionService.onUnfocused writes this time value, but that is buffered through PreferencesService so it may not be written to disk in time.
Another odd thing about this is we are sending outcomes for IAMs, but the backend doesn't support that.

I'll put these issues on our bug backlog.

• https://app.asana.com/0/1206295131710005/1206961842633136/f