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
We can't use the same instance on both the main and the background
thread, as this will lead to problems.
Change-Id: Ieec525f028df2d0596667126d8f5004773461517
Fixes: 28745682
Also fixes a slight bug where a CharSequence extra
was retrieved as a string.
Change-Id: I8a40ab1934b8a20355c3cd4afd66a4a7b91fb517
Fixes: 28775580
Fixes: 28775582
It's raising alarm bells but there isn't much we can do without a lot
of rewriting inside the ActivityManager. The only consequence is stats
that are off by a little bit.
Bug: 28581070
Change-Id: If51568c3a708a907ceef6452e7d45599a57454f7
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
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
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
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
