Since LocaleList needs to depend on android.os.Parcelable, we cannot let
that class belong to "android.util" package, which causes layering
violation.
Bug: 28819696
Change-Id: Ia8de2ee9df3dd0a42b1fe84574439519b680fe18
Also fixes a slight bug where a CharSequence extra
was retrieved as a string.
Change-Id: I8a40ab1934b8a20355c3cd4afd66a4a7b91fb517
Fixes: 28775580
Fixes: 28775582
Hiding the APIs for now since we're not releasing freeform yet and it's
better not to expose them now in case we'll decide to change them later.
Bug: 28774476
Change-Id: Ic2de33c5a611a515fc1c72535587ebf2e0a03a7f
There are few paths I can see to get a null intent down into
the framework at this point. Add in some checks and reports
at those places to mitigate and report such problems.
Change-Id: If235bf342558321d3fabe9363fcebb2bcea18df1
- Added ActivityOption to mark a starting activity as a taskOverlay
activity. That is the activity will always be the top activity of the
task and doesn't cause the task to be moved to the front when it is added.
- Only set the starting window state of the ActivityRecord to shown if
window manager actually showed the starting window for the activity.
Avoids incorrectly trying to remove starting window for an activity that
didn't show any.
- When starting additional activity in a task, transfer the starting
window from the top most activity with a starting window. It is possible
the top most window does have a starting window like in the case of the
forcedResized activity.
- Only ensure visiblity of an activity we are starting in a task whose top
activity is a task overlay. They need to start in the visible-paused state
and not the resumed state which just causes extra churn in the system.
- Always add additional starting activities in a task with an overlay
activity below the overlay activity.
Bug: 28751186
Change-Id: I3624a4313ae9c406d42c67a3537f67ad685791af
We need to incorporate task bounds when calculating the inset hint
so we don't specify something wrong to the client which we correct
immediately after.
Bug: 28697105
Change-Id: I23cec7d6cc62a4d982e0796a867e803d4cce0803
When an UID is added / removed to the Data Saver blacklist, it's
necessary to notify internal components such as the Settings UI (which
was erroneously listening to UID rules changes instead).
BUG: 28743623
BUG: 28791717
Change-Id: I11c85e141dfe074ad390fd324309d2412bfbbd45
Make getX/getY return view-relative position as specified in the class
JavaDoc.
Fix obvious errors in JavaDoc for getX/getY
Bug: 28793547
Change-Id: Ic2ac646189711e7466594d4fc8326408fc0348e1
We don't need to set up JIT profiles and register usage etc when
the package context we're trying to construct doesn't request code.
This will correct accounting for packages which are only used for
resources.
bug: 28519185
Change-Id: I849675efa76c8100ae937de478b52254babe384c
This is a follow-up to my previous CL [1] for Bug 15922840 so that we
can clear the following variables in a more reliable way.
- PhoneWindowManager#mLastInputMethodWindow
- PhoneWindowManager#mLastInputMethodTargetWindow
The idea behind CL [2] is that when InputMethodManagerService (IMMS) is
switching from an IME to another IME, IMMS can send a signal to
WindowManagerService (WMS) to remember the current IME's inset so that
the system can continue using it to reduce jank until the new inset is
specified by the next IME. As summarized in Bug 28781358, however, if
the next IME does not show the window after the IME switch, WMS (or
PhoneWindowManager to be precise) keeps using the previous IME's inset
unexpectedly until the new IME shows its window. All we have seen in
Bug 15922840 and Bug 26663589 fall into this category.
The idea of this CL is just adding a hidden API to InputMethodManager so
that InputMethodService#clearInsetOfPreviousIme() can surely terminate
the IME transition state managed in PhoneWindowManager, rather than
relying on a hack of calling SoftInputWindow#show() and
SoftInputWindow#hide(), which actually does not work for Bug 26663589.
[1]: Ib04967f39b2529251e4835c42e9f99dba2cf43f2
2977eb7b6c
[2]: I5723f627ce323b0d12bd7b93f5b35fc4d342b50c
792faa2c16
Note that addressing all the corner cases in [2] still requires lots of
non-trivial change. Hence this CL focuses only on Bug 26663589 (and
the case we handled in Bug 15922840).
Bug: 26663589
Change-Id: Ib567daa009c1139858dccadcfc6a04465ebecf36
We need to make IIntentSender oneway... but when the system is
calling that for itself, it needs to be able to return a result code.
Solution: instead of directly calling the interface, we have a new
IPC through the activity manager. If the thing being used is the
activity manager impl, it can do the synchronous send and return
the result directly in place. If not, you only get asynchronous
sending and thus never a failure result back (too bad for you!).
Change-Id: I4096e5b00063e8dba66230585a2dfe67e35e8092
Settings is using a MemoryIntArray to communicate the settings table
version enabling apps to have up-to-date local caches. However, ashmem
allows an arbitrary process with a handle to the fd (even in read only
mode) to unpin the memory which can then be garbage collected. Here we
make this mechanism fault tolerant against bad apps unpinning the ashmem
region. First, we no longer unpin the ashmem on the client side and if
the ashmem region is purged and cannot be pinned we recreate it and
hook up again with the local app caches. The change also adds a test
that clients can only read while owner can read/write.
bug:28764789
Change-Id: I1ef79b4b21e976124b268c9126a55d614157059b
am: d29c26073e
* commit 'd29c26073e97e4c6e7825641cf6e76720df395e3':
docs: Updates to multi-window and related docs.
Change-Id: Ic4be60debb41d074d717bfb0989125299428831a
am: c88130c572
* commit 'c88130c5724227b3ba7ef0b5ef4476fedabca650':
docs: Updates to multi-window and related docs.
Change-Id: I308c988e3a93737a478f9f2445b512e86f218643
