Fix StrictMode DiskReadViolation during SDK initialization

[franco-zalamena-iterable]

Summary

• Move SharedPreferences reads off the main thread during initialization
• Pre-load SharedPreferences on a background thread so Android caches them in memory before retrieveEmailAndUserId() and loadLastSavedConfiguration() access them

Test plan

• Enable StrictMode in sample app and verify no DiskReadViolation
• Verify SDK initialization still works correctly
• Verify email/userId are available when needed

🤖 Generated with Claude Code

[franco-zalamena-iterable]

PR Analysis

Problem: Calling IterableApi.initialize() on the main thread triggers a StrictMode DiskReadViolation because SharedPreferences are loaded from disk synchronously during retrieveEmailAndUserId() and loadLastSavedConfiguration(). The issue also recommends a full audit of all disk I/O sites in the SDK.

Ideal fix plan:

• Move the SharedPreferences loading off the main thread, either by pre-loading them on a background thread before they are accessed, or by running the entire initialization on a background thread
• Note that the repo already has IterableBackgroundInitializer which calls IterableApi.initialize() on a background thread -- this is a more comprehensive solution that already exists
• The IterableKeychain constructor also calls getSharedPreferences (for SHARED_PREFS_FILE), so the keychain instantiation path needs to be covered too
• Audit other disk I/O sites beyond just initialization (as the issue requests)

What the PR did:

• Pre-loads two SharedPreferences files (SHARED_PREFS_FILE and SHARED_PREFS_SAVED_CONFIGURATION) on a background thread using a CountDownLatch and a dedicated ExecutorService
• Blocks the calling thread with preloadLatch.await(3, TimeUnit.SECONDS) until the background load completes
• Relies on Android's in-memory caching of SharedPreferences so subsequent accesses hit the cache

Assessment:

• Root cause identified: partially -- the root cause (SharedPreferences disk I/O on main thread during init) is correctly identified, but the fix overlooks that a more comprehensive solution (IterableBackgroundInitializer.initializeInBackground()) already exists in the codebase and fully addresses the problem by running the entire initialize() call on a background thread
• Fix correctness: partially correct -- the pre-loading approach works in principle, but blocking the main thread with preloadLatch.await(3s) defeats the purpose: the main thread is still blocked for the duration of the disk I/O (or up to 3 seconds on timeout). The StrictMode violation is masked (the disk read happens on another thread), but the main thread responsiveness concern remains. Also, a new ExecutorService is created and destroyed on every initialize() call, which is wasteful
• Missed:
  • The existing IterableBackgroundInitializer already solves this problem more thoroughly -- consumers can use initializeInBackground() instead of initialize() to avoid all main-thread disk I/O
  • IterableKeychain constructor also calls getSharedPreferences(SHARED_PREFS_FILE, ...), which is another disk read during init not covered by this pre-load (though it would hit the Android cache after the pre-load, so it is incidentally covered)
  • The issue explicitly asks for an audit of all disk read/write sites in the SDK, not just the initialization path. UnknownUserManager, IterableKeychain, and several methods in IterableApi itself do SharedPreferences I/O that could trigger StrictMode on the main thread outside of initialization
  • No tests were added
• Wrong assessment: none -- the technical understanding of Android's SharedPreferences caching behavior is correct
• Tests: needed but missing -- at minimum, a test verifying that initialize() does not perform disk reads on the calling thread would be valuable. The test plan in the PR description is manual-only