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
Fixes a bug where the max lines restriction was not properly
passed to ImageFloatingTextView's layout, causing the TextView
to improperly apply bottom padding.
Change-Id: Ibe07515866a4599047712a0482332ed4430c9056
Test: runtest -x core/tests/coretests/src/com/android/internal/widget/ImageFloatingTextViewTest.java
Fixes: 32658499
Bug: 32658499
Properly account for VPN apps that make heavy use of the tun
interface. Prior to this change a VPN app could be incorrectly charged
for more data than it actually used if it sent more traffic through
the tun interface than the underlying interface.
This change excludes VPN app traffic on the tun interface from the
adjustment pool and doesn't redistribute traffic to the VPN app.
Instead all of the redistributed traffic is deducted from the VPN app
which effectively represents any overhead incurred by the VPN app.
BUG: 30557871
Change-Id: I62a75a0c0c0111e052b7903baa9f5d6d94ef57fd
When we create a file that already exists, we try attaching a suffix
like "(1)" to the filename to avoid the conflict. The newly added
rename method should do the same, since developers may not have
access to delete the conflicting file.
Test: boots, rename via UI, new unit tests
Bug: 31545404
Change-Id: Ie397eebb0fbf98cf079eee3bbbb6c6b7ca627d91
LoaderManagers configure their host callback lazily as their
associated fragment is brought up through its lifecycle states. In the
case of fragments on the fragment back stack this could happen very
late, if at all. As a LoaderManager's host callback references the
host Activity, this means that a LoaderManager could keep a destroyed
Activity reference alive.
Update the host callbacks of all LoaderManagers eagerly during the
restore non-configuration instance phase.
Bug: 30653222
Test: core/tests/coretests/src/android/app/LoaderLifecycleTest.java
Change-Id: I5d2b81daae5e7cae429fcf4934e64b3ce281140c
This change adds a new pathMatch attribute to the intent-filter tag
that supports a subset of regular expression syntax. Supported
tokens include dot (.) and set ([]) and supported modifiers include
zero-or-more (*), one-or-more(+) and ranges ({}).
Change-Id: I2ec3bc8a9eb3e94d21caf34a1ed0f3fd3fb33a35
Bug: 30805203
The summary is supposed to just hold enough data to continue counting
once the device has reset. Since kernel stats reset when the device
resets, and the first update is ignored to account for soft resets where the
kernel continues running, SamplingTimer should not be recording the last value
it saw from /proc/wakelocks in the summary.
Bug:30575302
Change-Id: Ic193bc5af9a0ede514e3abc8146523d7316c47d3
Tests that long stack traces and exception messages are
truncated to a reasonable size when a CrashReport is generated.
Bug: 29918978
Change-Id: I4d8202ddca850a72e0853e4064d5690965ff371c
The gender-balanced emojis are made with ZWJ sequence and emoji
modifiers. For example, U+1F469 U+1F3FD U+200D U+1F4BC should be
deleted at the same time by single backsapce key event. Here, U+1F469
is WOMAN, U+1F3FD is EMOJI MODIFIER FITZPATRICK TYPE-4, U+200D is ZERO
WIDTH JOINER, U+1F4BC is BRIEFCASE.
This CL also renames the state name from STATE_BEFORE_ZWJ_EMOJI to
STATE_BEFORE_EMOJI since now all emoji can be a part of ZWJ sequence
after I572dad42ee108476962d4b3fe9f3a6019cb50098
BUG: 29728397
Change-Id: Ib114295db45c6592f1c65a0773ab236f8bf35209
(cherry picked from commit bba8d97c36)
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
(cherry picked from commit 8e8d23214a)
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
