Right now this test is focused in the parcelization of a big object, due to an
upcoming refactoring on the Autofill parcelization that does not use
ensureData() to load the structure (which in turn requires calls from
system server to the app).
Bug: 35708678
Test: atest app.assist.AssistStructureTest
Change-Id: I9e1c52b19cd1d82869fa8f48113cc7dd7b00a38c
When the caller attempts to generate a key via DevicePolicyManager
(using DevicePolicyManager.generateKeyPair), and specifies that
StrongBox should be used, throw the right exception indicating
StrongBox unavailability - the same one that is thrown if the same
parameters were passed to the KeyStore's key generation method.
This is achieved by catching the StrongBoxUnavailableException in
KeyChain, returning an error code indicating this particular failure
to the DevicePolicyManagerService, which then propagates it by
throwing a service-specific exception with a value indicating
StrongBox unavailability.
The DevicePolicyManager then raises StrongBoxUnavailableException.
Prior to this change the exception propagated from KeyChain would be
a generic failure so the caller would simply get a null result.
Bug: 110882855
Bug: 111183576
Bug: 111322478
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
Change-Id: I9abe3f449b48eb5a960fafbc15c59b9b4ce7a966
As part of creating a full facade over OkHttp code there
are some changes to OkHttp-related classes that must be tracked.
See the related external/okhttp commit for details.
Some non-functional lint / WS changes have been made as part of this
change.
Test: Ran CtsLibcoreOkHttpTestCases entirely
Test: Ran CtsLibcoreTestCases entirely
Test: run cts-dev -m CtsNetTestCases -t android.net.http.cts.HttpResponseCacheTest
Bug: 111055375
Change-Id: I0b0ec21fa376ea33e2fa5486e203e92d3c3337cf
This had to be called from native because serialization
was done from native, but now that serialization is in Java
we can move this back to a more logical place.
Also, this allows us to dump the per-UID proxy counts in
this situation again.
Bug: 109888955
Test: sailfish builds, proxy debug info shown on hitting limits
Change-Id: I4e06b3f93e30ed1c7868ec9e018709a7e796e441
To make some future refactoring easier.
Added some JavaDoc (mostly links to android.os.IBinder)
to make checkstyle happy.
Test: builds
Change-Id: If9dd6913868a34ea1e3d14fee1860a4ff368e06b
SQLiteQueryBuilder has a setStrict() mode which can be used to
detect SQL attacks from untrusted sources, which it does by running
each query twice: once with an extra set of parentheses, and if that
succeeds, it runs the original query verbatim.
This sadly doesn't catch inputs of the type "1=1) OR (1=1", which
creates valid statements for both tests above, but the final executed
query ends up leaking data due to SQLite operator precedence.
Instead, we need to continue compiling both variants, but we need
to execute the query with the additional parentheses to ensure
data won't be leaked.
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Bug: 111085900
Change-Id: Ie85a95003ae134eef2fdfbf074c2f82d0a6a9f26
When users are building queries, they often need to append several
standalone SQL clauses, and it's tedious to track their first clause
so they can manually append " AND " to each subsequent clause.
So add new appendWherePhrase() API which appends a standalone phrase
which is AND'ed together with any existing WHERE query.
Also fix bug in update() which would turn null values into the
string literal "null" instead of passing them through as SQL NULL.
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Bug: 111085900
Change-Id: Ia280dd864895654239503e080eaef925f5620d37
In certains circumstances, only the base and split APKs were included in
the "old paths" list when updating the application info. Instead, this
list should contain _all_ elements, including any additional libraries
that may be added to the overall classpath.
Bug: 77342775
Bug: 80337129
Test: Manual. Install a package. Install a split with --dont_kill. See that the path doesn't contain duplicate entries
Test: Uninstall GMS updates and reinstall. Verify that GMS Dex files aren't extrated out of the APK.
(cherry picked from commit b9656a93aa)
Merged-In: Id9739cce215ab07bff1b17966583c0cf51a0b34a
Change-Id: I3c61b1b61dc1ab8a1a51a5be68f19ae9af586692
Despite SQLite documentation saying these clauses follow the "expr"
syntax, queries will fail with obscure "row value misused" errors,
so remove the strict enforcement for now.
Test: manual
Bug: 111480817
Change-Id: Ib8cdcb4e6456110589203189fcfa14e75cd68718
Previously battery history is kept in the in-memory mHistoryBuffer
with size of 512KB (96KB on low memory device). When the buffer is
close to full we drop certain types of history. When the buffer is
full the whole buffer is reset and we lost elder history. On a
device with long battery life this problem is more frequent.
This CL changes mHistoryBuffer to 128KB (64KB on low memory device).
When the buffer is full, it is saved to history file on file system.
By default we allow 32 history files (64 history files on low-memory
device) which gives us 4MB history (compare to 512KB today).
The MAX_HISTORY_BUFFER and MAX_HISTORY_FILES can be remote configured
through GServices or P/H.
In case of history exceeding 4MB, the oldest history file is deleted
and new history file is open.
This change increases battery history by using disk file and the
chance of losing history is greatly reduced.
Bug: 67297625
Test: adb shell dumpsys batterystats --history
Change-Id: Id9aafea761649d7323b97d1e44135f7880a95414
Developers often accept selection clauses from untrusted code, and
SQLiteQueryBuilder already supports a "strict" mode to help catch
SQL injection attacks. This change extends the builder to support
update() and delete() calls, so that we can help secure those
selection clauses too.
Extend it to support selection arguments being provided when
appending appendWhere() clauses, meaning developers no longer need
to manually track their local selection arguments along with
remote arguments.
Extend it to support newer ContentProvider.query() variant that
accepts "Bundle queryArgs", and have all query() callers flow
through that common code path. (This paves the way for a future
CL that will offer to gracefully extract non-WHERE clauses that
callers have tried smashing into their selections.)
Updates ContentValues to internally use more efficient ArrayMap.
Bug: 111268862
Test: atest frameworks/base/core/tests/utiltests/src/com/android/internal/util/ArrayUtilsTest.java
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Change-Id: I60b6f69045766bb28d2f21a32c120ec8c383b917
Add 2 additional attirubte |isFocused| and |lastActivityTime| in
ActivityManager.RunningAppProcessInfo and pass them to Chrome via IPC
so Chrome can better prioritize ARC processes.
Bug: 29576205
Test: Ensure new process information is passed to Chrome.
DateUtilsBridge is only used in one place in framework.
The usage is avoidable by sticking to java.util. This
decreases the number of non-public libcore classes in
use by framework.
Test: build
Bug: 111055375
Change-Id: Ifd6576b5b6df1e154f16ec201a4575d0b95de66d
The updates to the HWUI renderer now require that setOverlappingRendering be
set when shadows are used. Without this change modifying the alpha of the
TextView will produce incorrect blending results.
Bug: 111381525
Test: Test app in bug
Change-Id: I523c5ef698e8db912dd2ef848eeeffb3465b990a
Keeping the code in memory of the currently set home app is
important for latency as we don't have any kind of starting
window/splash screen when pressing the home app to hide any latency.
Memory impact:
Pinning dex/vdex:
In practical scenarios, this should be < 500kb.
The home app is usually profile-speed compiled, for which the
resulting dex/vdex files are about 2 mb. However, during regular
use, at least 1.5 MB of it is referenced in memory. This makes
sense: By definition profile-speed only compiles the things that
is usually frequently executed during regular execution.
Pinning apk:
With Launcher 3 in practical scenarios this should be about 3.7 MB,
as the APK is about 5.7 MB but 2 MB are usually referenced in any
case.
Bug: 111132016
Bug: 78585335
Test: Inspect "adb shell dumpsys pinner" after boot.
Test: Check for pinned files after updating camera/home.
Test: Check for pinned files after user switch with different
default apps.
Test: Check for pinned files after bg-dexopt.
Test: Check for pinned files after bg-dexopt + kill pid.
Change-Id: I6cdbc06d089efeb1c72a51216879ba0573502009
Merged-In: I6cdbc06d089efeb1c72a51216879ba0573502009
Keeping the code in memory of the currently set home app is
important for latency as we don't have any kind of starting
window/splash screen when pressing the home app to hide any latency.
Memory impact:
Pinning dex/vdex:
In practical scenarios, this should be < 500kb.
The home app is usually profile-speed compiled, for which the
resulting dex/vdex files are about 2 mb. However, during regular
use, at least 1.5 MB of it is referenced in memory. This makes
sense: By definition profile-speed only compiles the things that
is usually frequently executed during regular execution.
Pinning apk:
With Launcher 3 in practical scenarios this should be about 3.7 MB,
as the APK is about 5.7 MB but 2 MB are usually referenced in any
case.
Bug: 111132016
Bug: 78585335
Test: Inspect "adb shell dumpsys pinner" after boot.
Test: Check for pinned files after updating camera/home.
Test: Check for pinned files after user switch with different
default apps.
Test: Check for pinned files after bg-dexopt.
Test: Check for pinned files after bg-dexopt + kill pid.
Change-Id: I6cdbc06d089efeb1c72a51216879ba0573502009
