Moving StrictMode configuration to activities is not an acceptable
solutions. As you generally don't know which activity might start first,
and adding same code (even only one function call) to each activity is not
always possible. Even more, you'd need to enable custom StrictMode
configuration in services, receivers and even content providers.
>From what I see this is a bug introduced in JB. According to documentation
this should work as you first described.
The bug itself is introduced in ActivityThread file, in
handleBindApplication() function. Basically here is what happens:
final StrictMode.ThreadPolicy savedPolicy =
StrictMode.allowThreadDiskWrites();
try {
// If the app is being launched for full backup or restore,
bring it up in
// a restricted environment with the base application class.
Application app =
data.info.makeApplication(data.restrictedBackupMode, null);
mInitialApplication = app;
//...lots of other code
} finally {
//restore StrictMode configuration that happened before
application's onCreate()
StrictMode.setThreadPolicy(savedPolicy);
}
Which effectively discards any changes made from Application's onCreate().
Here is the quick workaround for the issue and should be called from
Application's onCreate():
private static void enableStrictMode() {
doEnableStrictMode();
new android.os.Handler().post(new Runnable() {
@Override
public void run() {
try {
doEnableStrictMode();
} catch (Throwable ex) {
Log.d(TAG, "Failed to enable StrictMode.", ex);
}
}
});
}
This seems to fix issue by first enabling your StrictMode configuration by
the end of onCreate(), and then re-enabling it sometimes after onCreate()
returns. There is no guarantee when exactly StrictMode configuration is
restored. And theoretically this might happen after some activity or
service has already been started. This could probably be mitigated via
Handler's sendMessageAtFrontOfQueue().
On Sunday, July 15, 2012 7:41:04 PM UTC+3, b0b wrote:
>
> Ok found the cause of StrictMode.setThreadPolicy() not working.
>
> I was making this call in the onCreate() of a subclass of the Application
> class. This worked prior to Jelly Bean.
>
> Now in JB, it must be called after an Activity's onCreate() to take
> effect.
>
> Looks like the default StrictMode ThreadPolicy initialization done by the
> framework is not done the same way in JB than prior versions.
>
>
>
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
