GitLab

No clue what's wrong here, but we're seeing some flakiness in the
"connect" tests. Hopefully there will be a clue in this extra
output next time we see a failure.

(cherry-pick of 73587588.)

Bug: 6971145
Change-Id: I8236b2fb368581e2b6965898f109370e7e0af2e5

(cherry-pick of 0f129636.)

Bug: 6972612
Change-Id: Ibc919c7023898f9e521f222d69c7efb50a170923

Depending on the timing of the two threads, SocketTimeoutException or SSLProtocolException can be thrown.

Bug: 6964910
Change-Id: Ia921f0dc61d1f2eb39a8d41c4ff6d551c924977e

It appears that OpenSSL has a bug where any DSA key verification
operation that fails will push an error on the OpenSSL error stack. This
change will clear the error state whenever a key verification is
performed.

(cherry picked from commit 912d5102)

Bug: 7302619
Change-Id: I16d1afad20f2d3934a01963ab62eea45b6caa6a1

Based on https://github.com/square/okhttp/pull/30
(git fetch git://github.com/square/okhttp.git && git cherry-pick -x b8c51dc5bdc89d5487cbc110d6fe40389de16480)

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

(cherry picked from commit 4bedacd5)

Change-Id: I68c55e9259db91dbccca30824c00726094570304

This isn't right for all locales, but it's right for "tl" in "tl" itself,
which is how we render language names in Settings.

(Yes, I know that "tl" is for "Tagalog" and "fil" is for "Filipino", but
Google policy is to use the latter name. If our resource system weren't
limited to two-letter language codes, we'd be using the modern three-letter
"fil" instead of the obsolete "tl", but we can't fix that right now. Bukas.)

Bug: 7291355
Change-Id: I7d9021dc55d9f1d3f8a75b10c890a2d5f91982d6

Our Pipe originally used socket(2) to create AF_INET/AF_INET6
sockets. This was clearly a bad idea.

I rewrote it to use socketpair(2) and AF_UNIX, but this was
before the big "expose POSIX" rewrite, so it required a bunch
of hacks in the native code, so I went with pipe(2) instead.

The trouble with pipe(2) is that we end up using FileChannel
to implement the Pipe.SinkChannel and Pipe.SourceChannel, but
the kernel won't wake a read(2) on a pipe if another thread
calls close(2) on it, so we started failing interrupt tests.

This (final?) rewrite is hopefully the best of all worlds:
we don't have any INTERNET permission needs, the code is as
simple as the pipe(2) code, and interruption works.

Bug: 7084342
Bug: 2735373
Bug: http://code.google.com/p/android/issues/detail?id=9431

(cherry picked from commit 32180823)

Change-Id: Ib92cdf8c818f6bba1f00e191f1b624ce9e693754

Merge "NativeCryptoTest#test_SSL_do_handshake_clientCertificateRequested_throws_after_renegotiate failure" into jb-mr1-dev

Fix similar issue in test_SSL_do_handshake_server_timeout

Bug: 6229479
Change-Id: If2cf7d7dfe468843285a531f4b8b42941996a3ed

Bug: 6964910
Change-Id: I13bed4e5ed104241025fbb1d5e28427ec16d7a80

We were running the risk that the server's end of a client socket would get
closed by the finalizer thread, resulting in read(2) returning 0 to the client,
and the test failing like this:

  junit.framework.AssertionFailedError: read returned -1
      at libcore.java.net.ConcurrentCloseTest.test_read(ConcurrentCloseTest.java:121)
      at java.lang.reflect.Method.invokeNative(Native Method)

(cherry-pick of 4bbcd7e5.)

Bug: 7206024
Change-Id: I0dae214a7ee609655f4f4781abf4457863bcfd5f

We need to strip both the Content-Length and the Content-Encoding
for such requests. In such requests, it will be the length of the
compressed response. We hide the fact that compression is taking place
from clients, so we shouldn't give them the content length either.

(cherry picked from commit f9d60aed)

Change-Id: Ic2776ecf020c34b1c55e2fb7e2f0728e553187a0

(cherry-pick of bb987854.)

Bug: 6973520
Change-Id: I372e451b5858e2f01a0aeeb7cb659f7df9f9348b

* commit '594aa21e':
  Fix umask.

* commit '35627363':
  Fix umask.

(cherry-pick of acba45cc.)

Bug: 7094213
Change-Id: I0c5cbfbfcd937e2393b30f3f50edea40586278cb

Bug: 7094213
Change-Id: I81979e6f050912cdc4cde8084765d09ec64c0689

Bug: 6693087
Change-Id: Ie18b227580682ff1d1cc8221de1b89677d446b66

Bug: 6693087
Change-Id: Ie6903168ca0ada4516c55dfab5f7194baf965b4c

Bug: 6964436
Change-Id: I9a6fd2ec589968743dc6727dad406057b328156d

* commit '722d0b9e':
  Add tests for underscores in URLs.

* commit '5ca6d99a':
  Add tests for underscores in URLs.

We're between a rock and a hard place on this. The RFCs say
that underscores aren't permitted in URLs. But browsers have
historically permitted them, and so there are websites that
depend upon them.

Attempting to support the de-facto standard rather than the
spec is difficult because support isn't universal. Mail servers
don't handle them. Internet Explorer loses cookies on them.

Further complicating things is that we can't easily support
underscores in hostnames in HttpURLConnection without also
adding support for that to java.net.URI. This would cause
awkward behavior in class that can be used for its strict
validation.

I'm recommending we stay spec-compliant. If its a major
problem for anyone, they can fix their servers.

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

* commit '2682316c':
  Add setsid.

* commit 'c87dc489':
  Add setsid.

See "Monkey not handling SIGHUP signal" (https://android-review.googlesource.com/43053).

Change-Id: Ib327702caefa8eb8d044723c270acfe4685c7551

* commit 'f0f825cb':
  Fix LocaleData.toString once and for all.

* commit '90bdb9da':
  Fix LocaleData.toString once and for all.

* commit '63529068':
  Fix a native memory leak in SimpleDateFormat cloning.

Change-Id: I207a3226470557ac26caba165ef35f5df6859273

* commit '82d74983':
  Fix a native memory leak in SimpleDateFormat cloning.

We didn't use the regular finalization idiom in NativeDecimalFormat because
Formatter used to create a lot of these objects, and we wanted to be able to
close them manually rather than clogging up the GC. We've since rewritten
the Formatter code so this is no longer relevant, but we left the finalization
in the wrong class.

Tested with a "while (true) sdf.clone();" loop and ps(1).

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