Previously the DisplayMetrics passed to a new ResourcesImpl
object would be generated from the default DisplayAdjustments.
We now use the correct DisplayAdjustments for the ResourcesImpl
and make sure to update them for things like rotation changes.
Bug:29619314
Change-Id: If2ba0d7670a4554dcd3fde9766e2337f20a191fd
* changes:
Give WakeupMessage the ability to transport an object as well.
Don't treat the lingerExpired broadcast specially.
Add a test for mobile data always on.
Add a FakeSettingsProvider and use it in ConnectivityServiceTest.
We allow each individual Resources object to select the best
Locale for the given APK. This allows one update to the configuration
instead of multiple updates, once the locale is chosen.
The Java locale is selected from the app context's locale.
Bug:28625993
Bug:27325465
Change-Id: I99e1e53f522e560f3b80bbd1e1c605f552dbdff0
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
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
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
NetworkPolicyManagerService (NMPS) keeps an internal list of uid
rules (mUidRules) for network restrictions, and when these rules
changes it needs to notify external listeners (such as
ConnectivityService / CS).
Prior to Android N, both Data Saver mode (the feature previously known
as "Restrict Baground Data") and Battery Save mode used the same set of
firewall rules to implement their restrictions: when Battery Saver mode
NPMS would mark all networks as metered and set the proper firewall
rules externally.
Recently, these 2 modes were split in 2 distinct firewall rules and
NMPS.updateRuleForRestrictBackgroundLocked() was changed to update
the mUidRules logic based on the Data Saver firewall (since the Battery
Saver firewall changes are handled externally, on
updateRuleForRestrictPowerLocked()). As such, CS was not notified when
the power-related changes were made, which would cause apps to get a
state of CONNECTED / CONNECTED when querying its active connection.
This change refactores the mUidRules to use bitmasks, in preparation for
another change that will fix the issue.
It also fixes a minor bug that was preventing removed packages to be
removed from the whitelist.
BUG: 28521946
Change-Id: I9f0e1509a6192cad403f740c1cd76a6b7dab7d26
am: f71d7fe
* commit 'f71d7feef22db9e0cab2f32edc7440aedb86fdfe':
Ensure local settings caches are not stale
Change-Id: I356b9ad0b6dc1e91bfad140de1b9fc79ab6efef3
We used the system proterties as a shared memory mechanism
to propagate information to local settings caches when the
content has changed and the cache should be cleared. The
system properties are unfortunately updated asynchronously
leading to cases where clients may read stale data.
This change adds a simple int array data structure backed
by shared memory which guarantees individual values are
atomically read and updated without memory tear. Multi-
index opearations are not synchronized between each other.
The settings provider is using the new data structure to
propagate the settings generation which drives when caches
are purged.
We have a single memory array keeping the generation for
different settings tables per user. Since memory array is
not a compact data structure and the user space exceeds
the memory array size we use an in-memory map from keys
to indices in the memory array where the generation id of
a key is stored. A key is derived by the setting type in
the 4 most significant bits and the user id in the 28 least
significant bits.
The mapping from a key to an index is cleared if the user is
removed and the corresponding index in the memory arry is
reset to make it available for other users. The size of the
memory array is derived from the max user count that can be
created at the same time.
bug:18826179
Change-Id: I64009cc5105309ef9aa83aba90b82afc8ad8c659
SamplingTimer has been losing some data, as well as not correctly handling
entries that have gone away and come back with less data (reset).
This change correctly ends a SamplingTimer sample by adding the accumulated amount
to the total, then reseting the running counter to accept new values.
This is also triggered automatically when the incoming data is less than what is currently
recorded.
Bug:25695597
Change-Id: I6b540906e6be527578d1003485384a75ba211b52
am: 752434a
* commit '752434a0ff54ac30b7701292b66361e64b2ae5a0':
Record in progress count when parceling Timer
Change-Id: Icc7e8312df00bd22f0e5433e15fc65d2ad705db4
am: 7ecd767
* commit '7ecd7671b75b2ae7c4d20928722b4a1d41bd62ff':
Delete emojis before and after ZWJ at the same time.
Change-Id: If877cde7549f0bd0e56c7cbd707e360c8df012fd
Vendor may want to introduce their own ZWJ emoji sequence. To delete
them by one back space as the same behavior of Unicode emoji sequence,
use all emoji as the zwj emoji.
Bug: 28248662
Change-Id: I572dad42ee108476962d4b3fe9f3a6019cb50098
While processing an unlock request, we might go async to handle
long-running operations like dispatching PRE_BOOT_COMPLETED. This
change ensures that all unlock requests for a particular user wait
in line behind any pending async operations.
Without this CL, any subsequent unlock requests would immediately
return successful, even though PRE_BOOT_COMPLETED events were still
being processed.
Bug: 28240584
Change-Id: I307d6aaebfb8f38028f3666a2e19e4399b7cf3a7
am: 5dc3c67
* commit '5dc3c674a2635179d17e96af8fb248142e03b87e':
Add some tests for procstats, and fix some bugs that the tests uncovered.
Change-Id: I53ee3334f58db4a0904370fc4f2f1b6b29365020
This is a follow up CL to my previous CL [1], which added a new key
binding Meta+Space to rotate enabled IME subtypes. With this CL,
Shift+Meta+Space starts reverse-rotating enabled IME subtypes as
originally planed.
[1]: I4005692215edfcf8bed3e86b1e07000148f986f5
ae61f7118a
Bug: 25753404
Bug: 28103839
Change-Id: I3694edd80be6dfe18b90360e24ae4d451b331928
