Reputation: 12989
I am using good old-fashioned HttpURLConnection
to fetch a bitmap (this is handled asynchronously) along the following lines:
Bitmap bmp;
boolean fetchOk = false;
try {
URL url = new URL(strURL);
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setConnectTimeout(timeoutConnectMs);
connection.setReadTimeout(timeoutReadMs);
int responseCode = connection.getResponseCode();
if (responseCode == 200) {
inputStream = connection.getInputStream();
BitmapFactory.Options options = new BitmapFactory.Options();
options.inScaled = false;
bmp = BitmapFactory.decodeStream(inputStream, null, options);
fetchOk = true;
}
} catch (Exception e) {
// I also catch and handle specific Exceptions differently but there is also a catch-all here
e.printStackTrace();
} finally {
try {
inputStream.close();
} catch (IOException e) {
e.printStackTrace();
}
}
if (!fetchOk) {
// handle retry
return;
}
// do stuff with fetched bmp
Just occasionally, the fetched bitmap isn't complete... it stops part-way down and is blank for the lower part. Or sometimes it is blank completely. This bitmap ends up in a widget, which is where I sometimes see these incomplete / blank bitmaps.
I think it when the phone wakes up after a sleep, and I've had users reporting similar. When it has happened to me, the following was in the log:
D/My_Stuff(11449): isBitmapInCache: true
D/My_Stuff(11449): getViewId for widget_port
D/My_Stuff(11449): nothingToDo: false
W/System.err(11449): javax.net.ssl.SSLException: Read error: ssl=0x73401b5d88: I/O error during system call, Software caused connection abort
W/System.err(11449): at com.android.org.conscrypt.NativeCrypto.SSL_read(Native Method)
W/System.err(11449): at com.android.org.conscrypt.NativeSsl.read(NativeSsl.java:411)
W/System.err(11449): at com.android.org.conscrypt.ConscryptFileDescriptorSocket$SSLInputStream.read(ConscryptFileDescriptorSocket.java:583)
W/System.err(11449): at com.android.okhttp.okio.Okio$2.read(Okio.java:145)
W/System.err(11449): at com.android.okhttp.okio.AsyncTimeout$2.read(AsyncTimeout.java:213)
W/System.err(11449): at com.android.okhttp.okio.RealBufferedSource.read(RealBufferedSource.java:61)
W/System.err(11449): at com.android.okhttp.internal.http.Http1xStream$FixedLengthSource.read(Http1xStream.java:602)
W/System.err(11449): at com.android.okhttp.okio.RealBufferedSource.read(RealBufferedSource.java:61)
W/System.err(11449): at com.android.okhttp.internal.http.HttpEngine$2.read(HttpEngine.java:1007)
W/System.err(11449): at com.android.okhttp.okio.RealBufferedSource$1.read(RealBufferedSource.java:397)
W/System.err(11449): at android.graphics.BitmapFactory.nativeDecodeStream(Native Method)
W/System.err(11449): at android.graphics.BitmapFactory.decodeStreamInternal(BitmapFactory.java:875)
W/System.err(11449): at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:850)
W/System.err(11449): at com.myapp.thisis.MyGetStuffTask.call(MyGetStuffTask.java:277)
W/System.err(11449): at com.myapp.thisis.MyGetStuffTask.call(MyGetStuffTask.java:31)
W/System.err(11449): at com.myapp.thisis.TaskRunner.lambda$executeAsync$1$TaskRunner(TaskRunner.java:61)
W/System.err(11449): at com.myapp.thisis.-$$Lambda$TaskRunner$-iWF_J4qwWx8b2L_xWSWxOSc0Nk.run(Unknown Source:6)
W/System.err(11449): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
W/System.err(11449): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
W/System.err(11449): at java.lang.Thread.run(Thread.java:919)
D/skia (11449): ---- read threw an exception
D/My_Stuff(11449): showMessageInWidget (Finishing up…)
D/My_Stuff(11449): getTextViewId for message_port
There is normal logging before and after the SSLException
, and the process completes normally after the exception, just with an incomplete bitmap being the result. In other words, the SSLException
doesn't seem to be caught by the catch
block, so there doesn't appear to be any way to catch this and deal with it.
I think it may be related to this issue (I understand that HttpURLConnection
uses okhttp
under the hood for Android 4.4+ and hence why okhttp
appears in my log despite not using the okhttp
library directly). There, they also associate the problem with doze mode. But there is no resolution of this problem over there either.
Upvotes: 1
Views: 1103