Multi-Process Apps Result in TRANSACTION_URI Not Being Initialized
See original GitHub issueI 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 ofBuildConfig.APPLICATION_ID
, and use a static initialization block for theUriMatcher
. You’d keep theattachInfo()
as is. So, in normal single-process cases, developers could rename theChuckContentProvider
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 requirestatic
values that might not exist in all processes.
Thoughts?
Thanks!
Issue Analytics
- State:
- Created 7 years ago
- Reactions:9
- Comments:11 (1 by maintainers)
Top GitHub Comments
I, too, have run into this issue.
any solution on this?