Troubleshooting Issue with commonDBHelper and onUpgrade Function after SDK Upgrade from CA Mobile-OTP-LIB-Android-2.2.5 to ca-mobile-authenticator-android-sdk-2.0.1

Products

• CA Strong Authentication
• CA Advanced Authentication

Issue/Introduction

Customers have reported an issue related to the behavior of the commonDBHelper and the onUpgrade function. The issue arises when the commonDBHelper is recalled, and the DB version is directly set to a higher number, bypassing the expected behavior of setting it to a lower version. Consequently, the onUpgrade function is not triggered, leading to data not being moved to the desired database and certain tables not being dropped.

Environment

Release : CA Strong Authentication 9.1

Cause

The root cause of this issue is a coding error within the commonDBHelper, where the version number is being set incorrectly during the recall process. Instead of setting the DB version to a lower number or the next appropriate version, it is directly set to a higher number.

Resolution

Impact:

The impact of this issue is twofold:

1. Data Migration Failure: Due to the incorrect versioning, the onUpgrade function is not invoked as expected, resulting in the failure to move data to the desired database (e.g., AccountsV2) during the upgrade process.
2. Retained Tables: Additionally, the tables ArcotOTP and Accounts, which are intended to be dropped during the upgrade, are not being removed, potentially leading to data inconsistencies or conflicts.

Resolution:

To ensure that the onUpgrade function is triggered appropriately and to allow fetching accounts from both the old and new databases (encrypted and non-encrypted), we have modified the version number. Previously, the first execution of the commonDBHelper triggered an update to the latest version, even if the database was not yet updated to the last schema generated by the SDK.

Upon investigating the reported issue, we have identified that when the commonDBHelper is recalled, the DB version is being directly set to 7 instead of the expected behavior of setting it to 6 or a lower version. As a result, the onUpgrade function is not being triggered as intended.

Consequently, the data is not being moved to the real DB AccountsV2, and the tables ArcotOTP and Accounts are not being dropped, which is causing the observed issue.

With the recent modifications, the version number has been adjusted to trigger the onUpgrade function correctly. This enables the retrieval of accounts from both the old and new databases, accommodating encrypted and non encrypted data.

Additional Information

Conclusion:

To prevent similar issues in the future, it is recommended to follow these best practices:

• Conduct comprehensive testing to ensure the correct behavior of database-related functions, including the onUpgrade function, before deploying any updates or releases.
• Implement a robust version control system to accurately track and manage database schema changes. Ensure that the versioning is aligned with the actual database schema to prevent inconsistencies.
• Conduct thorough code reviews to identify and rectify any potential coding errors or inconsistencies in database-related code.