Status Update
No update yet.
Comments
ie...@gmail.com
Thank you for suggesting this enhancement. We value the feedback from our community and hope to review your suggestion in an upcoming sprint.
ie...@gmail.com
Good idea!
pu...@gmail.com
Fixed for an upcoming 3.2 canary by Change-Id: I93b86823b3311b2214da50fdcae7deb4fc095729 . Thanks for the suggestion!
en...@google.com
no...@gmail.com
Oh, this is why StrictMode never works on Galaxy S3 JellyBean.
na...@google.com
The breakage comes from ActivityThread.handleBindApplication :
// Allow disk access during application and provider setup. This could
// block processing ordered broadcasts, but later processing would
// probably end up doing the same disk access.
final StrictMode.ThreadPolicy savedPolicy = StrictMode.allowThreadDiskWrites();
try {
...
...
mInstrumentation.callApplicationOnCreate(app);
} finally {
StrictMode.setThreadPolicy(savedPolicy);
}
// Allow disk access during application and provider setup. This could
// block processing ordered broadcasts, but later processing would
// probably end up doing the same disk access.
final StrictMode.ThreadPolicy savedPolicy = StrictMode.allowThreadDiskWrites();
try {
...
...
mInstrumentation.callApplicationOnCreate(app);
} finally {
StrictMode.setThreadPolicy(savedPolicy);
}
ku...@google.com
This is still broken in the O Preview
bd...@google.com
Specifically from
commit 6bff62c2fd1733832a81f613495f4ead14045b81
Author: Jeff Sharkey <jsharkey@android.com>
Date: Wed Feb 29 12:26:36 2012 -0800
Wrap StrictMode changes in try/finally.
Bug: 6091030
Change-Id: I2614f8bb30203e00953b1978bbcaf24d84d0397b
note the change in the comment
// Allow disk access during application and provider setup. This could
// block processing ordered broadcasts, but later processing would
- // probably end up doing the same disk access. restore not guarded with
- // finally block, since exceptions here will take down the application.
+ // probably end up doing the same disk access.
commit 6bff62c2fd1733832a81f613495f4ead14045b81
Author: Jeff Sharkey <jsharkey@android.com>
Date: Wed Feb 29 12:26:36 2012 -0800
Wrap StrictMode changes in try/finally.
Bug: 6091030
Change-Id: I2614f8bb30203e00953b1978bbcaf24d84d0397b
note the change in the comment
// Allow disk access during application and provider setup. This could
// block processing ordered broadcasts, but later processing would
- // probably end up doing the same disk access. restore not guarded with
- // finally block, since exceptions here will take down the application.
+ // probably end up doing the same disk access.
ku...@google.com
ku...@google.com
This has been fixed and will be in a future release.
ku...@google.com
Commit
5e154365a4a0ef04ede668cbd646fb9de68a738d
Don't clobber application's strict mode
Applications often configure strict mode in Application.onCreate. A
regression was added in I2614f8bb30203e00953b1978bbcaf24d84d0397b that
applied a strict mode override for a longer period of time than needed.
Test: Launched a few applications
Bug: 36951662
Change-Id: I30b3eafa4a833fc42d0a938da9446007ade80480
5e154365a4a0ef04ede668cbd646fb9de68a738d
Don't clobber application's strict mode
Applications often configure strict mode in Application.onCreate. A
regression was added in I2614f8bb30203e00953b1978bbcaf24d84d0397b that
applied a strict mode override for a longer period of time than needed.
Test: Launched a few applications
Bug: 36951662
Change-Id: I30b3eafa4a833fc42d0a938da9446007ade80480
za...@google.com
Does this mean that when running on devices w/o the above fix custom thread policies may not be enforced during some portion of App#onCreate? Is there any workaround? Is posting to main thread from App#onCreate the best way to set a custom policy for an application running on such devices (even if it means it wont take effect until after App#onCreate completes)?
ku...@google.com
Until the fix is in a release, any changes to thread policy are overwritten by ActivityThread right after Application#onCreate returns. The only workaround on these devices is to post the policy change also to the main thread. Once this fix is in the next API level, when an app changes the thread policy in Application#onCreate that policy will stay in place as long as the app targets that API level.
If a developer does not update their target API, they will continue to see the broken behavior on purpose. This change will not make the O/26 release.
If a developer does not update their target API, they will continue to see the broken behavior on purpose. This change will not make the O/26 release.
a....@gmail.com
Has the fix been released for API 27 or will it be for the next version of Android (P)?
ku...@google.com
The fix is in O-MR1 and enables itself if 27 is targeted.
ra...@gmail.com
How can i fix this : StrictMode policy violation; ~duration=817 ms: android.os.StrictMode$StrictModeNetworkViolation: policy=65543 violation=4
bd...@google.com
#16 StrictModeNetworkViolation seems unrelated to original issue. please file new issues for different problems. Also #16 seems like a question more than a bug in Android.
ma...@gmail.com
StrictMode not logging when second activity launch. Only RED color blinking working.
Its logging when first activity get launch, and stop logging when second activity launched from first activity and first activity finish() called.
I setup strict mode in Application class.
if (BuildConfig.DEBUG) {
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectAll().penaltyDialog().penaltyFlashScreen()
.detectDiskReads()
.detectDiskWrites()
.detectNetwork() // or .detectAll() for all detectable problems
.penaltyLog()
.build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
// .detectAll()
.detectLeakedSqlLiteObjects()
.detectLeakedClosableObjects().detectActivityLeaks()
.penaltyLog()
// .penaltyDeath()
.build());
}
Its logging when first activity get launch, and stop logging when second activity launched from first activity and first activity finish() called.
I setup strict mode in Application class.
if (BuildConfig.DEBUG) {
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectAll().penaltyDialog().penaltyFlashScreen()
.detectDiskReads()
.detectDiskWrites()
.detectNetwork() // or .detectAll() for all detectable problems
.penaltyLog()
.build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
// .detectAll()
.detectLeakedSqlLiteObjects()
.detectLeakedClosableObjects().detectActivityLeaks()
.penaltyLog()
// .penaltyDeath()
.build());
}
Description
In Jelly Bean all changes made to ThreadPolicy that were set through StrictMode.setThreadPolicy() are discarded as soon as Application's onCreate() returns.
- Steps to reproduce the problem:
Assuming developer does this in her Application's object:
@Override
public void onCreate() {
if (BuildConfig.DEBUG) {
ThreadPolicy.Builder builder = new ThreadPolicy.Builder(StrictMode.getThreadPolicy());
builder.detectAll();
builder.penaltyDeath();
ThreadPolicy policy = builder.build();
StrictMode.setThreadPolicy(policy);
}
super.onCreate();
}
- What happened:
When any activity starts it does not crash on next violations: disk read, disk write, custom slow call. Which means StrictMode.ThreadPolicy was disacarded.
- What you think the correct behavior should be:
Custom StrictMode.ThreadPolicy that was set from Applications.onCreate() should not be discarded.