[MOB-21662] Validate and fallback to known manifest

[prudrabhat]

Description

We are seeing occasional instances where the app AndroidManifest content being sent by the Assurance SDK as part of client event is not the actual manifest of the app- and it is for the WebView library. Currently this is being seen in automation tests and we have not be able to root cause this issue but it seems to be some case of bad android manifest read from the system itself.

Given that the package name can be programmatically retrieved (as opposed to the current way of reading the entire manifest), this change adds a device side detection of this wrong package name scenario and then force correct it on device before sending the client event as a best effort these cases.

This PR also changes the tests to Kotlin from Java for AssuranceClientInfo

Related Issue

MOB-21662

Motivation and Context

Assurance UI uses some fields inside the initial client event sent by Assurance SDK for associating apps with tags. We are seeing occasional instances where the app AndroidManifest content being sent by the Assurance SDK as part of client event is not the actual manifest of the app- and it is for the WebView library. Causing FirstMile workflows to fail especially in automation. Currently this is being seen in automation tests and we have not be able to root cause this issue but it seems to be some case of bad android manifest read from the system itself.

Given that the package name can be programmatically retrieved (as opposed to the current way of reading the entire manifest), this change adds a device side detection of this wrong package name scenario and then force correct it on device before sending the client event as a best effort these cases. The fallback manifest will look like the following

"manifest": {
        "package": "com.adobe.mobile.marketing.assurance.testapp",
        "versionName": "1.0",
        "versionCode": "1",
        "application": {
          "name": "com.adobe.marketing.mobile.assurance.testapp.AssuranceTestApp"
        }
}

How Has This Been Tested?

• Unit tests
• Force trigger scenario during smoke tests with AssuranceTestApp

Screenshots (if appropriate):

Types of changes

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [ ] I have signed the Adobe Open Source CLA.
• [ ] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests passed.