am: 4dbdd5d971
* commit '4dbdd5d97155364305abf7c010c165f1a6f79edb':
Add data from /proc/pagetypeinfo to procstats.
Change-Id: Ic86eb0ad4278dc2d0b7f93148bab00a1f707dc16
This data tells us the number of pages of each type that
are available by page size. It is collected each time
the procstats snapshot is taken, and printed in the
checkin and verbose (dumpsys procstats -a) modes.
Change-Id: I14562eac15833617391c560638a9e7d239ef8db6
am: d86ac8116b
* commit 'd86ac8116bfc64c61d8124ff8d3e92be5e55cd3e':
New api in LockSettingsService to get StrongAuth synchronously
Change-Id: I3fe13c51d5d33f5689f0b4130a33cf3a2777e186
We handled stale wakelocks (wakelocks that disappear from /d/wakeup_sources)
differently in previous version of Android. They would be set stale, but still be
updated with their previous counts (they would never disappear).
The method setStale has been replaced with endSample(), which is semantically different.
Once a SamplingTimer has endSample() called, it expects any future calls to update() to
be a new sample, meaning the entire amount passed to update() is included in the kernel
wakelock's total. Since stale wakelocks were never removed from the list, this would
increase by large amounts when nothing had actually changed.
This was exacerbated by the fact that there was a bug where the last wakelock in
/d/wakeup_sources was never parsed, so if the order ever changed, this "stale" wakelock
would suddenly re-appear and the entire amount reported would be charged to the wakelock,
instead of just the difference since the last update.
All this was exposed when we added support to handle wakelocks that would disappear and
reappear with smaller values, meaning the kernel had pruned them from its accounting and
reset them.
Bug:28601080
Change-Id: Ic96027f7d580dac5e20aa73d67e5cedac4ccabeb
When a null window background is set, we want to use the
fallback drawable for resizing.
Bug: 28801472
Change-Id: Ia616d7aa18b0d7aa2c7081a85ce7551ecfeca5b3
Instead of in activity thread. That way, we can warm up (ie,
precompute cached values) this provider and AndroidBCWorkaroundProvider
(which are installed together) so that the computation doesn't
happen in the app. As a result, the time spent in the first call to
SSLSocketFactory.getDefault() decreases by ~5ms in angler userdebug.
Measured with an app calling SSLSocketFactory.getDefault in onCreate
and timed it with System.currentTimeMillis() .
Bug: 28545496
Change-Id: I73284eccdf6d51dbf55206335d759ccf795c5f41
Upstream ICU caches use SoftReferences. On Android this means
that useful cached data initialized in the Zygote are "lost" when
the Zygote GCs and cannot be shared with apps. This change makes use
of an Android patch to ICU to ensure References created during
Zygote initialization are "strong". i.e. they are never collected.
This prevents them being GCd and ensures they can be shared between
applications.
After switching ICU to use strong references, this change
also creates DecimalFormatSymbols objects for common ULocales
(ROOT, US and the user's default, if different). DecimalFormatSymbols
makes use of an ICU Reference cache and this alone has been shown to
improve the construction time of java.text.DecimalFormat by 1-1.5
milliseconds on a Seed device. This saving applies the first time one
is created in each app for each locale, and again if SoftReferences
have been cleared.
The cost to the heap size of the Zygote has been measured at ~107k.
This value will change as more caches are switched to use the new
CacheValue class.
Formatting is typically performed on the UI thread and the intention
of this change is to reduce app start up time and jank in apps like
the Dialer which do a lot of formatting when scrolling lists. The
change may also enable more virtual memory page-sharing between
apps, though this is not the specific goal.
Bug: 28326526
(cherry picked from commit 41c9dc3b69)
Change-Id: I48e4d57ecbb207b9a5e17b6caf5e7b282e4a40e3
Not all client needs to monitor the StrongAuth, e.g. ConfirmDeviceCredentialBaseFragment
Provide a quick method to get StrongAuth
Bug: 28752364
Change-Id: Iecfd217046da38e43297bdd5832cf7d637b979ed
am: 8491b4c05d
* commit '8491b4c05d35b15e0a4c1a0ef2396cbb7169698a':
Add support for ICU data pinning in the Zygote
Change-Id: I64ba8a96ab8990a051a68cbdb35f4b1de3738d09
am: 9b1d64410d
* commit '9b1d64410dfddc38ade15d1581de2c89ad79948a':
Add support for ICU data pinning in the Zygote
Change-Id: I53a2d5f885df5cf633a4a63cb2e3c2bc5c75959e
Upstream ICU caches use SoftReferences. On Android this means
that useful cached data initialized in the Zygote are "lost" when
the Zygote GCs and cannot be shared with apps. This change makes use
of an Android patch to ICU to ensure References created during
Zygote initialization are "strong". i.e. they are never collected.
This prevents them being GCd and ensures they can be shared between
applications.
After switching ICU to use strong references, this change
also creates DecimalFormatSymbols objects for common ULocales
(ROOT, US and the user's default, if different). DecimalFormatSymbols
makes use of an ICU Reference cache and this alone has been shown to
improve the construction time of java.text.DecimalFormat by 1-1.5
milliseconds on a Seed device. This saving applies the first time one
is created in each app for each locale, and again if SoftReferences
have been cleared.
The cost to the heap size of the Zygote has been measured at ~107k.
This value will change as more caches are switched to use the new
CacheValue class.
Formatting is typically performed on the UI thread and the intention
of this change is to reduce app start up time and jank in apps like
the Dialer which do a lot of formatting when scrolling lists. The
change may also enable more virtual memory page-sharing between
apps, though this is not the specific goal.
Bug: 28326526
Change-Id: Ia2c73f6525f05b1aa81e57a31eed1616decf6bb5
am: 45165c9373
* commit '45165c9373f1bf2dbe0c3f11b271daa24414ea35':
Demote the log in ProcessState.ensureNotDead from a wtf to a warning.
@hide SystemHealthManager.from
Change-Id: Id56c7ee80254eac26132956ef62b83c405a0e2f8
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
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
The method warmUpJcaProviders arrived here from both nyc-dev
and aosp/master, removing duplication.
Change-Id: I2d91ee38fe93f600bec89651416e84ab83ef9d4a
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() .
(cherry picked from commit 6cb7b1c476)
Bug: 28545496
Change-Id: Ic5aab3ece609d9fef06fee4ccb83d8371af075b2
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
am: 008d73bd5b
* commit '008d73bd5b3ca4b1b7a8af61957759d65dd67e3b':
Ensure app op restrictions reset when the app that set them dies.
Change-Id: I177256a7f65b3f5c98e5ddc5cf57a7cb47c965ab
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
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
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
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>
