GitLab

java.net.Socket creates the socket on connect(). But in case of failure
during the connect() it closes the socket.
During the create, BlockGuard's socket() is the one tagging the socket.
But in case of failure, nobody untags that socket.
So now we untag scokets on close() in BlockGuard

Bug: 5274621
Change-Id: I282665a05e2dc184df77c84ceab49fb55b7695af

Bug 5498103

Use a StreamHandler instead of a FileHandler, so that FileHandler
doesn't throw an exception if the log directory doesn't exist.

Change-Id: I7b7334ff8290a4b028712e89bb432fd78ef48346

Bug: 5466273

(cherry picked from commit d3433cea)

Change-Id: I8618be21a2227d66ea66352342b530906605160f

Bug: 5274621
Change-Id: Icc42a80c8cce6adb20d16ca2bb1fb51e2a8e8e1b

The kernel uses awkward device-specific units that make tests with timeouts
that aren't integer multiples of a second awkward.

There's no common superclass for the various sockets, so we can't factor
out the test even though -- apart from the creation of the specific socket --
it's textually identical in each case. Nice library design, boys!

I've also fixed a couple of CloseGuard warnings in passing.

Bug: 5159133
Change-Id: Iaf4c9891b3cf2f5b3ebcee5cb2ba862157ab034e

The kernel uses awkward device-specific units that make tests with timeouts
that aren't integer multiples of a second awkward.

There's no common superclass for the various sockets, so we can't factor
out the test even though -- apart from the creation of the specific socket --
it's textually identical in each case. Nice library design, boys!

I've also fixed a couple of CloseGuard warnings in passing.

Bug: 5159133
Change-Id: Iaf4c9891b3cf2f5b3ebcee5cb2ba862157ab034e

Whatever the root cause of the fstat(2) failure, we should still attempt the
requested close(2) --- even if it's just going to fail in the same way the
fstat(2) did.

Bug: 5407056
Change-Id: Ie988d1b1ebdb6b378fb537b2f56245fab568ee7c

* commit '64350311':
  Work around a dalvik weakness.

Our register maps aren't good enough, so when the collector looks at the
FinalizerReference for the RandomAccessFile, the referent has been marked
because the RandomAccessFile is still pointed to by a dex register, and
the register maps don't take into account that that register can never be
accessed again after the current dex PC, so it should in fact not be marked.

This is a long-standing weakness (I can cause similar failures in Gingerbread).

Bug: 5412580
Change-Id: I1de253a3686701ee724f8fefd5a6230d11179bad

* commit '9abfeaca':
  Fix backwards Engine cache test

Also fix SignatureTestMD2withRSA to clean up its test provider.
Add context information on failures to CertificateTest.

Bug: 5479141
Change-Id: I9a5ce60cfda63cfc418e72464eb1d3ef81dab0c0

am bea6b3d2: Merge "Don\'t require exception priority to match any particular implementation." into ics-mr0

* commit 'bea6b3d2':
  Don't require exception priority to match any particular implementation.

Bug: http://b/5478266
Change-Id: I15ad1f1eb67b307b61819c0c2031cc9a5f2e00fd

Change-Id: If10cf39515472969a2e57e9a1e00dead818fe771

* commit '0aaf7fc3':
  Set ANDROID_DATA for DalvikExecTest

* commit '5576e932':
  Fix Arrays Javadoc to be consistent with parameter names.

* commit '5de85581':
  DexClassLoaderTest.setUp should clean optimized directory

Also increase timeout to allow for dexopt of BOOTCLASSPATH

Bug: 5310023
git cherry-pick 513ac78c

Change-Id: Iab7ebc14fb0569d88c710f0e85344faad2d51228

Also increase timeout to allow for dexopt of BOOTCLASSPATH

Bug: 5310023
Change-Id: Icaa81a3bb3cea10c610e6ad671a001f6dbfeda17

Bug: 5410715
Change-Id: Ifde74c42105e8c408e0073953e5b0bf91ec86414

Bug: 5410715
Change-Id: Ifde74c42105e8c408e0073953e5b0bf91ec86414

Change-Id: I1b1d9013f99fe32b496696a4e1cbb5afcc73be6c

* commit 'c8ed4009':
  Clean up exception throwing in Arrays.

Change-Id: Ie002ba1cd1c681b83c7a8d4e8d4f96b7c0350eef

(I'd already fixed the bug, but hadn't explicitly tested the reported case.)

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

Bug: http://b/5410725
Change-Id: I116e5a846a528899608895163bb2a27573c5efae

In change:
    commit 2f9e468e
    Author: Elliott Hughes <enh@google.com>
    Date:   Fri Oct 9 17:21:46 2009 -0700

        Update libcore/security to Harmony r823222.

GeneralName.checkDNS was updated to support RFC 1123 (section 2.1)
which allows DNS names to start with a digit. This updates the test to
track that change by changing the negative test input for parsing DNS
names to not start with a '0'.

Bug: 5411722
Change-Id: Ie037e6d54e3e2c8b603af455ccde31c4558f070f

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