Multi-Process Apps Result in TRANSACTION_URI Not Being Initialized

I tried integrating Chuck into my playground app for CWAC-NetSecurity. Using Chuck either as a regular or network interceptor resulted in:

java.lang.NullPointerException: url
   at com.android.internal.util.Preconditions.checkNotNull(Preconditions.java:60)
   at android.content.ContentResolver.insert(ContentResolver.java:1224)
   at com.readystatesoftware.chuck.ChuckInterceptor.create(ChuckInterceptor.java:172)
   at com.readystatesoftware.chuck.ChuckInterceptor.intercept(ChuckInterceptor.java:114)

This would result from TRANSACTION_URI being null, either because attachInfo() is not being called at all or Uri.parse() returning null.

My playground app uses two processes. My launcher activity brings up a set of preferences to configure the scenario to try. It then starts another activity, running in a separate process, to actually test the scenario.

By default, your ChuckContentProvider goes into the default process. When I try applying Chuck in the other process, ChuckContentProvider.TRANSACTION_URI will be null, because the provider is a natural system-wide singleton, and that singleton is in the other process. Hence, attachInfo() is never called in this process to initialize TRANSACTION_URI.

(this is one of the reasons why I don’t recommend multiple processes for most apps…)

I could use manifest merger to shove ChuckContentProvider into the other process, which in theory should get past this crash. However, then I suspect that your activities will fail, as the default process will not have TRANSACTION_URI. I could further shove all of those into the other process using the same manifest merger approach, and perhaps get all this working. I’m not sure if that’s what you want us to do.

Some possible alternatives:

• Use a static initializer for TRANSACTION_URI based off of BuildConfig.APPLICATION_ID, and use a static initialization block for the UriMatcher. You’d keep the attachInfo() as is. So, in normal single-process cases, developers could rename the ChuckContentProvider authority and you’re covered. The limitation then is that multi-process apps would be required to leave the default authority alone, so the statically-initialized values are valid.

• Dump ChuckContentProvider entirely and do something else that does not require static values that might not exist in all processes.

Thoughts?

Thanks!

[mnchiu]

I, too, have run into this issue.

[erenbakac]

any solution on this?