GitLab

Change-Id: I6ea268e469675ef890010282dbe35ed5838cca73
http://code.google.com/p/android/issues/detail?id=20442

We shouldn't throw NPE if you call isReachable on a deserialized InetAddress.
Fixed by removing the "globals", which also fixes the unreported bug that
calling isReachable on the same InetAddress was not thread-safe.

Bug: http://code.google.com/p/android/issues/detail?id=20203

Also, the arguments to isReachableByTCP in isReachable(NetworkInterface, int, int)
were the wrong way round, which meant we'd always return false (unless you were
asking if localhost was reachable).

Bug: http://code.google.com/p/android/issues/detail?id=20107

Bug: 2497441
Bug: 3213503

Change-Id: Ic808e774c28be6487e30e6acb8bc06f766f5c71d

I still don't see anything in the specification, but I can confirm
that real-world tools like unzip(1) don't like not having this bit
set. (Interestingly, "unzip -l" doesn't complain, but "unzip" does.
I usually test filename stuff with the former, so I never noticed
this gingerbread regression.)

Bug: http://code.google.com/p/android/issues/detail?id=20214
Bug: 4964868
Change-Id: I42d340d8b71a309285cf2bec3e938d07e05e9201

Change-Id: I59cacdbde1fe65b849d542f8faa8c0c2c0f5cddf

Also simplify a few of the implementations, and add a few tests.

Bug: http://code.google.com/p/android/issues/detail?id=19165
Change-Id: If33d5a830068114edf722711333bf0e00098d91a

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

Change-Id: Ie84c92e64a80acd336d44d8bb31bfe48c03a06e6

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