1070231 - Disable disk read strict mode during BrowserApp#onCreate

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

[Richard Newman [:rnewman]]

We disable strict mode in release builds, but our developer and test machine logcat is still flooded by four routine warnings during startup.

I propose disabling these so we have an easier time reading logs.

Comment 1

[Richard Newman [:rnewman]]

Attachment: Disable disk read strict mode during BrowserApp#onCreate. v1

This was slightly less trivial than I'd hoped, simply because GeckoApp turned it back on as soon as I turned it off!

This patch moves the call to enableStrictMode in developer builds from GeckoApp into BrowserApp.

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Richard Newman [:rnewman] from comment #0)
> We disable strict mode in release builds, but our developer and test machine
> logcat is still flooded by four routine warnings during startup.
> 
> I propose disabling these so we have an easier time reading logs.

What are the four routine warnings? Are they routine because we have grown too lazy/ambivalent about them? Or can we (should we) do something about them?

Comment 3

[Richard Newman [:rnewman]]

These two, printed twice each:

09-19 21:31:59.536 D/StrictMode(14491): StrictMode policy violation; ~duration=329 ms: android.os.StrictMode$StrictModeDiskReadViolation: policy=31 violation=2
09-19 21:31:59.536 D/StrictMode(14491): 	at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1229)
09-19 21:31:59.536 D/StrictMode(14491): 	at libcore.io.BlockGuardOs.open(BlockGuardOs.java:106)
09-19 21:31:59.536 D/StrictMode(14491): 	at libcore.io.IoBridge.open(IoBridge.java:393)
09-19 21:31:59.536 D/StrictMode(14491): 	at java.io.FileInputStream.<init>(FileInputStream.java:78)
09-19 21:31:59.536 D/StrictMode(14491): 	at java.io.FileReader.<init>(FileReader.java:42)
09-19 21:31:59.536 D/StrictMode(14491): 	at org.mozilla.gecko.util.INIParser.parse(INIParser.java:99)
09-19 21:31:59.536 D/StrictMode(14491): 	at org.mozilla.gecko.util.INIParser.parse(INIParser.java:86)
09-19 21:31:59.536 D/StrictMode(14491): 	at org.mozilla.gecko.util.INIParser.getSections(INIParser.java:74)
09-19 21:31:59.536 D/StrictMode(14491): 	at org.mozilla.gecko.GeckoProfileDirectories.findDefaultProfileName(GeckoProfileDirectories.java:142)
09-19 21:31:59.536 D/StrictMode(14491): 	at org.mozilla.gecko.GeckoProfile.getDefaultProfileName(GeckoProfile.java:570)
09-19 21:31:59.536 D/StrictMode(14491): 	at org.mozilla.gecko.BrowserApp.getDefaultProfileName(BrowserApp.java:3069)
09-19 21:31:59.536 D/StrictMode(14491): 	at org.mozilla.gecko.GeckoProfile.get(GeckoProfile.java:103)
09-19 21:31:59.536 D/StrictMode(14491): 	at org.mozilla.gecko.GeckoApp.getProfile(GeckoApp.java:1666)
09-19 21:31:59.536 D/StrictMode(14491): 	at org.mozilla.gecko.GeckoApp.onCreate(GeckoApp.java:1171)

09-19 21:31:59.536 D/StrictMode(14491): StrictMode policy violation; ~duration=80 ms: android.os.StrictMode$StrictModeDiskReadViolation: policy=31 violation=2
09-19 21:31:59.536 D/StrictMode(14491): 	at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1229)
09-19 21:31:59.536 D/StrictMode(14491): 	at libcore.io.BlockGuardOs.open(BlockGuardOs.java:106)
09-19 21:31:59.536 D/StrictMode(14491): 	at libcore.io.IoBridge.open(IoBridge.java:393)
09-19 21:31:59.536 D/StrictMode(14491): 	at java.io.FileInputStream.<init>(FileInputStream.java:78)
09-19 21:31:59.536 D/StrictMode(14491): 	at java.io.FileInputStream.<init>(FileInputStream.java:105)
09-19 21:31:59.536 D/StrictMode(14491): 	at org.mozilla.gecko.util.HardwareUtils.getMemSize(HardwareUtils.java:168)
09-19 21:31:59.536 D/StrictMode(14491): 	at org.mozilla.gecko.GeckoAppShell.isHighMemoryDevice(GeckoAppShell.java:1407)
09-19 21:31:59.536 D/StrictMode(14491): 	at org.mozilla.gecko.GeckoAppShell.getScreenDepth(GeckoAppShell.java:1420)
09-19 21:31:59.536 D/StrictMode(14491): 	at org.mozilla.gecko.BrowserApp.onCreate(BrowserApp.java:666)


Arguably the profile read could be backgrounded, but maybe not: it's a core startup operation, and we can't display some UI without it.

Reading the mem size looks worse than it is: we're using a filesystem interface to interrogate the kernel, so it's not really a file read.

Comment 4

[(inactive) Jim Chen [:jchen] [:darchons]]

> Arguably the profile read could be backgrounded, but maybe not: it's a core
> startup operation, and we can't display some UI without it.

Bug 1062377 should move this to the background in most cases. I just have one more patch to fix test failures.

> Reading the mem size looks worse than it is: we're using a filesystem
> interface to interrogate the kernel, so it's not really a file read.

I agree.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

I'd rather not need this. We should try to remove it in the future.