This will prevent users from losing their language setting when they
take an OTA to M.
bug: 23021286
Change-Id: Ifb66f6bf6a940ab745edac709321f3009ec6eab4
thread_local does not work with Clang at the moment.
Bug: 22414716
Change-Id: I4059b63a1621c346bfc72dbbec0b9cb165485e26
(cherry picked from commit 2bc67a1b5f9d4662ef7da4645ca8e580302b3553)
When starting the runtime from app_process, we only pass JDWP options
if starting zygote. It prevents from opening a JDWP connection in
non-zygote programs while Android apps (forked from zygote) remain
debuggable.
Bug: 23050463
Change-Id: If8ea719063a65db4cdeed69a838b52e87b078b08
We have a bunch of magic that mounts the correct view of storage
access based on the runtime permissions of an app, but we forgot to
protect the real underlying data sources; oops.
This series of changes just bumps the directory heirarchy one level
to give us /mnt/runtime which we can mask off as 0700 to prevent
people from jumping to the exposed internals.
Also add CTS tests to verify that we're protecting access to
internal mount points like this.
Bug: 22964288
Change-Id: I74dbdcb01d4fabe92166b8043a74c6a1e93c6d5f
Makes it more likely for app launches to end up on a large core in
an HMP environment.
bug 21915482
Change-Id: Ieac192a4bc1237dd03b9492fcad3a78de5510a58
Bug: 22214367
Previous releases would let the getters on a recycle()'d bitmap to still
work despite being firmly in undefined behavior per the documentation
on Bitmap#recycle().
As there are apps relying on this, yell very loudly about this behavior
in the log and give them a bit of time to fix it
Change-Id: I857be7e74cb217877973d9c6f03eb761d12fd056
- Add vendor keys to getKeys() calls for CameraCharacteristics,
CaptureRequest, and CaptureResult.
- Vendors can specify whether custom keys show up by listing
visible keys in the REQUEST_AVAILABLE_RESULT_KEYS field.
- Vendor key types are always treated as a primitive (or Rational)
array type corresponding to one of the valid types for
a camera metadata entry.
Bug: 22067625
Change-Id: I6e7dd3db7a8bf533c2ec15ff69ca38824134e971
- Allow both pixelArraySize and preCorrectionArraySize
buffer dimensions for input buffers.
- Adjust crop, active area, and dimensions used for
opcode lists based on the input buffer size.
Bug: 22302614
Bug: 22210811
Change-Id: I16fb8921a144b0a251d555037ca45fdc12f7dd18
To allow ANR dumps to be symbolized easily, hand the build
fingerprint to the runtime.
Bug: 22693991
Change-Id: Ibd3d3b3bd65dce84acfb97a487807d6f280a9508
Bug: 22378829
Use fast-jni for getFontMetrics, drops from 35us -> 30us
Note the "heavy" part of the method, getMetricsInternal, is
already called by other fast-jni methods.
Use critical array access for getRunAdvance_* methods. This
will avoid the copy and the access is appropriately scoped
and fast enough to not significantly block the moving GC.
Improves from 88us -> 79us on short text
Change-Id: I7c1481c23f6dba3420fbcf48220f6335cf9f6d10
Bug:22378829
toLanguageTag is significantly more expensive than previously
thought (note ULOC_FULLNAME_CAPACITY is 157) and weighs
in at around 40us. Given that this is called on every Paint
and that there are typically thousands of Paint objects
created this adds up very quickly.
Given that the locale is almost always Locale.getDefault(),
a very simple thread_local cache of size 1 fixes this trivially
Change-Id: I819e60cac7a4b27e9dd5538332c22ce5bbd0851c
Bug: 22378829
std::string only knows how to move & deep-copy, and we really
don't want either here since the Paint object for certain outlives
the stack scope so use a const reference instead.
Change-Id: I1c822c6ba9647953899cfe89dcc670d7265e3973
Before mounting the requested storage into place, fully unmount all
existing mounts inherited from the root namespace.
Bug: 22192518
Change-Id: I6f7f12c1219d25ee487a031d37c60fb4051d24ad
In practice we only see failed transactions with small payloads when
the remote dies while the binder operation is in flight. Throw the
applicable exception type rather than the generic "oops binder went
haywire" one.
Bug 22104446
Change-Id: I785c15617db7a1f4d505aa11f16e61551c8357ba
Now that we're treating storage as a runtime permission, we need to
grant read/write access without killing the app. This is really
tricky, since we had been using GIDs for access control, and they're
set in stone once Zygote drops privileges.
The only thing left that can change dynamically is the filesystem
itself, so let's do that. This means changing the FUSE daemon to
present itself as three different views:
/mnt/runtime_default/foo - view for apps with no access
/mnt/runtime_read/foo - view for apps with read access
/mnt/runtime_write/foo - view for apps with write access
There is still a single location for all the backing files, and
filesystem permissions are derived the same way for each view, but
the file modes are masked off differently for each mountpoint.
During Zygote fork, it wires up the appropriate storage access into
an isolated mount namespace based on the current app permissions. When
the app is granted permissions dynamically at runtime, the system
asks vold to jump into the existing mount namespace and bind mount
the newly granted access model into place.
Bug: 21858077
Change-Id: I62fb25d126dd815aea699b33d580e3afb90f8fd2
In practice, if we ever see an apparent transaction-too-large result
with a modest-sized payload, it means that the remote process died at
just the right time (with the binder transaction already in flight
so it wasn't detected as a DEAD_OBJECT up front). Don't throw
TransactionTooLargeException in this case, because we really do need
to distinguish that from dead-remote more accurately.
In particular, certain common execution patterns on existing hardware
trigger this circumstance, and they wind up crashing the system.
This is bad, so now we avoid it unless we're pretty sure that is
really what happened.
Bug 21801759
Change-Id: Id05f1eecc0d23dc8d0505c402e2cb68396782135
The measureText method when applied to a string should just measure
the substring, rather than treat the entire string as context. It was
less likely to cause problems than the similar issues with char
arrays, but still wrong. This patch makes the behavior consistent.
Bug: 20087437
Change-Id: I1c6e07a694b151f4fb097edae8e271805e996d06
