GitLab

The previous docs made it much too easy to miss the critical 'requirement'
that read(byte[],int,int) should be overridden.
http://code.google.com/p/android/issues/detail?id=7933#c36

Change-Id: I2c4e0e18026a93b8e994d4448be35114bd5f20bc

We recently had a bug in Apache HTTP client where catching a
specific exception subclass caused incorrect behavior. Apache HTTP
expects a ConnectException but we're throwing its superclass,
SocketException. Unfortunately I don't think fixing this to throw
ConnectException is any better; the best I can tell from the spec
this should be throwing a NoRouteToHostException which would still
fail on Apache HTTP client. I'm going to fix that code to catch the
appropriate type.

Bug: http://b/5293809
Bug: http://b/4411922
Change-Id: I189408f6e2355475510fb817c97017e7bae1739e

This regression was found by a harmony test:
org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest#testSocket_bind

Change-Id: Idb1089fb96b17673cf78903d935cb729722fda33

Change-Id: I8ff2c36e65624dfe65f570d4dd56f026ea05a499

cd libcore/luni/src/main/files
git rm cacerts/c0cafbd2.0
./certimport.sh

Bug: 5232736
Change-Id: I455a7c72a6d08cd0556fd4a64bb195e9e97dbfc0

cd libcore/luni/src/main/files
git rm cacerts/c0cafbd2.0
./certimport.sh

Bug: 5232736
Change-Id: I2c78d90fe513ec6f4a0a76a3b4095d9be9345292

* commit '308df1d9':
  Remove DigiNotar Root CA

* commit '26085321':
  Remove DigiNotar Root CA

cd libcore/luni/src/main/files
git rm cacerts/c0cafbd2.0
./certimport.sh

Bug: 5232736
Change-Id: I455a7c72a6d08cd0556fd4a64bb195e9e97dbfc0

Change-Id: Ide84f6fa454eafb843e48cd21312875f387c2c13

* commit '623ec56a':
  Remove DigiNotar Root CA

* commit '203990d7':
  Remove DigiNotar Root CA

cd libcore/luni/src/main/files
git rm cacerts/c0cafbd2.0
./certimport.sh

Bug: 5232736
Change-Id: I2c78d90fe513ec6f4a0a76a3b4095d9be9345292

* commit '75aea4d5':
  Remove DigiNotar Root CA

cd libcore/luni/src/main/files
git rm cacerts/c0cafbd2.0
./certimport.sh

Bug: 5232736
Change-Id: I455a7c72a6d08cd0556fd4a64bb195e9e97dbfc0

Bug: 5232736
Change-Id: Ifb4c31d5ba994bc694aeabc218d5a6397a686769

Bug: http://b/5179775
Change-Id: Ie4b220eb61eb479b3d0bb894a3824fcdbc1a70b1

I don't believe the functionality this test was testing ever
worked. The new test makes that clear; the old test masked the
real behavior in a bunch of unnecessary complexity.

These tests demonstrate that query timeouts are not working!

Bug: http://b/5213614
Change-Id: If09e5d6204e06df7df4649953b69ddba0537fbf9

In classes that wrap another Socket, return the real FileDescriptor
from the wrapped Socket.

Bug: 5189186
Change-Id: I157feb6991def9110eaf0ea82365b6f5b95b9372

Change-Id: I243519eff36e31298b433069bf1661c57f9ef46a

Bug: 5205819
Change-Id: I06af9d59485126579266af062c3a81a8ac36b1f5

Change-Id: I18c826f70a820bdcd6bcb46a8af9038ba685fc30

It's a lot of work to cache partial responses properly. We've
punted on this for the built-in HttpResponseCache.

This test passed once, but only because we were using a stub
response cache that didn't interpret 206s properly.

Change-Id: I2ee5ae2d5dc9a9d52d499411b281d647e658f21d

I recently broke JarInputStream by changing Streams.readFully()
to unconditionally close the input stream when it was exhausted.
Although most streams won't return data after read() returns -1,
both JAR and ZIP streams can return data after a call to get the
next entry.

Change-Id: I2fcef44aaeae0ac27c9fa5a7a4996c5b1b794964

Change-Id: Ib1d256a1aa6cb74e09f183263bb0f3e40b103e4f

Change-Id: I7d8d683bd81fd96e826584cf502e418b29acab61

This was causing tests to fail under CTS.

Change-Id: Iaefa292321c77ca1644fc04655d6c9aa1cac9b88

This was causing the test to fail on CTS.

Change-Id: I43a55620e702d4693eb4f8df2791ec7bba8d8390

Change-Id: I27d13fe10153bfbb124f6259cf0b98ba2c442060