Adding freeform resizing to activities which require
a certain orientation. This is needed for e.g. ARC++.
Bug: 33267688
Test: runtest frameworks-services -c com.android.server.wm.TaskPositionerTests
Test: Visually on ARC++
Change-Id: If708c1602cb2ff464174389af4648ad767b0b079
We had overriding of PRIVATE format scattered at multiple places.
Consolidate them into one place.
Test: Camera preview/capture, and camcorder recording
Change-Id: I098ce93bba2000760a20c0297fcf0cb9d8c6caab
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: Ib8e50afcdb5475123968572ac9696e8ed4031631
- Add a set of write methods to ProtoOutputStream that figure out the type.
The other methods are doing all the type checking anyway, so this won't be
much slower, and it's way easier to use. The expected java type casts
that people would do anyway happen inside.
- Add writeObject and writeRepeatedObject methods that write a pre-encoded
object.
- Add a constructor that takes an OutputStream, and a flush() method. Right
now, all the data gets flushed at the end, but given this API it would be
possible to write smaller chunks at the object boundaries and do more
sophisticated buffering.
Test: CTS
Change-Id: Ieb852092d3d65812c81139558151de9e3f467dc8
If multiple async shared preferences writes are queued, all but the
last one can be ignored as they will be overwritten by the last one
anyway.
For commit() we need to make sure that we have at least persisted the
state of the commit.
Generation counts are 64 bit, hence they never overflow.
Test: Produced a lot of SharedPreferences.Editor.apply and did not see
excessive writes anymore, ran SharedPreferences CTS tests
Bug: 33385963
Change-Id: I3968ed4b71befee6eeb90bea1666a0bb646544f6
Add Payload and PayloadType to the SearhIndexablesContract to support
the new Search architecture in Settings Search.
Change-Id: I07e411ead11d420c19c737fad79d459f44288681
Test: SettingsUnitTests
Bug: 33390556
When Binder calls are nested, we can quickly end up with a snowball
of stacktraces that can cause the original transaction to fail. This
CL makes two specific changes to alleviate this pressure:
-- Consider a nested Binder call from PID A -> B -> C. If both B and
C encounter dozens of StrictMode violations, then gatheredViolations
in B will end up with 10 ViolationInfo (5 from B and 5 from C). This
problem only grows with each successive nested call. To solve this,
always limit ourselves to only ever write out 3 ViolationInfo from
any given process.
-- CrashInfo already nicely truncates any large stack traces to 20kB,
but readAndHandleBinderCallViolations() blindly appends the entire
local trace, and never considers truncating again. Similar to the
first problem above, nested calls can quickly cause the stackTrace
value to explode in size. To solve this, we always re-truncate the
stackTrace value after appending our local stack.
Also fix some NPE bugs when missing crashInfo.
(cherry-picked from commit 58f27b5033)
Test: builds, boots
Bug: 32575987
Change-Id: Ie8373ca277296f920f2b1c564d419c702a8ee0f2
Change is preventing the device from showing the lock screen
after the boot animation.
This reverts commit 4647acb60e.
Bug: 33098677
Change-Id: If7ecb04b74d5b626c7c3517e7e8d1dc1566ccb17
If construction of a new IpReachabilityMonitor throws an IAE then
log it and immediately call onProvisioningFailure().
Test: runtest frameworks-wifi
passes, except for selectQualifiedNetworkDoesNotChooseDeletedEphemeral()
which fails with an NPE for unrelated reasons.
Bug: 31038971
Bug: 31742703
Change-Id: Ie91b8bdd509d06ad54d062bf446e74c092eb096c
(cherry picked from commit e452660466)
When Binder calls are nested, we can quickly end up with a snowball
of stacktraces that can cause the original transaction to fail. This
CL makes two specific changes to alleviate this pressure:
-- Consider a nested Binder call from PID A -> B -> C. If both B and
C encounter dozens of StrictMode violations, then gatheredViolations
in B will end up with 10 ViolationInfo (5 from B and 5 from C). This
problem only grows with each successive nested call. To solve this,
always limit ourselves to only ever write out 3 ViolationInfo from
any given process.
-- CrashInfo already nicely truncates any large stack traces to 20kB,
but readAndHandleBinderCallViolations() blindly appends the entire
local trace, and never considers truncating again. Similar to the
first problem above, nested calls can quickly cause the stackTrace
value to explode in size. To solve this, we always re-truncate the
stackTrace value after appending our local stack.
Also fix some NPE bugs when missing crashInfo.
Test: builds, boots
Bug: 32575987
Change-Id: Ie8373ca277296f920f2b1c564d419c702a8ee0f2
Defining a new system API that will allow the system to request
network recommendations from a NetworkScoreService implementation.
Test: Coming in a future CL.
BUG: 32909424
Merged-In: I2d5c0a843b928b04e87c1862a78702a02fd54c31
Change-Id: Idd33095c6cd2f5b391796c900399f18a2c40fcc3
When updating the non direction members of screenLayout
we check that they are not in total undefined, before
accepting the new value in full. This was enough for LONG/SIZE
which are always undefined or set together. It seems we have paths
now where SCREENLAYOUT_ROUND however can be undefined and the others
will be set. In this case if we pass a configuration with SCREENLAYOUT_ROUND_UNDEFINED
but LONG/SIZE set to updateFrom then we will overwrite our previous SCREENLAYOUT_ROUND value.
This triggers extra configuration changes.
Bug: 33098677
Test: bit FrameworksCoreTests:android.content.res.ConfigurationTest
Change-Id: I6eb321d27011a2af2134d0ed5b6864d4cd902dc3
Bug 33377297
When an exit transition was finished after the onStop was received,
the final visibilty ended up being INVISIBLE. To prevent this,
when views are being reset to the initial location, the transitions
are forced to end prior to changing the final values.
Test: I10517bb5f1477824f1e54109e7be766225591d24
Change-Id: I3837927bb41623a3a146fc3a42209c9a81c99a38
Defining a new system API that will allow the system to request
network recommendations from a NetworkScoreService implementation.
Test: Coming after the API is approved.
BUG: 32909424
Change-Id: I2d5c0a843b928b04e87c1862a78702a02fd54c31
