The ephemeral provider is a service that simply determines whether or
not an ephemeral application is available. The ephemeral installer
does the heavy lifting of installing the ephemeral application.
Bug: 25119046
Change-Id: I591f4c2c3f2b149d299fa8b4f359f2582d9199cb
The crash was happening because we were sending a future from sysui, but
that future would always return null animation specs when docking. This
makes it returns proper specs in that case. However, we need to still
protect ourselves from null specs when executing the future.
Bug: 25765339
Change-Id: I02d842ea31503169f6e053a1695d8896d2e4d97c
Add new "am unlock-user" command so we can trigger changes from the
command line.
Move FBE check to static method so it can safely be called early
during boot before the mount service is ready. Move FBE emulation
to persisted system property, and start reading/writing that value.
Change default permission grants to ignore current encryption-aware
flags, since many of the target apps aren't crypto aware.
Always prepare package data directories, which is how we create the
new "user_de" paths during boot.
Bug: 22358539
Change-Id: I6f58ea2d34b3a466d3775d614f8a13de92272621
in the same was as we allow then to turn of debuging notificaitons
this is useful for screenshots and demos
Change-Id: I6e95addec2917abdd619086ed68910097fb5b8aa
Traditionally, when a view called requestLayout it would force
recursive requestLayout calls for all parent views up the
hierarchy. This meant that there was no way to determine at traversal
time whether a parent view itself needed layout, or if just one of its
descendants did.
Add a ViewParent method requestPartialLayoutForChild(View). This lets
a caller state that a particular child of a given parent needs a
remeasure and relayout at its current measured size and position
within that parent. This can help prevent the full-tree relayout often
caused by otherwise trivial changes. Partial layouts are processed
after any pending "full" relayout during ViewRoot traversals, but
before drawing.
Add a ViewGroup method requestLayoutForChild(View). This lets a
ViewGroup decide whether it is more appropriate to request a
traditional relayout or a partial layout for itself or just the child
that changed.
Add a ViewParent method findDependentLayoutAxes. This allows a caller
to check if the ViewParent's layout is dependent on a specific direct
child view along one or both axes. Called recursively, this can be
used to determine if a change in a child view can be isolated to a
partial layout, even if its direct parent's own layout is tied to its
other ancestors. (e.g. MATCH_PARENT, LinearLayout weights)
Implement ViewGroup#requestPartialLayoutForChild to call new
ViewParent method findDependentLayoutAxes and based on the result,
either request a full layout for itself or a partial layout for the
child in question.
Implement findDependentLayoutAxes for common framework ViewGroups. A
private implementation in ViewGroup is available for use by framework
classes that will deal with basic LayoutParams. These implementations
specifically check for derived LayoutParams classes and abort the
optimization if they find something beyond their expected parameter
types.
Change-Id: I0a1a9b79293d17d4fae8d9892b96d3586f9401ae
Refactors density handling to look more similar to GradientDrawable's
implementation, which should make things easier to maintain. We no
longer update density directly in updateStateFromTypedArray, instead
handling it in applyTheme() and inflate().
Lazily calculates local density-dependent dimensions and invalidates
when the constant state density changes, which should ensure a random
call to applyTheme() will still result in the correct intrinsic
dimensions.
Change-Id: I726878a6cd75d38a550637e3e7a7b6bc68bcaf6d
ContentProvider is a singleton of the process. So it may live longer
than Service. We could not close database when the service is destroyed.
BUG=25730042
Change-Id: I591250c1a1e7c5705eb2585c71cac2598c0c0fb9
Suppose the following case:
1. Launch an activity.
2. Focus in an EditText on the activity. IME is shown up.
3. Kill the activity process in a not graceful way, e.g.,
'adb shell kill'
After step 3, IMMS#removeClient(client) is immediately called back from
com.android.server.wm.Session, which is good, but we forgot to clear
IMMS#mCurClient to null.
Basically not clearing IMMS#mCurClient there is not so critical, because
1) we already have bunch of RemoteException check for the case where
IPC target is already dead, and in theory we cannot avoid this kind of
runtime error anyway, and 2) in most of cases new input method client
gains focus.
That said, in conjunction with other focus-related issues such
as bug #25373872, not cleaning that can result in the following error
message in 'input_method:' section of bugreport, which might be a bit
confusing.
Input method client dead: android.os.DeadObjectException
The primary goal of this CL is to make bugreport less confusing. Any
user/developer-visible changes beyond that is unintentional.
Bug: 25373872
Change-Id: Iee001ad9cce0c8c6324e3c0984be1e6f0e641d05
