1

I am running StrictMode.enableDefaults() to clean up my code and I have one line of code that sets the ZoneId that gives 10 StrictMode violations at about 195ms each for the single line of code. The Log.d statement just above the line only shows once in Logcat. I get the same errors if I use ZoneId.of(tz.getID()).

What's going on here? I checked the ZoneId source and the cause was not obvious to me. Is this from ZoneId parsing the input? Log times only go from 16:46:09.079 to 16:46:09.080, but otherwise the 10 stack traces look the same.

Am I truly loosing about 195ms x 10 or is this some sort of bug? Thanks

Routine that has the error:

if (lastUpdateZoneOffset.equals(utcOffset)) {
        // last update offset is zero, so add back time from observation station time zone
        Log.d(TAG, "tz.getID()");
        //ZoneId observationStationZoneId = ZoneId.of(tz.getID());
        ZoneId observationStationZoneId = ZoneId.of("America/Denver"); **<---Error Here**
        ZonedDateTime zdt = offsetDateTime.atZoneSameInstant(observationStationZoneId);
        // format to 14 Apr 4:16 PM Note: the "a" pattern only allows upper case for AM/PM
        lastUpdate = zdt.format(DateTimeFormatter.ofPattern("dd MMM h:mm a"));
        lastUpdate += " " + tz.getDisplayName(true, SHORT);
    } else {
        lastUpdate = offsetDateTime.format(DateTimeFormatter.ofPattern("dd MMM h:mm a"));
        lastUpdate += " " + tz.getDisplayName(true, SHORT);
    }

Typical stack trace:

01-01 16:46:09.079 24614-24614 D/StrictMode: StrictMode policy violation; ~duration=196 ms: android.os.StrictMode$StrictModeDiskReadViolation: policy=31 violation=2
    at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1137)
    at libcore.io.BlockGuardOs.open(BlockGuardOs.java:182)
    at libcore.io.IoBridge.open(IoBridge.java:442)
    at java.io.RandomAccessFile.<init>(RandomAccessFile.java:117)
    at java.io.RandomAccessFile.<init>(RandomAccessFile.java:149)
    at java.util.zip.ZipFile.<init>(ZipFile.java:158)
    at java.util.zip.ZipFile.<init>(ZipFile.java:119)
    at dalvik.system.DexPathList$Element.maybeInit(DexPathList.java:431)
    at dalvik.system.DexPathList$Element.findResource(DexPathList.java:445)
    at dalvik.system.DexPathList.findResources(DexPathList.java:361)
    at dalvik.system.BaseDexClassLoader.findResources(BaseDexClassLoader.java:72)
    at java.lang.ClassLoader.getResources(ClassLoader.java:425)
    at java.util.ServiceLoader.internalLoad(ServiceLoader.java:129)
    at java.util.ServiceLoader.reload(ServiceLoader.java:93)
    at java.util.ServiceLoader.<init>(ServiceLoader.java:86)
    at java.util.ServiceLoader.load(ServiceLoader.java:122)
    at org.threeten.bp.zone.ZoneRulesInitializer$ServiceLoaderZoneRulesInitializer.initializeProviders(ZoneRulesInitializer.java:122)
    at org.threeten.bp.zone.ZoneRulesInitializer.initialize(ZoneRulesInitializer.java:89)
    at org.threeten.bp.zone.ZoneRulesProvider.<clinit>(ZoneRulesProvider.java:82)
    at org.threeten.bp.zone.ZoneRulesProvider.getRules(ZoneRulesProvider.java:121)
    at org.threeten.bp.ZoneRegion.ofId(ZoneRegion.java:143)
    at org.threeten.bp.ZoneId.of(ZoneId.java:358)
    at com.drme.weatherNoaa.CurrentConditionsFragment.getDisplayLastUpdate(CurrentConditionsFragment.java:674)
    at com.drme.weatherNoaa.CurrentConditionsFragment.updateCurrentConditionsUi(CurrentConditionsFragment.java:543)
    at com.drme.weatherNoaa.DataManager$1.handleMessage(DataManager.java:201)
    at android.os.Handler.dispatchMessage(Handler.java:102)
    at android.os.Looper.loop(Looper.java:135)
    at android.app.ActivityThread.main(ActivityThread.java:5254)
    at java.lang.reflect.Method.invoke(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:372)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)
shizhen
  • 12,251
  • 9
  • 52
  • 88
mtdavem
  • 441
  • 1
  • 7
  • 17
  • 2
    [This post](https://developer.android.com/reference/android/os/StrictMode) describes strict mode in detail: *"StrictMode is most commonly used to catch accidental disk or network access on the application's main thread, where UI operations are received and animations take place. Keeping disk and network operations off the main thread makes for much smoother, more responsive applications. By keeping your application's main thread responsive, you also prevent ANR dialogs from being shown to users."* – Robert Harvey Jan 02 '19 at 00:40

0 Answers0