onMessageInvalidate() sets mExpectedPresentTime to a value originating
from the vsync event that scheduled it. If handling of the invalidate
is delayed, this value will be in the past, which is clearly not a
plausible present time. Because of this, queued frames may incorrectly
be ignored as "too early".
This has caused problems in screen-on animations: even though the first
frame is drawn and ready, SurfaceFlinger shows an old frame. This looks
particularly bad with a fade-from-black animation: the old frame flashes
by before the first frame of the animation shows.
Here's an example timeline of how this problem could manifest:
1000 ms INVALIDATE queued with expectedVSyncTimestamp = 1010ms
1013 ms SF calls setPowerMode()
1014 ms SystemUI queues new NotificationShade frame
1255 ms setPowerMode() returns; invalidate can now be handled
1256 ms invalidate runs; mExpectedPresentTime set to 1010ms
1257 ms handlePageFlip() skips NotificationShade frame; "too early"
1259 ms refresh runs, composits prehistoric NotificationShade frame
It's a bit of a race: if SystemUI manages to queue its new frame before
the INVALIDATE message's timestamp, there won't be a problem.
To solve this, let's check that the expected present time is in the
future, and pick the nearest future vsync point if it's not. In order
to not break frame miss detection, mScheduledPresentTime is introduced
and used instead of mExpectedPresentTime for jank calculations.
Fixes: 178415552
Test: manual on Xperia device; flash of old frame is gone
Test: compiles on aosp/redfin
Change-Id: I095f1dd08374fd1d14552cd1af90d95e9718b4dd
Merged-In: I095f1dd08374fd1d14552cd1af90d95e9718b4dd
This is used in production as a means to go between languages
(rust<->C++) in keystore.
Bug: N/A
Test: N/A
Change-Id: I562f7fd15d9b85e065074abf7b80e4d439432730
We have switched panic strategy to abort rather than unwind. This
prevents the previously tested behavior from working correctly.
Bug: 178577888
Test: atest rustBinderSerializationTest
Change-Id: I0ab1ed86ed1264054f43a9655185496d9c8b6328
To enable binder service-name based dumps of services when the same
interface might be registered from multiple different processes.
The getDebugPid command can't be sent instead to specific instances,
since if they are hung, the PID couldn't be retrieved.
For partiy w/ HIDL, this uses the 'list' selinux permission to control
reading debug dumps.
Bug: 175322136
Test: using this info to dump AIDL HALs in ANR
Change-Id: I4bc7c2df5faa6be1cdcc69b2a7fc882293f1d249
The test assert that file size of primary.prof in the
`FS/data/misc/profiles/cur/0/com.android.phone/` should
be greater than 0. This behavior depends on art module,
and it's not always true. Updates the test to assert
the file should exist.
Bug: 178561542
Test: atest dumpstate_smoke_test
Change-Id: I1038c6c10c320cd98fa97f0890fff7f64e29e731
If a device does not have any policy directories under
/sys/devices/system/cpu/cpufreq this would previously lead to the
cputimeinstate subsystem being initialized with an empty set of policy
frequencies. This would lead to integer underflows in various loops
that enumerate the frequencies when subtracting 1 from a maxFreqCount
variable calculated as 0, resulting in us spending a significant amount
of time in these loops, likely leading to an ANR in system_server
since at least the loop in clearUidTimes is executed while holding the
BatteryStatsImpl lock. Fix the problem by skipping the initialization
of cputimeinstate if there are no policy directories.
Bug: 142352330
Bug: 178231152
Change-Id: I2ec1e8de0fe2a40ed100c8f14e6ca3f6d6285b82
This instance is used as the signal for kmem_activity trigger
(See:go/mm-events-design)
Bug: 155928119
Test: adb shell ls /sys/kernel/tracing/instances/mm_events
Change-Id: I4d02fac3969ac837006eaa5396be5bc7797b6b81
If VSyncPredictor gets an invalid timestamp, it might be accepted as
a correct one, and then all the other correct timestamps will become
incorrect for VSyncPredictor leading to rejecting all the correct
timestamps followed by a one off inconsistent vsync.
Bug: 173235499
Bug: 177484301
Test: SF unit tests (+1 new)
Change-Id: I192b917196c727b9a97a0d18bae160467f75722d
Merged-In: I192b917196c727b9a97a0d18bae160467f75722d
Instead of passing the number of active services, pass a bool
that represents if there are clients.
Bug: 176239128
Test: test aidl_lazy_test
Change-Id: I8180547dfe4ebc11d5d7bb3a7306bc79f839d715
Merged-In: I8180547dfe4ebc11d5d7bb3a7306bc79f839d715
This tests cross-language marshaling between C++ and Rust for all
available parcelable types.
Test: atest libbinder_rs-internal_test
Change-Id: I57fae844d58395ee85f0afa4604e1480262f1a4b
Rather than embedding the wire format of parcelable arrays in rust, we
should rely on the NDK implementation to parcel and unparcel arrays of
generic parcelables. This allows the NDK to change the wire protocol
independently of the Rust library.
Test: atest -p frameworks/native/libs/binder/TEST_MAPPING
Bug: 174801709
Change-Id: I52dd35c506e96840f8e765ba53cb7c83f4921536
Android S requires the device to support bpf.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I10c3bf8a3d0a42f9c90eaa578f9f94157cac2151
Merged-In: I10c3bf8a3d0a42f9c90eaa578f9f94157cac2151
The size of gpuservice regressed while adding perfetto trace functions
inside GpuMemTracer for unittests. This change fixes the regression by
moving readPackets into the unittest, thereby removing the need to
include some libraries in gpumemtracer.so
Bug: 175904796
Test: atest gpuservice_unittest:GpuMemTracerTest
Change-Id: Ifaafdbfb24f8c51712276ef7efd645ce43c987f4
Merged-In: Ifaafdbfb24f8c51712276ef7efd645ce43c987f4
This change adds some unittests for the GpuMemTracer module to verify
that the producer indeed works.
Bug: 164194338
Test: atest gpuservice_unittest:GpuMemTracerTest
Change-Id: I9f570567310f23261b43c85ab8cdc3ede8717f09
Merged-In: I9f570567310f23261b43c85ab8cdc3ede8717f09
When the nice platform API description isn't available, we can still
build something here.
Bug: 134795810
Test: N/A
Change-Id: I2b5eb8365c3b6f56e2ba967a21cf304909d147ff
For clarity (a reference to RefBase is omitted here since many of the
details in the platform documentation are irrelevant here, since they
are not exposed).
Bug: 177020658
Test: N/A
Change-Id: I5b33124422243c2eb2517bd5e5325010126a45f3
Bug:146758432
PD#SWPL-39338
Problem:
Dtvkit, no small window displayed in pip mode
Solution:
porting from I82d81ded
For surfaceview of tv sideband, there is no activeBuffer in bufferqueue.
ClientCompostion layer if above it need plug holes for this case.
Verify:
ohm
Change-Id: Id92c3856eb8eb5a14813336f723d30b7a17514b1
Signed-off-by: Tianhua Sun <tianhua.sun@amlogic.com>
The other change in this topic allows the onError
DumpstateListener call to be made asynchronous,
meaning that a blocking binder call will no longer be
made out of system_server.
Bug: 147703592
Test: Manual. Take bugreport, ensure that the death recipient
logic never triggers before the onError/onFinished callback.
Change-Id: Ibb74bf068c4b186f07e19bb076b4ddea69eda768
Because it uses:
- 0.4% of system_server CPU time
- 1% of com.android.bluetooth
- 0.8% of com.android.phone
This call is used to implement
IPCThreadState::blockUntilThreadAvailable, but this API is actually only
used by WatchDog.java, and due to the locking we have in place here, we
have more information than pthread does internally to tell it when a
broadcast would actually be useful.
Future considerations: this API is actually broken in the case of poll
calls or if too many userspace threads manually call joinRpcThreadpool.
We could move the binder part of WatchDog.java into a separate process
and completely remove all of the associated infrastructure. An external
process could call pingBinder (or similar) on different services. This
would have the same effect, but it would use the existing path of
processing a transaction in order to detect deadlocks.
Bug: 168806193
Test: boot, manually check how often this gets called now (only when
the binder threadpool is saturated when this is called, so at most
once/30 seconds given WatchDog's current implementation)
Change-Id: I44f8ff0d8ca2cdf236a9fa3ad1e3a0241663bfcd
In preparation for a broader set of apps using BugreportManager, we
enforce that only the app which started a bugreport is allowed to cancel
it.
Bug: 161393541
Test: atest BugreportManagerTestCases
Test: manual with two apps triggering/cancelling BRs
Change-Id: I10bdc9ff2a5746e2dc1e7d63876219bb34fad3b9
Merged-In: I10bdc9ff2a5746e2dc1e7d63876219bb34fad3b9
(cherry picked from commit 00c2a7563c)
This flushCommands call is no longer required.
Bug: 139697085
Test: ran test repeatedly for 10 minutes
Change-Id: I58fb7e55e6e8b90962377ef165ef5ba5fdcba20a
BC_FREE_BUFFER and ref commands are normally just queued, and not
automatically flushed out to the kernel driver. This usually works fine,
because BC_FREE_BUFFER is typically called from a binder thread (which
flushes when calling back into the kernel), or a thread making regular
binder transactions itself.
But it can happen that a Parcel is destructed from a thread that meets
neither of those requirements; especially Parcels created from Java are
sensitive to this, because if they aren't immediately recycled, they
will instead be garbage collected, and in that case the BC_FREE_BUFFER
will be queued to the FinalizerDaemon thread, which otherwise never
makes or receives any binder calls.
To prevent these commands from getting stuck, flush BC_FREE_BUFFER and
refcount operations automatically from such threads.
Bug: 68604253
Bug: 139697085
Test: boots, binderLibTest
Change-Id: I98109a7046c122db22af0b15a268629284f06663
Calling setupPolling and then handling polled commands has the effect
of never telling the kernel anything, and then then waiting for it to
get back to you. While this type of (non)communication may be common
among some humans, it should not be common among our processes.
So - the general requirement for a flushCommands call by every client of
this call is lifted.
Critically, also, this means that LL-NDK users of the setupPolling
command don't also need a flushCommand. This avoids an extra API. Sure,
it may be useful to have such a command, but whenever it is used in our
tree, it is mostly used as a hack. So, hopefully this delay in adding it
will instead encourage fixes in libbinder which help avoid people
needing to understand binder internals.
Bug: 139697085
Test: use with servicemanager and boot
Change-Id: I45d19bf6b58950f9d91dd6f7dcaa94b8061d3666
