I've just created one:
http://code.google.com/p/android/issues/detail?id=35298
On Friday, July 20, 2012 4:12:26 PM UTC+3, BoD wrote:
:(
Did anybody open an issue?
--
BoD
On 07/20/2012 11:25 AM, b0b wrote:
Exactly. StrictMode thread policy (and it seems only thread policy) is
Wait, I'm not sure I understand.
Are you saying StrictMode configuration calls (setThreadPolicy,
setVmPolicy) no longer work if made in Application.onCreate? (We can
expect most apps make the calls there.)
--
BoD
On 07/16/2012 11:05 PM, Dianne Hackborn wrote:
The bug I think is that the
On Friday, 20 July 2012 10:33:46 UTC+2, BoD wrote:
Wait, I'm not sure I understand.
Are you saying StrictMode configuration calls (setThreadPolicy,
setVmPolicy) no longer work if made in Application.onCreate? (We can
expect most apps make the calls there.)
--
BoD
Exactly.
:(
Did anybody open an issue?
--
BoD
On 07/20/2012 11:25 AM, b0b wrote:
Exactly. StrictMode thread policy (and it seems only thread policy) is
restored to the default settings by the framewrok after onCreate() is
called.
--
You received this message because you are subscribed to the
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
Thank you for your in-depth analysis.
I've ended up with this, call in the Application derived class onCreate():
private void setLaxStrictMode() {
if(Build.VERSION.SDK_INT Build.VERSION_CODES.GINGERBREAD) return ;
if(Build.VERSION.SDK_INT Build.VERSION_CODES.JELLY_BEAN) {
Just curious, how did this influence your application? Do you access
network layer from UI thread?
Anyway, I think this is a bug, there is nothing changed in documentation.
And StrictMode example in documentation still uses App's onCreate(). So
there are no signs of this being an intentional
The bug I think is that the documentation should be updated. We definitely
want the new behavior -- when strict mode is enabled by default (on
non-user builds) we explicitly do not want the checks happening in
Application.onCreate() because it is okay to do disk access and such there
(the process
On Monday, 16 July 2012 22:25:49 UTC+2, Ievgenii Nazaruk wrote:
Just curious, how did this influence your application? Do you access
network layer from UI thread?
Yes.
I use a large external library that calls InetAddress.getHostName() as part
of its init, on LAN ip addresses only.
This
Dianne,
The problem with new behavior is not that it disables disk checks in
onCreate(), but that it completely discards all changes made to StrictMode
UI thread policy after onCreate() returns.
By the way, are there any other best-practices on where to initialize
StrictMode configurations
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
11 matches
Mail list logo
