This makes the time spent in the first call of an app to
SSLSocketFactory.getDefault() drop from ~240 ms to ~50 ms. In M
it was around ~6ms. This is due to the fact that, while instantiating
the default factory, all providers are initialized.
In order to obtain the timings above, I created an app calling
SSLSocketFactory.getDefault in onCreate and timed it
with System.currentTimeMillis() .
Bug: 28545496
Change-Id: I650d4b0435e67e481a41e02b0b538ce5cc993fa3
- 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
We were not keeping track when an app that set an app op restriction
dies to clean up after that. As a result we may end up with stale
restrictions that will be there until the device reoots - not cool.
This change adds remote binder death tracking and simplifies the
code as adding the formed would have made more complex.
bug:28770536
Change-Id: I7dcaafba2354843a0cdf0206ab1f96625edc5120
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
Was missing a content description. The same button is used for
both opening and closing the toolbar, so it needs to be updated
dynamically.
Bug: 28750935
Change-Id: I7f75701ae6af45e5621c36b81003b658479e8b31
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
Netlink notifications about the state of the modem contains uid too.
This patch adds the functionality to add that. It also fixes the bug to
parse the timestamp in the message even in cases where the length is
greater than expected.
Bug: 28527904
Change-Id: I4643bff3eb5b1ffa2dc0b78f1c6947d60487e0d8
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
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
Framework edition
Add a matching onAttachFragment method to Fragment to match the
fragment host version.
Bug 28760393
Change-Id: I5f50b3446449cae7110da6b4e468ee80f413e1e5
Clarified behavior when activity is resized or put in fullscreen
mode, per b/28580007 . Also (per email from o-o) removed misleading
statement about when onStop() might or might not be called.
Both changes can go live now (multiwindow update applies to DP1 & 2,
and onStop() clarification applies to all versions of API), so I'll
submit as soon as this is approved.
See first comment for doc stage location.
bug: 28580007
Change-Id: Ib008f24e5796ec7810b67c91e512e679680d4afd
This change fixes the issue where
getChildVisibleRect(View, Rect, Point, boolean) call isn't recursive.
The method was introduced in I49550ed4082bcbdcfe4643b962b50f3308092525
Bug: 28514727
Change-Id: Ib6b0fb67ca6c700b44f645319c23b1213a2742d4
By changing some member refs into arguments and having one of the
functions create the UID range instead of adding to mVpnUsers.
This will be useful for other layers of UID filtering like having
UIDs explicitly blocked from the VPN.
Deleted one broken line of code that cleared the status intent when
a restricted profile is removed. Other than that, this commit shouldn't
change any behaviour. If it does, that's a bug.
Bug: 26694104
Change-Id: Ieb656835d3282a8ba63cc3f12a80bfae166bcf44
If we're going to show metadata about a resolved implicit intent that
is targeted to a single package with multiple potential targets,
populate the ResolveInfo with the label and icon of the target
package's ApplicationInfo and set resolvePackageName. This helps use
cases such as EXTRA_INITIAL_INTENTS in ChooserActivity, where
sometimes apps set target packages but not components.
Bug 28739056
Change-Id: I8070d341fccc139463c5ac8d66db45fce02252e5
