bug: clear MMKV on fresh install

[MarioAslau]

Description

When digging migration issue more. we've come to realise that MMKV causing the issue with the EXISTING_USER flag.

• Right now, when the app starts, in App.tsx, in the second useEffect the app checks for existing user: const existingUser = await StorageWrapper.getItem(EXISTING_USER);
• If existing user exists, it calls Authentication.appTriggeredAuth(), inside it, it tries to get credentials form the keychain. If there are none, it will thrown an error. Which will be our case, on a new device.
• Error is caught and lockApp is called. This method navigates to the login screen.
• The MMKV Storage gets restored -> app sees EXISTING_USER and tries to auth -> Auth fails due to lack of actual vault/credentials -> app shows login screen instead of onboarding.

Solution:

Leveraging react-native-device-info, which has the getFirstInstallTime method and lastUpdateTime to check if it is a fresh install in App, if so, reset the flag.

Related issues

Fixes:

Manual testing steps

1. Go to this page...

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I’ve followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[sethkfman]

@MarioAslau have you tested the upgrade path to make sure we are not flushing the store?

[Cal-L]

Let's verify that this clears all keys. Ex. default as well as the unique keys used to create MMKV instances

[MarioAslau]

@MarioAslau have you tested the upgrade path to make sure we are not flushing the store?

There are 3 conditions:

1. To determine if the app has been freshly installed, I use getFirstInstallTime() and getLastUpdateTime() to compare the install date with last update

• On Android, it uses PackageManager.getPackageInfo().firstInstallTime and lastUpdateTime
• On iOS, it uses NSFileManager.attributesOfItemAtPath to get the creation and modification dates of the app bundle

getFirstInstallTime -> will show the timestamp of when the app was first installed
getFirstInstallTime -> will show the timestamp of when the app was last updated. In the case of a fresh install it will coincide

For a fresh install, both timestamps will be identical since the app bundle is created and modified at the same time.

2. Checking for EXISTING_USER - this is the flag that can carry over migration due to it being stored in MMKV

To make sure that this condition is not true indefinitely until the user updates the app, we have the 3rd check.

3. If both of the conditions above are met + checking for the flag in Async Storage FRESH_INSTALL_CHECK_DONE. If this flag is not present, then it means that we have Fresh install with an app stored from a backup/migration.

[github-actions]

Bitrise

❌❌❌ pr_smoke_e2e_pipeline failed on Bitrise! ❌❌❌

Commit hash: 33f5380
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/1f5007c9-e5e4-4688-ab21-8828a8ac2b35

Note

• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

Tip

• Check the documentation if you have any doubts on how to understand the failure on bitrise

[sethkfman]

It would be good to see tests for this function.

[sonarqubecloud]

Quality Gate failed

Failed conditions
9.1% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud