GitLab

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

Bug: http://b/5171136
Change-Id: I58259863157df1301183d851d43bcfc6fcdb72c9

Our testing tools cannot normally test package-private APIs
because the tests are loaded in a different class loader than
the production classes. This is an unfortunate workaround.

Change-Id: Ic8d9d3088887bccceaf166959468cd52bfef9aae

Tests were failing in CTS because they were relying on the static
'st' member to be side effected by other tests.

This also makes some quick cleanups to style and names.

Change-Id: I93b9ce370c247c07f3521a8db3904ede86394ffe

The CTS test harness doesn't sanitize the preferences between tests
so we need to make sure it's clean in the test.

Change-Id: Idc80ac23f97431d31c902ad6a985ee8010a008f8

This weird, surprising behavior used the entire call stack as
context to lookup resources. This is the wrong solution to the
problem; context class loader is the right solution. And the
code is already using context class loader.

This change prevents some tests from failing with an NPE when
iterating the null class context.

Change-Id: Ic2419dc22f66a4fa8cceaee4746ef1a6d7d4680c

This test invisibly uses two threads - the test thread and the
preference API's preference change thread. This test was relying
on flush() taking long enough that the other thread would have
posted its event before it returned.

The new test just waits up to 100ms. This is still racy but it
eliminated the false failures in my runs.

Change-Id: I87799b36cb4e5e26d8ca04e4529d1db0b936acb3

Change-Id: I24d60b6db32409ed84a81f4a067e3c60e2817493

Change-Id: Ie0b62f598bb97cec76394e99654eaeaf7956ae6a

I've raised a bug to enhance CheckJNI. For now, this was caught by a
setSoTimeout test.

Bug: 5159133
Change-Id: If28e81b97c2fdd870ebbcd36d9d0bc01be9d8cf1

We had a test URLStreamHandlerFactoryTest.testInstallCustomProtocolHandler
that was failing when run in an APK without this fix. The new behavior
is definitely what Android applications will want!

Change-Id: I2266a8aea6da833022b538c1f424a3099684d992

Change-Id: Icc35a44bac6481b549a96d0533770d11aff507da

This was breaking several CTS tests.

Change-Id: I76a87deeb9a1f7b056adb72447001cf5e23ec0b3

am a3038e56: (-s ours) am 8f591ff0: Merge "Support wrapping app processes to inject debug instrumentation. Bug: 4437846"

* commit 'a3038e56':
  Support wrapping app processes to inject debug instrumentation. Bug: 4437846

* commit '8f591ff0':
  Support wrapping app processes to inject debug instrumentation. Bug: 4437846

Exception throwing is pretty slow, and BlockGuard's isLingerSocket
causes us to throw whenever we close a non-socket fd. Avoid that
by adding a cheap test for socket fds and only calling isLingerSocket
on socket fds.

Bug: 4972558
Change-Id: Ib18d6c0c091cb366f953d7467e83fad570bb3457

The Format, Private Use, and Surrogate categories were all claimed to be
Cf. The error was only in the summary table. The javadoc for the individual
categories was correct.

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

The public (though hidden) method contentEquals(char[], int, int)
was added to java.lang.String to avoid creating large numbers
of Strings during XML parsing.

That objective is preserved with this change, which uses a private
static method with a similar implementation that goes through the
regular String API.

Change-Id: I808e1ebc4ef6812dd651682628167b4c078af334

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