MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Ibf56827209a9b791aa83ae679219baf829ffc2ac
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: I1004579181ff7a223ef659e85c46100c47ab2409
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Id7f0e8a4c861b0b9fa796767e0c22d96633b14d1
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Ie267646eb88014034fbd048d7a9bc273420c7eff
Fix a bug where the DisplayMetrics wouldn't be updated for a Resources
object on the default display. Since multi-window, we want to update
all Resources.
This didn't always manifest itself due to recreation of assets, which
would force an update of DisplayMetrics. Re-use of an AssetManager from
the cache would expose the bug.
Bug:32133693
Bug:31998629
Test: cts-tradefed run cts --module CtsServicesHostTestCases
Change-Id: Ic51ab82710517b87eb995ccf982085dba876ad58
Sync adapters without an account access cannot run until the
user approves the account access (for the case the account
access is not allowed by other policy such as being singed
with the same cert as the authenticator). If the sync adapter
does not have permission to access the account we ask the
user to grant access and take a note. This CL adds backup
for the explicit user grants.
bug:31162498
Change-Id: I31e3f3d010475352c7c54255ac2d3a2fed4d0c72
Use ParcelFileDescriptor only as an IPC transport
to make sure MemoryIntArray manges its backing fd.
Bug:30310689
Change-Id: Ib3cc13ef4ae2a744e5f7a96099570e0431847bce
(cherry picked from commit fe2462f3a6)
Use ParcelFileDescriptor only as an IPC transport
to make sure MemoryIntArray manges its backing fd.
Bug:30310689
Change-Id: Ib3cc13ef4ae2a744e5f7a96099570e0431847bce
Instead of crashing, log a wtf and recover. This is not a problem
in ArraySet, but caused by someone else using an ArraySet without
protecting access to it. So whoever is calling at this point is
not the cause, and it isn't worthwhile to let them crash.
Change-Id: Iaefa4315b620c9fe24b31507e4aa47a8525c8540
(cherry picked from commit 92aa4b2ba3)
Instead of crashing, log a wtf and recover. This is not a problem
in ArraySet, but caused by someone else using an ArraySet without
protecting access to it. So whoever is calling at this point is
not the cause, and it isn't worthwhile to let them crash.
Change-Id: Iaefa4315b620c9fe24b31507e4aa47a8525c8540
append() is used to optimized insertions in the array, but it must
preserve the order of the hashcode array; when it doesn't, it falls back
to append(), but it should not log a warning message
In particular, PendingIntentRecords might have different hashcodes
across different processes.
Fixes: 29912192
Change-Id: I0ab566249829ddb934fd51cf21399b68cb286bd5
We need to make every peniding intent that went in the notification
system to allow special handling of such intents when fired by a
notification listener. If a pending intent from a notification
is sent from a notification listener, we white-list the source app
to run in data saver mode for a short period of time. The problem is
that actions and the notificaion can have extras which bundles may
contain pending intents but the system cannot look into the bundles
as they may contain custom parcelable objects. To address this we
keep a list of all pending intents in the notification allowing
the system to access them without touching the bundle. Currently
the pending intents are written to the parcel twice, once in the
bundle and once as the explicit list. We can come up with a scheme
to optimize this but since pending itents are just a binder pointer
it is not worth the excecise.
bug:29480440
Change-Id: I7328a47017ca226117adf7054900836619f5679b
Add supported screen densities to closer match some hardware's physical specifications
BUG: 24132725
Change-Id: I7138d92fa4e1f4320f9068e154bd8318ac0c45c7
We now have a new settings key that provides all of the existing
tuning parameters, plus some newly redone ones for dealing with
different memory levels.
Changed the minimum batching for overall jobs from 2 to 1, so
we will never get in the way of immediately scheduling jobs
when the developer asks for this. We should now be able to rely
on the doze modes to do better batching of jobs for us when it
is really important.
Also work on issue #28981330: Excessive JobScheduler wakeup alarms.
Use a work source with scheduled alarms to blame them on the app
whose job they are being scheduled for, and add a check for whether
a job's timing constraint has been satisfied before considering it
a possible candidate for the next alarm. (If it is satisified,
the time is in the past, so we should not schedule an alarm for it.)
Finally clean up a bunch of the dumpsys output to make it easier
to understand.
Change-Id: I06cf2c1310448f47cf386f393e9b267335fabaeb
This fixes a bug where APK JAR signature verifier returned the wrong
certificate chain. Rather than returning the cert chain of the
verified SignerInfo, it was returning the bag of certs of the PKCS#7
SignedData block.
This issue was introduced in Android N and thus does not affect
earlier Android platform versions.
Bug: 29055836
Change-Id: I684c0f8e9ff47b922030645e07b6a114c0eb0963
TalkBack is seeing crashes that I can only explain by our assumption
that window layer is unique in all cases. TalkBack reports that it
happens during animation, so I assume that the layer may repeat
transiently.
Reducing our dependence on this assumption by traversing the list of
windows sorted by layer without assuming that the list has the same
length as the list of unsorted windows.
Also documenting the undefined behavior of SparseArray when indexing
beyond its bounds. The undefined behavior itself is intentional for
performance reasons.
Bug: 28679528
Bug: 28815817
Change-Id: I0c9f90b0b458b4cde465f603ba204fe6691e5c2c
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
This commit makes the LocaleList constructor require non-null
arguments in all cases, and fixes all uses of LocaleList that could
previously pass a null to use getEmptyLocaleList() instead (which is
preferred anyway becaues it avoids an allocation.
Bug: 28460668
Change-Id: I4b8b3cfa82914412731c2b79003951c46cb2afa1
-- Remove default constructor from public API since getEmptyLocaleList exists
-- Merge the Locale and Locale[] constructors by providing a single Locale… varargs constructor
-- forLanguageTags, get, toLanguageTags, size, need docs
-- get(int location) should be get(int index)
Plus general docs improvements
Bug: 28296200
Change-Id: I8b4e67184f8c723daebcd251f04947d48bbb5478
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
Wrap Patterns.UCS_CHAR character class with brackets. Previously CL
Ie6df818dc4d33dfee6ee54432a2231cca51ec423 broke autoLink email and URL
patterns while excluding the empty spaces.
Bug: 28020781
Change-Id: Ieb7d09cb5e544c1e7cbc1a4d665b979c65e7e773
Excludes the following space characters from autoLink URL patterns:
\u00A0: no-break space
\u2000: en quad
\u2001: em quad
\u2002: en space
\u2003: em space
\u2004: three-per-em space
\u2005: four-per-em space
\u2006: six-per-em space
\u2007: figure space
\u2008: punctuation space
\u2009: thin space
\u200A: hair space
\u2028: line separator
\u2029: paragraph separator
\u202F: narrow no-break space
\u3000: ideographic space
Bug: 28020781
Change-Id: Ie6df818dc4d33dfee6ee54432a2231cca51ec423
Android platform does not support DSA with SHA-512. Thus, it does not
make sense to support this unsupported algorithm in APK Signature
Scheme v2.
Bug: 24331392
Change-Id: Ie90b3dd8dd67bad65c64dfb7f6bf427e8ed282ba
