There are cases where dumping Java traces times out and then later tries
to write to a closed pipe, causing incidentd to crash. This introduces a
handler for the SIGPIPE signal so it doesn't crash due to a closed pipe.
Bug: 111729299
Test: lower section timeout to 5 seconds and make sure incident service
doesn't crash
Change-Id: I868aba1ae21a50ae76977e0e09e782cf94198473
(cherry picked from commit 5b763c13472effa7df25cc53a44d5bdae9392410)
The current wording seems to suggest allocating an infinite number of
fields, which is not future-proof.
Bug: 72866543
Test: N/A
Change-Id: I88732ea8695521a39f20524348547cfe50cbf776
Java trace dumps can take significantly longer than 30 seconds. Testing
suggests that 2 minutes should be ample time.
Bug: 111729299
Test: 'adb shell incident' and ensure the section doesn't time out.
Change-Id: I35e09fc1ca608122a1a352985ea3741f6ea0a344
(cherry picked from commit 0f7167947a6e3180da0964ec6187f9f01642fb6d)
Previously, fdopen was being called on a file descriptor that was owned
by a unique_fd without releasing. This leads to a double close, since
both fclose and the unique_fd destructor will try to close the fd.
Bug: http://b/113880863
Test: treehugger
Change-Id: I6f6f48d304861b5e4d7efee0d3ad0e30178a95a4
The page block order is an independent variable from the free
page order table in the kernel, so the parser should not error
out if they do not match.
Bug: 110559361
Test: incident_helper_test
Change-Id: I08ad9c8f9b29cc15b80a89929f3a1fb6886852e6
Merged-In: I08ad9c8f9b29cc15b80a89929f3a1fb6886852e6
(cherry picked from commit 3abb43991685d0ba40e70dd5f81abe044f65b891)
_exit was being used instead of return in order to
work around a static destructor issue that has been
fixed.
Bug: 77934844
Test: screencap (and it doesn't crash)
Change-Id: I5dc25b0af5099993a94705ac9c7b439e68432824
Exemption given to a sync request made by a foreground app (including
PROCESS_STATE_IMPORTANT_FOREGROUND).
At the schedule time, we promote the sync adapter app for a higher bucket:
- If the device is not dozing (so the sync will start right away)
promote to ACTIVE for 1 hour.
- If the device is dozing (so the sync *won't* start right away),
promote to WORKING_SET for 4 hours, so it'll get a higher chance to be started once the
device comes out of doze.
- When the sync actually starts, we promote the sync adapter app to ACTIVE for 10 minutes,
so it can schedule and start more syncs without getting throttled, even when the first
operation was canceled and now we're retrying.
Test: atest cts/tests/tests/syncmanager/
Test: Manual test with "requestsync -f" and "am set-standby-bucket", while checking
"dumpsys usagestats"
Test: settings put global app_idle_constants \
exempted_sync_scheduled_nd_duration=1,exempted_sync_scheduled_d_duration=2,exempted_sync_start_duration=3
and check "dumpsys usagestats" and make sure the constants are properly updated.
Fixes: 72443754
Change-Id: I233d8e4be85769150830bac798abc04810f4cc7b
MediaSession#getCurrentControllerInfo() can have more fine grained
differentiation for multiple MediaController in a package/process
Bug: 79728675
Test: Run CtsMediaTestCases
Change-Id: I81e94736e795ee5e7fbd28cb6cd834cc3a3b8f98
Statsd hashes (using its own hashing function) raw strings to reduce the
upload data size when there are duplicate strings in the report. And in cloud,
the clearcut translator would backfill the strings.
In a few droidfood users, we find the translator was unable to do that. While
debugging the root cause, we first decided to provide an option to disable
the hashing from the cloud.
Test: statsd unit test, CTS test, tested manually
BUG: b/79943763
Change-Id: If0359c8cf3f3cf83a2938db9ebf95ea7906f0b0c
Pulled value metrics with conditions had a subtle bug that caused
us to leave the condition on even if it should've been false.
Bug: 79778783
Test: Added unit-test and verified on marlin-eng.
Change-Id: I31f34791118319b3471f7a6ea8a024e2d511cfe7
See build/soong/README.md for more information.
Test: m libframeworks_coretests_jni
Test: m FrameworkCoreTests_install
Test: m libshim_jni
Test: m CtsShimPrivUpgrade
Test: m libfilterfw
Test: m PMTest_Java_dual
Test: m libdefcontainer_jni
Test: m libperftestscore_jni
Test: m libpmtest32 libpmtest64
Test: m libprintspooler_jni
Test: m libsmartcamera_jni
Test: m idmap
Test: m libdrmframework_jni
Test: m libdvr_loader com.google.vr.platform com.google.vr.platform.xml
Test: m libfilterpack_imageproc libfilterpack_base
Test: m libwebviewchromium_loader
Test: m shared_mem_test
Test: m test-touchlag
Change-Id: I868561dd237fa28647896d59049ab9260373ada1
Right now in value metric, if a later pull produces a smaller number
than the previous one, we use absolute value of the current value.
This is not correct for some atoms as listed in the CL, which should
just take 0.
For some other atoms, this is unexpected error and should just dump
stale data.
Test: manual test
Bug: 79265262
Change-Id: I59fbfd96cbb57be22cd8d21cb57a7c60ca6856ee
Reports written to disk don't contain the strings used, which will
make this report unusable if there are strings that don't show up
again. We should always include the strings, so this option is
removed entirely.
Also, we hard-coded the wrong number of fields when pulling
ModemActivityInfo. There are actually 10 fields, not 6.
Bug: 79601503
Test: Tested unit-tests pass on marlin-eng.
Change-Id: I6834b096ced77418a9cc2ddd79b08d1c9c447fae
