This reverts commit d8220c2050.
Reason for revert: Fix available for deadlocks.
Bug: 113122541
Bug: 134244752
Merged-In: Ib65214598837289bd39dbf040b56ab7835f893ba
Change-Id: Ia90bf2c72ef686e80800d113d03548e0efcadb66
(cherry picked from commit a84d9fa572)
This is still sent in an intent.
Bug: 131764329
Fixes: 131764329
Merged-In: I56c86b0c1912064d5a642991df32d2cefb6a8d5b
Change-Id: I64b9d632be97dc51e6085162371bb8c19f410258
(cherry picked from commit e546cb0bd16b7359feeb3c46ba52e64cf91ae4d3)
To determine if the CPS can get/send messages. Apparently
the IBinder can be cached in ActivityManager and onBind() is not
always called when a service is connected the second time.
Test: manual; ensure a service recieves an onsubscribe for an
active rule post requestUnbind/requestRebind
Fixes: 62584038
Change-Id: Iffe37242509f3bf26e609e6b423f3928c00156ad
(cherry picked from commit 265d093cd9)
Before this CL, the magnifier could deadlock when the following
happened:
1. the renderer is asked to draw (and a frame callback is provided)
2. a #dismiss() happens on the UI thread. This acquires mDestroyLock
(previously line 309)
3. InternalPopupWindow#destroy() is called, and this calls
mRenderer.destroy(). This attempts to destroy the renderer on the UI
thread, however the UI thread will wait until the pending frame callback
corresponding to step 1 is executed on the render thread.
4. The frame callback starts executing on the render thread, and tries
to acquire mDestroyLock (previously line 1093). However, this is held by
the UI thread, so a deadlock happens.
This CL completely removes mDestroyLock, relying on the existing
synchronization between the UI and render threads described in step 3.
Bug: 134584742
Test: manual testing
Change-Id: Ia4c75b5b997e0ed94d5a3814dd4507a8fffa124d
Annotates InputMethodSystemProperty#MULTI_CLIENT_IME_ENABLED as @TestApi
to let cts can verify if multi-client IME enabled.
Bug: 135217809
Test: build and passes
Change-Id: Id7b4dceb2dbfaf3d7ed1084957dd14b04cad0cdf
Add 450dpi as a supported screen density.
This change follows up below change Id : Iac673eae2d82c27d96e279c076454af2f5933208
Originally 600dpi was added to support sw384 with WQHD resolution,
though it was lack of for the cases when resolution is FHD resolution. (In case of other resolutions, there already exist 300 and 200 for HD and WVGA resolutions).
Bug: 78283907
Test: run android.dpi.cts.ConfigurationTest#testScreenConfiguration and android.app.cts.ActivityManagerMemoryClassTest#testGetMemoryClass
(cherry picked from commit 13ca0450ede3eedf7d34bbd0b69525cb6ebc63f1)
Change-Id: Ide0baba183c7dea962610d16f18fecbd0dc62567
As it was in P. There are no public APIs created, hence there is no
better, _public_, alternative.
Fixes: 135282729
Test: none
Change-Id: I199cfcc125f948b983eb55a199abf673cc58b7e1
Added Tron logging to StatusBarNotification.getLogMaker() so it will
be present in most logs about the notification.
Change-Id: I720706d37c663f2018bdfe2153ad180970166c90
Test: atest android.service.notification.StatusBarNotificationTest
Bug: 135180518
* changes:
Remove recalibrate notification when user enrolls
getFaceDaemon on FaceService's own handler
Return empty string when invalid error codes are received
Test: drag accross pattern
Test: start dragging from edges
Test: start drawing, drag outside the bounds
Test: repeat on small and large device
Fixes: 132687980
Change-Id: Idab9279dd7cb002cbd43aab0ce1d48f265d39f04
Previously, there's only one Game Driver existed in the system, so we process
sphal libraries in GPU service to save the launch time for loading Game Driver.
Now we need to support a separate prerelease driver, so we have to move the
processing back to app launch time.
Bug: 134881329
Test: Manual test with prerelease driver and Settings UI.
Change-Id: Ic1bb412a6a026c68f55243c906bd56fe1fee44c3
When starting a new batteystats history file, before inserting a new
CMD_CURRENT_TIME HistoryItem at beginning of the history
buffer, make a copy of the current HistoryItem. Otherwise the current
HistoryItem could be overriden by the CMD_CURRENT_TIME and we lose
a HistoryItem.
In b/130083227, the longwake start event happends before opening the new
history file, after CMD_CURRENT_TIME event, the longwake finish event
is missing. The fix is to make a copy of current HistoryItem before
adding CMD_CURRENT_TIME event.
Change-Id: I5048f98b6b47f54336fb01e354fb5a6284c84b43
Fix: 130083227
Test: b/130083227 can be reproduced by createFakeHistoryEvents() call,
missing longwake finish event can be seen after "TIME:" record. With the
fix, no more missing longwake finish event after "TIME:" record.
“adb shell dumpsys batterystats --history-create-events 50000” to
create enough events to start new history files,
“adb shell dumpsys batterystats --history” to observe all history records.
