Use ContentProvider instead of hashmap for numberMatch data, AB#3308440, Fixes AB#3308440

[siddhijain]

AB#3308440
In the current implementation for number matching feature, the data is stored in the hashmap. On testing, I found out that the data in the hashmap was not accessible since this is an interprocess communication. This PR uses ContentProvider to enable interprocess communication.

[github-actions]

❌ Work item link check failed. Description does not contain AB#{ID}.

Click here to Learn more.

[Copilot]

Pull Request Overview

This PR replaces in-memory storage of number match data with a ContentProvider for proper interprocess communication.

• Refactors NumberMatchHelper to use a ContentProvider for storing, retrieving, and clearing number match entries.
• Adds NumberMatchDbHelper and NumberMatchContentProvider to manage a SQLite-backed table.
• Updates tests and the JavaScript interface/WebView client to inject and use Context for ContentResolver operations.

Reviewed Changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
common/src/test/java/com/microsoft/identity/common/internal/numberMatch/NumberMatchHelperTest.kt	Tests updated to mock ContentResolver and drive new store/get methods with Context
common/src/test/java/com/microsoft/identity/common/internal/broker/AuthUxJavaScriptInterfaceTest.kt	Injects a mocked Context into the JS interface constructor
common/src/main/java/com/microsoft/identity/common/internal/ui/webview/AzureActiveDirectoryWebViewClient.java	Passes application context into the JS interface (incorrectly via getActivity())
common/src/main/java/com/microsoft/identity/common/internal/numberMatch/NumberMatchHelper.kt	Refactored helper methods to use ContentResolver and ContentProvider URIs
common/src/main/java/com/microsoft/identity/common/internal/numberMatch/NumberMatchDbHelper.kt	New SQLiteOpenHelper creating the number_match table
common/src/main/java/com/microsoft/identity/common/internal/numberMatch/NumberMatchContentProvider.kt	New ContentProvider implementation with query/insert/delete/update
common/src/main/java/com/microsoft/identity/common/internal/broker/AuthUxJavaScriptInterface.kt	JS interface now takes Context and calls NumberMatchHelper.storeNumberMatch(context,…)

Comments suppressed due to low confidence (1)

common/src/main/java/com/microsoft/identity/common/internal/numberMatch/NumberMatchHelper.kt:95

• There’s no unit test covering clearNumberMatchMap(context). Add a test to verify that calling it deletes all entries and subsequent getNumberMatch returns null.

        fun clearNumberMatchMap(context: Context) {

[github-actions]

✅ Work item link check complete. Description contains link AB#3308440 to an Azure Boards work item.

[mohitc1]

storeNumberMatch

This is called broker side right, so why the overhead of content resolver here insert here?

[siddhijain]

I did not understand. This is called as part of the javascript API call made by the AuthUx. Are you saying we should be calling ContentProvider directly?

[mohitc1]

NumberMatchDbHelper

Is persistent storage need?

Your content provider can you hashmap as its (in-memory) storage.. and no need of disk operations

[siddhijain]

HashMap will not work for IPC. That is the main reason of this PR and change. Let me know if I am missing something.

[mohitc1]

NumberMatchContentProvider

We have BrokerContentProvider.. any reason not to use it?

[mohitc1]

when

nit: you can use kotlin mockito and whenever