Multi-Process Apps Result in TRANSACTION_URI Not Being Initialized

[commonsguy]

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!

[jgilfelt]

Thanks! I half anticipated this would come up, by which point my use of ChuckContentProvider was well intrenched.

I'm inclined to just add a note to the docs saying this project is not suitable for multi-process apps, until I can determine if there is enough demand to make this effort worthwhile.

[MrMannWood]

I am also running into this problem. I'm working on a simple SyncAdapter application, and was hoping to use Chuck for some network diagnostics. Looks like the issue is known, so I just wanted to add my name to the hat of affected users.

[su1216]

I am also running into this problem. I use another process to collect my app crash report and send it to server.

[TonyTangAndroid]

Just for feedback, I have also run into this problem.

[icespring]

I am running into this problem too. I start an webview in another process for memory leak from webview.

[mnchiu]

I, too, have run into this issue.

[lrampazzo]

Workaround: TRANSACTION_URI can be initialized through reflection when necessary

Class clazz = getClass().getClassLoader().loadClass(
    "com.readystatesoftware.chuck.internal.data.ChuckContentProvider");
Field field = clazz.getField("TRANSACTION_URI");
(field.get(null) == null) {
    field.set(null, Uri.parse("content://" + context.getPackageName() +
        ".chuck.provider/transaction"));
}

[erenbakac]

any solution on this?

[rehmanmuradali]

Any updates on this issue ? Also run into this problem while using SyncAdapter

[AlienAsRoger]

Hello! Any updates?

[cortinico]

Quick update: this project has been forked https://github.com/ChuckerTeam/chucker
Please note that we removed the ContentProvider in chucker as we haven't found a great use case for that. If you have one, please open an issue on the fork and we re-implement it 👍