Age | Commit message (Collapse) | Author |
|
4256261, 4256262, 4254470, 4254471, 4256281, 4255145, 4255146, 4255252, 4255253, 4255254, 4255255, 4252780, 4255147, 4252862, 4256148, 4256149, 4256150, 4256151, 4256152, 4256153, 4256154, 4255256, 4255257, 4255258, 4255259, 4253843, 4253844, 4253845, 4253846, 4253847, 4253848, 4253849, 4256156, 4256269, 4256272, 4256273, 4256401, 4255338, 4255339, 4256422, 4256402, 4256157, 4256223, 4256224, 4256158, 4256159, 4256160, 4256441, 4256442, 4256443, 4256444, 4256445, 4256446, 4256447, 4256448, 4256449, 4256450, 4256451, 4254472, 4256285, 4256403, 4256274, 4256424, 4256452, 4256275, 4256276, 4255153, 4253850, 4253851, 4253852, 4253853, 4253854] into sparse-4732991-L34000000179248081
Change-Id: Idedf026d57da0d4d092329143de43339a480ccac
|
|
writeInplace() itself already pads securely, by masking off
the padded bytes. If the padding is done before calling
writeInplace(), no mask is applied, and heap data can leak.
Bug: 77237570
Test: builds
Change-Id: Ide27a0002d4ed4196530430760245b971f6a3f44
Merged-In: Ide27a0002d4ed4196530430760245b971f6a3f44
(cherry picked from commit f8542381b72a7bb2452a5278a00ca8c34edbf8a0)
(cherry picked from commit 732132b765cd7b667f16cf32f0fe4c852d7d44dd)
Change-Id: I7a4135f56c34f209b63a948a8e366ce88c9aac87
|
|
Make sure to increment the parcel data position even when trying to
improperly read from protected data
Bug: 29833520
Test (M): cts-tradefed run cts -c android.os.cts.ParcelTest -m testBinderDataProtection
Test (M): cts-tradefed run cts -c android.os.cts.ParcelTest -m testBinderDataProtectionIncrements
Test: cts-tradefed run cts -m CtsOsTestCases -t android.os.cts.ParcelTest#testBinderDataProtection
Test: cts-tradefed run cts -m CtsOsTestCases -t android.os.cts.ParcelTest#testBinderDataProtectionIncrements
Change-Id: Ie4aae6277fc5f5c924f603d9828c3a608998b986
Merged-In: Ie4aae6277fc5f5c924f603d9828c3a608998b986
(cherry picked from commit 6a825e8ad1a3928dd872bb7c3fbcd94784d77267)
|
|
The check added to each non-object reads adds an overhead. If the
objects (binders and file descriptors) were written to the Parcel in
sequential order then check adds a small O(1) overhead to each read,
plus an O(N) overhead to the first read (to verify the N objects were
added in order).
If the objects were written out of order (as in by jumping around the Parcel
with setDataPosition and writing Binder, DON'T DO THIS!!) (writing non
objects out of order is fine), the first read is forced to sort the objects
in the internal bookkeeping. Based on the assumption non sequential writes
are infrequent and overall Parcels are probably mostly sorted, insertion
sort was used. Worst case sorts will add an O(N^2) overhead to the first
non object read from the Parcel.
Test: run cts -m CtsOsTestCases -t android.os.cts.ParcelTest
Bug: 29833520
Change-Id: I82de8eb5f5eb56f869542d5358e96884c24301b2
(cherry picked from commit c517681c66a1a387be657e0cf06da8d19659dd14)
|
|
Change-Id: I9e1c316fea8f2bdf18fb8ad0bb38f5c4d6485fe7
|
|
If more than one pointer is present and identical coordinates are
encountered for any pointer, the lastResample value will not be
invalidated (by clearing its bits). As a result, the same lastResample
value will be used to subsequently rewriteMessage any time in the
future. This can cause significant jumps in the pointer coordinates, and
is a bug. To further clarify, this bug has only to do with resampling
and nothing to do with both pointers having the same X or Y value.
This CL makes this logic to be per-pointer. As soon as non-identical
value is encountered and the timing conditions are such that the
resampled value is not needed to be used, the lastResample bit for that
pointer will be cleared, meaning that the value in lastResample for this
pointer is stale. This value will no longer be used anywhere.
When performing resampling, allow the process to happen on a per-pointer
basis. If one of the pointers has encountered events with identical
coordinates, then use the previously resampled value (do not resample
again), if that value is still valid (see above). Otherwise, the normal
resampling path will be taken. On the other pointers that do not have
identical coordinates, go through the normal path as well.
Bug: 68840121
Test: recorded a repro event with inputstudio and replayed it while
observing the screen. Saw that the coordinates jump before the fix,
and do not jump with the fix.
Change-Id: If43c323759de8f0184b76221d1ae599a75349ce9
Merged-In: If43c323759de8f0184b76221d1ae599a75349ce9
(cherry picked from commit 3bb597138bc53416b3049caa48c618075ec24231)
|
|
3783029, 3783030, 3783164, 3783165, 3783167, 3783168, 3783170, 3783171, 3783172, 3782288, 3783031, 3782196, 3782955] into oc-m4-release
Change-Id: I829c1af8a0e059880daf61bdd4aca5cc9132c345
|
|
Avoids attempting to read a 0-size array during input validation. Adds
SafetyNet logging when this is triggered.
Also, change the cast for the ashmem size check from int to int64_t to
avoid potential conversion to negative number on 32-bit systems.
Bug: 70986337
Test: run POC, confirm via logs that function bails early
Change-Id: I674285738983f18de3466f9e818d83dabe269b7d
(cherry picked from commit 0eb4624b33aeb375ae431a6b1e2b787c959968fe)
|
|
Change-Id: Ic38ee6339dd717720126bf9e16c404d37136feaf
|
|
Change-Id: I4589d60c744dbd4cdb448d12d1b3c5839a48eca7
|
|
Change-Id: Ia10521643f057e000f1e59febfd77668963597e2
|
|
3278010, 3277767, 3277768, 3277769, 3277770, 3276509, 3276510, 3278011, 3278012, 3278013, 3278014, 3278099, 3278100, 3278101, 3278102, 3278103, 3278104, 3278105, 3278106, 3277800, 3276474, 3278015, 3278016, 3278017, 3278118, 3278119, 3278120, 3278121, 3278122, 3277946, 3277905, 3277947, 3277906, 3277751, 3278123, 3277752, 3278110, 3277771, 3277907, 3278095, 3277908, 3278111, 3277772, 3276475, 3276476] into oc-mr1-release
Change-Id: Ife900dfa51f88db5508d790a3db28251a7038f23
|
|
There are more issues than I expected :)
- no lock to synchronize enable/disable and injection
- Every time injection is diabled and enabled, a new EventThread is
created
- mCallback might be nullptr
- ENABLE_VSYNC_INJECTIONS/INJECT_VSYNC should require special
permission
- MessageQueue::setEventThread must be called from the main thread
- MessageQueue::setEventThread does not handle EventThread switch
well
Bug: 65483324
Test: manual
Merged-In: I7d7b98d1f57afc64af0f2065a9bc7c8ad004ca9f
Change-Id: I7d7b98d1f57afc64af0f2065a9bc7c8ad004ca9f
(cherry picked from commit 6200eacdc927776483d775562db11cce284cc7e0)
|
|
Change-Id: I6f114a47469ab69f46bf9d9b7c1429294bb80ec2
|
|
into oc-mr1-release
Change-Id: If407b5d78299ba0be9410de4546042986fd65758
|
|
On devices that support wide color rendering and color management,
add a new setting to disable color management ("saturated" color
mode). To disable color management, the framework can set a persistent
property. Color management can be also toggled by using a Binder
transaction. Finally this change adds a new Binder query so Settings
can easily check whether the device supports wide color rendering.
Bug: 68159303
Test: manual (adb shell + apps)
Change-Id: If74d9b0273bc04f4a3d11e63fe2ec96451fbcc2e
(cherry picked from commit 54f154a28284eabb52ade2689d4a9f8fa190163b)
|
|
Change-Id: I625ea121635c45f347aa3498eb7aa6c818e5a33f
|
|
Change-Id: Ia1a538a97249d77b25b1f1568df514547c0bcd5f
|
|
Bug: 65455724
Test: make -j30
Change-Id: I03a22e10d92ea53bb2e1631e4203a186e42fa265
|
|
This reverts commit 05cd77c494aa7042fca7978e1b934855598b765e.
Bug: 65455724
Test: make -j30
Change-Id: Id531101cc35b661f02291eed0c044e96f5a91a12
|
|
This is the proper fix for the revert in ag/3048738.
Bug: 65455724
Test: lunch full-eng && make -j30
Change-Id: I88d37fca2d1f71a46595dd74b5fd6749fa4b477d
|
|
This broke full-eng / docs / m_e_arm-eng builds.
Test: lunch full-eng && m-j8
Change-Id: I79b0176738e4de35cca25e9618e64aa2bd4c4316
|
|
Change-Id: I8be8e1ad05e7445a5c03a3f6009b5e1e30171a59
|
|
This CLs reduces BufferHub CPU consumption by adding asynchronous
state transition so that out-of-process VR composition can run on 2016
pixel devices smoothly. In addition, this CL addresses a couple corner
cases in the existing bufferhub logic, which fixes various blackscreen
issues.
1/ Tracks buffer transition states (gained, posted, acquired, released)
from the client side via atomic shared memory and adds
PostAsync/AcquireAsync/ReleaseAsync/GainAsync with metadata and
fence support.
2/ Adds dequeue order guarantee for buffers enqueued with
dvrWriteBufferQueuePostBuffer.
3/ Synchronous BuffeHub operations are still supported.
4/ Bump up the bufferhubd's soft limit of open file descriptor.
5/ Handle orphaned consumer in acquired state. This is a corner case
that consumer process goes aways (most likely due to a crash) leaving
buffer stuck in acquired state with inconsistent buffer state.
6/ Fixes a race condition for released buffer to be Gain'ed and
Acquire'd when a new consumer is created in released state.
7/ Improve silent consumer queue efficiency: Silent queues no longer
import buffers or receive signals about new buffers and they are
limited to only spawning other consumers and notifications about
producers hanging up.
8/ Modify PDX/UDS channel event signaling to work around epoll
behavior. PDX UDS uses a combination of an eventfd and an epoll set
to simulate the original PDX transport channel events. An odd
behavior discovered in the kernel implementation of epoll was found
that causes the epoll fd to "unsignal" itself whenever epoll_wait()
is called on it, regardless of whether it should still be
pending. This breaks the edge triggerd behavior in nested epoll sets
that channel events depend on. Since this is unlikely to ever be
fixed in the kernel we work around the behavior by using the epoll
set only as a logical OR of two eventfds and never calling
epoll_wait() on it. When polling is required we use regluar poll()
with the eventfds and data fd to avoid the bad behavior in
epoll_wait().
9/ Keep reading data after PDX hangup signal. UDS will signal hangup
when the other end of the socket closes. However, data could still be
in the kerenl buffer and should be consumed. Fix an issue where the
service misses an impulse sent right before the socket is closed.
Bug: 65455724
Bug: 65458354
Bug: 65458312
Bug: 64027135
Bug: 67424527
Test: libpdx_uds_tests
bufferhub_tests
buffer_hub_queue-test
buffer_hub_queue_producer-test
dvr_api-test
Change-Id: Id07db1f206ccf4e06f7ee3c671193334408971ca
|
|
Change-Id: I860ab87bb8fafc7accdc5600e52929f8df68f075
|
|
Change-Id: I93cf952e3df19205d63b3d3bd4fccc22cd262432
|
|
The callback functions are set nullptr in ComposerClient::~ComposerClient()
./composer/2.1/default/ComposerClient.cpp:160: mHal.enableCallback(false)
However, the callbacks are still used in hwc2on1adaptor, it will cause segment fault.
Bug: 64650599
Test: adb shell stop
Change-Id: I92e6a6b42418e987a7ead041f2d95c194b6a16e8
Signed-off-by: Randy Xu <randy.xu@intel.com>
Signed-off-by: Qiming Shi <qiming.shi@intel.com>
Signed-off-by: Yong Yao <yong.yao@intel.com>
Signed-off-by: Gaurav Sarode <sgaurav@google.com>
|
|
Change-Id: Iabc1c91c428511b1f337ef6e548dc69df13ebb02
|
|
|
|
4371241 snap-temp-L10900000107789672
Change-Id: I4a64d37aab8dde4ad6abc1bc37a2477683696a39
|
|
|
|
367109 snap-temp-L18300000107415568
Change-Id: Iedb5b2ab04d4740b203022eb17cfe693dcfe6875
|
|
into oc-mr1-dev
|
|
If we were unlucky with the timing when switching to vr flinger we would
sometimes deadlock. The vr dispatch thread would request the display
from surface flinger, locking mStateLock in the process. mStateLock was
being held by the surface flinger main thread, which was processing a
previous request to switch to vr flinger. The main thread was trying to
connect to the vr hardware composer service, which sent a request to the
vr dispatch thread as part of its initialization, leading to the
deadlock.
The deadlock is easily fixed by posting a message to request the vr
flinger switch to the surface flinger main thread, instead of doing it
on the vr dispatch thread.
Bug: 66916578
Test: Confirmed I can still get into/out of vr flinger on
Marlin. There's no longer code to acquire mStateLock in the vr dispatch
thread, so the deadlock is no longer possible.
Change-Id: I3de5476f698ed798f6b9afe927cc733f0f38c56e
|
|
HWC supports caching buffers for layers using "slot" assignments.
Use this in VrFlinger to avoid importing a buffer handle every
frame. The avoids periodic stalls we observe in the ion driver
when mapping a buffer into the HWC address space.
Bug: 66459419
Test: Observe systraces no longer have MapBuffer in HWC in steady
state; system does not drop frames.
Change-Id: Iba4161b33561322bfbccbfafe600b432a6fa7c44
|
|
Discovered that FP16 and 1010102 may not be supported
for Swapchain. Since we don't have a query mechanism
defined, limit P3 to 8888 which must be supported.
Bug: 66706404
Test: adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity \
-e cmdLine '"deqp --deqp-case=dEQP-VK.wsi.android.colorspace \
--deqp-log-filename=/sdcard/dEQP-Log.qpa"'
Change-Id: If537c631cd40610f6a62c437f8a7aff70f742fff
|
|
4365318 snap-temp-L33600000106883904
Change-Id: I085cc802f1140f72f3eb80d4cbd0d46722ec24e1
|
|
Can verify using this command:
adb shell dumpsys package | grep picture_in_picture
Bug: 65602088
Test: manual
Change-Id: I0e91cb63ce9d4b3ae059afc91d76a36ffc6a0a53
|
|
352002 snap-temp-L88700000105039240
Change-Id: I7b9499f10f42b6f860c54192535f3619a4618d1d
|
|
4351869 snap-temp-L93800000104806132
Change-Id: I1530ca75a479667c9ab39178deaa0e6a15df84ed
|
|
unchanged" into oc-mr1-dev
|
|
|
|
The function setVisibleRegions is always called as part of composition,
shouldn't mark geometry changed if there are no changes in the visible
regions.
Bug: 65019874
Test: run cts -m CtsViewTestCases -t android.view.cts.DisplayRefreshRateTest#testRefreshRate
Change-Id: I3f93431002fc4b691c799f4ae91aa1488849e4a6
|
|
oc-mr1-dev
|
|
Without this, PIP will break a bunch of apps since its frame fills the
whole screen, even though the application is restricted to its
stackbounds (which are the size of the touch region, not the frame
region).
Bug: 65606046
Test: None
Change-Id: Id7035dace30db37c5a58c66339d0749550a362e5
|
|
add getInstallerForPackage() and getVersionCodeForPackage()
to support native media.metrics needs.
Bug: 65027506
Test: watch logs for various package combinations
Change-Id: I6f3c551e8f547ab4151ef2400db4e100a6f53abf
|
|
We see two sources of scheduler jank when waiting for VSYNC:
- A kernfs issue that wakes up threads using a normal priority
work queue that may be delayed or have other work on it.
- The VSYNC callback from HWC is handled by a normal priority
HwBinder thread that may be delayed by other work.
Change the VrFlinger frame post thread to use an absolute timer-
based dead reckoning loop. VSYNC timestamps from the display
driver are reliable, even if the delivery of the value takes time.
Predict the VSYNC time into the future based on the last known
VSYNC time. If we see that VSYNC has not been signaled by the time
we need to post a frame to HWC we assume that the driver and/or
HWC was delayed so much that the previous frame is still pending
and skip the upcoming frame to avoid double stuffing the driver.
Bug: 65064949
Test: Extensive system tests and systraces. See bug for details.
Change-Id: Iae6c4173b8eac1d179adc3fc8004d3d475b3f156
|
|
4343541 snap-temp-L73700000103533431
Change-Id: If3104e7d71eaa75c0b93177ea76076626a7b09bf
|
|
|
|
This reverts commit 864c07077b0283ecf9bd36a0381951a19ec8c3df.
No special behavior for tests.
Reason for revert: b/65603915
Bug: 64776708
Change-Id: Ib64d4f6ef5ea59afa1d3c408c792685a3d025c0a
|