This is a preparation to remove the dependency on IInputMethodClient
from WindowManagerService.
What inputMethodClientHasFocus(IInputMethodClient) is currently doing
is basically equivalent to comparing PID (and UID), because
InputMethodManager is a per-process instance and comparing two
IInputMethodClient Binder proxies is no more or less than comparing
PID (and UID pair). We can just change its method signature to
achieve the same behavior by taking a PID/UID pair instead of taking
IInputMethodClient.
Note that we can later add display ID to this method to support
multi-display scenario.
This CL also renames inputMethodClientHasFocus() to
isInputMethodClientFocus() for better consistency with other methods.
There should be no observable behavior difference in this CL anyway.
Bug: 115993358
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I444077b1e4af4033f67ab72c181fac85b601e08a
This reverts commit fa894222e6.
Reason for revert: Resubmitting in a topic with the fix for the bug that required the revert
Change-Id: Ia70f966c8757f340ceb14f187e9726c12457403a
This is a preparation to allow InputMethodManager to have per-display
instances rather than the current per-process singleton instance.
When I introduced InputMethodPrivilegedOperationsRegistry [1], there
was an assumption that InputMethodManager was a per-process global
singleton object.
Now that we are going to break up that global per-process instance
into multiple per-display instances, having multiple
InputMethodPrivilegedOperationsRegistry instances probably does not
make much sense, because it would likely to increases the risk of
compability issues in existing IMEs. Although IME developers soon
really need to use the right Context to obtain the right instance of
InputMethodManager anyway, unnecessarily introducing compatibility
pitfalls that can be avoided in the Framework side is not my
intention.
With this CL, following 9 methods can continue to work no matter
whether InputMethodManager is a per-process singleton or not.
This is fine because those APIs had been mistakenly exposed in
InputMethodManager and already deprecated in favor of newly added ones
in InputMethodService.
* InputMethodManager.hideSoftInputFromInputMethod
* InputMethodManager.hideStatusIcon
* InputMethodManager.setInputMethod
* InputMethodManager.setInputMethodAndSubtype
* InputMethodManager.shouldOfferSwitchingToNextInputMethod
* InputMethodManager.showSoftInputFromInputMethod
* InputMethodManager.showStatusIcon
* InputMethodManager.switchToLastInputMethod
* InputMethodManager.switchToNextInputMethod
[1]: If762714b2003fa6477e1318110f63e13968c1d7e
eec552e9e9
Bug: 115893206
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I4a61470f06ffac5f7a512536f8431489db0108f4
When statsd pulls data from StatsCompanionService, the data is put into
log_msg format on java side and expanded into LogEvent on cpp side.
There is a lot of dependency on log_msg and liblog to add new types.
There is pending bug to rewrite thta part of the code in statsd to
completely rid the legacy of logd and liblog. But that may not happen
soon.
Now we can support new storage type.
Also no need to specify number of fields in StatsLogEventWrapper cstr,
which is a source of bug in P.
Bug: 115775035
Test: manual test and cts test
Change-Id: Id1f0b033885da6f3bcebe043968061821db48f35
KernelCpuProcReader used FileChannel to dump bytes into a large enough
ByteBuffer. However, FileChannel#read stops as soon as there is nothing
left to read. Since the kernel may not deliver all parts of a proc file
simultaneously, previous read mechanism would possibly read only a
portion of the proc file. The impact is that KernelUidCpuFreqTimeReader
gets an incomplete UID list.
New mechanism uses a loop to turn non-blocking FileChannel#read into a
blocking operation. It does not return until hitting EOF. The reason
not to use Files#readAllBytes is that we want to reuse the byte[].
Bug: 111805985
Test: atest KernelCpuProcReaderTest
Test: compared KernelCpuProcReader#readBytes against Files#readAllBytes
locally
Change-Id: If0d2b6742489632e22c8fec34c627851cda875f2
This API is necessary for identifying the cursor locations.
Bug: 112327179
Test: atest android.graphics.cts.PaintTest
Change-Id: Ief6770bd622a296ae356094fe3ce58e9c4371088
Seen in on devices with work profiles.
- Only bind the the current started user(s)
- Wrap applyEnqueuedAdjustmentFromAssistant with a try/catch
since assistant services cannot recover from it on their own.
Additionally, while debugging this rebindServices hurt my brain,
so I've split it up a bit and added comments and tests.
Test: runtest systemui-notification, device restart and log queries
Bug: 113296846
Change-Id: I19b9044ff87712f9ef5401457217156ea9fb9f1f
