Adds a post fork hook for System Server that is used to enable JIT.
Bug: 62356545
Bug: 66095511
Test: device boots, no permission errors
Change-Id: I963e8c4903fb20fd0b5a207fdc6746035b69c569
When using xt_qtaguid to count per uid stats,
NetworkStatsService needs to adjust the 464xlat traffic since
iptables module would double count for ipv4 and ipv6 packet.
But for eBPF, the per uid stats is collected in a different
hook, so the adjustment on root uid would only be needed in tx
direction.
Bug: 112226716
Test: 1. Make ipv4 traffic in ipv6-only network and check data
usage.
2. Make ipv4 traffic in a client which connect to
ipv6-only hotspot.
3. runtest frameworks-net
4. cts-tradefed run cts -m CtsNetTestCases -t \
android.net.cts.TrafficStatsTest
5. cts-tradefed run cts -m CtsUsageStatsTestCases
Change-Id: Ic9a84f5446eddc943c255d5f3b89dad171f53cac
Reads all thread CPU usage for the current process. This traverses
"/proc/self/task/*/time_in_state" to gather the thread ID and CPU usage
of each child thread. Process name, thread name, and UID are also read from
"/proc" for interpretable data.
Bug: 111534779
Test: Unit test in CpuThreadProcReaderTest
Change-Id: I6c71dde1dfcc9bbb87d95baf0886f9da7a782299
1. There used to be double offset from the origin.
This is because we used to (in NYC) make the surface position to display
origin and draw content with a offset in the surface. However we lately
let the surface position be inherited from task surface position, so
there will be an offset from surface position and an offset from drawing
content in that surface.
To fix the bug I removed the offset in drawing content. That offset is
provided by WindowState#getBackdropFrame() so it just solved the issue
by moving frame to the origin.
2. Window quickly jumps when user starts drag resizing a window.
The reason is out of synchronization between surface insets change and
graphical buffer update. When user is drag resizing, we suppress window
shadow to save some graphical resources, which will consequently change
surface insets. Change in surface insets will cause the surface being
repositioned to reflect the new surface insets because window frame
doesn't change. However the content is still drawn at old location with
old surface insets for the first a few frames, so the content jumps to a
wrong location for a split second. This also happens when users stop
drag resizing.
I kept the old surface insets when user is resizing so there won't be
surface reposition at the beginning and end of drag resizing, but still
suppress the shadow by adjusting the elevation of DecorView.
Also fixed a synchronization issue we found in BackdropFrameRenderer,
and cleaned up code in it.
Bug: 113254346
Test: Manual tests show drag resizing for both freeform and split screen
works.
Change-Id: I42349f88f14af35fac7c65e784462b5f2e1a71c7
Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Merged-In: I719b5c94e5b1f4fa562dd5d655953422958ad37e
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
(cherry picked from commit 8c854f86a4)
Currently IInputMethodSession#finishInput() is called nowhere.
Let's remove this IPC method exposed from InputMethodService to IME
client for now until we fully understand what is the right approach on
how and when InputMethodService#finishInput() should be called.
Note that we cannot simply remove InputMethodSession#finishInput()
because it is already published as a public API. In Bug 9216494
hopefully we can also discuss whether InputMethodSession#finishInput()
should be deprecated or can be reused for some actual use cases.
Bug: 9216494
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I9e378111c9df40cb6821583d1e6ae8f9fe38f2b1
This is the last step to split InputMethodClient into multiple
classes.
Now that all the integer constants for UnbindReason are defined inside
UnbindReason, "UNBIND_REASON_" prefix is just redundant.
This is a mechanical refactoring. There should be no user-visible
behavior change.
Fix: 118040692
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/com/android/internal/inputmethod/UnbindReason.java
Change-Id: Iafce68b614dd85392d06af8726525a18b014dba0
This is another step to split InputMethodClient into multiple classes.
With this CL, InputMethodClient is completely removed.
This is a mechanical refactoring. There should be no user-visible
behavior change.
Bug: 118040692
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/com/android/internal/inputmethod/UnbindReason.java
Change-Id: I3b96a351413025338776f6c87cbaa8cf28c3a44f
This is another step to split InputMethodClient into multiple classes.
Now that all the integer constants for StartInputReason are defined
inside StartInputReason, "START_INPUT_REASON_" prefix is just
redundant.
This is a mechanical refactoring. There should be no user-visible
behavior change.
Bug: 118040692
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/com/android/internal/inputmethod/StartInputReason.java
Change-Id: Ic2476c3d588211e6c61180cde7df4c6b79039ede
This is another step to split InputMethodClient into multiple classes.
With this CL, StartInputReason will be extracted from
InputMethodClient.java into a dedicated file.
This is a mechanical refactoring. There should be no user-visible
behavior change.
Bug: 118040692
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/com/android/internal/inputmethod/StartInputReason.java
Change-Id: I0cc2588c97239a004720f74cbf356bda4c735d53
This is the first step to split InputMethodClient into multiple
classes.
With this CL, utility methods to convert integer constants to String
messages will be moved from InputMethodClient to InputMethodDebug,
which I believe is a bit more descriptive class name than
InputMethodClient.
This is a mechanical refactoring. There should be no user-visible
behavior change.
Bug: 118040692
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/com/android/internal/inputmethod/InputMethodDebug.java
Change-Id: I83f4795e95bc2e8ae325ad6e28d3a42317414e8d
Based on recent measurements, storage pools of small objects are
generally not useful.
We ran into this because growing ArrayDeques are potentially very
unfriendly towards a generational GC, and racing recycle calls
can cause it it grow beyond MAX_POOL_SIZE. This isn't a big deal,
but there's no reason we should even be thinking about it.
Test: Build and boot AOSP
Change-Id: Icbda95e472e206c54f141129cc36ddc6d163b095
Bug: None
Test: I solemnly swear I tested this conflict resolution.
Change-Id: Icf172daeb848f746c81acd25a4406decc00ed875
Merged-In: Ib32dafbd3c6fcbe11186dc8ecab6b09c9b734067
By requiring an explicit default setting, it eliminates all ambiguous
states where a disambiguation would normally be shown. With this
change in place, at no point should a disambiguation be shown.
Test: manual
Bug: 111603898
Change-Id: Ib32dafbd3c6fcbe11186dc8ecab6b09c9b734067
Currently InputMethodManagerService#finishInput() does nothing. Until
we fully understand what is the right approach on how and when
InputMethodService#finishInput() (Bug 9216494), let's remove this
unnecessary IPC from the IME client to InputMethodManagerService.
Bug: 9216494
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Change-Id: I614050d20f4a7d9611dc0502e55e6ca3458a836e
By requiring an explicit default setting, it eliminates all ambiguous
states where a disambiguation would normally be shown. With this
change in place, at no point should a disambiguation be shown.
Test: manual
Bug: 111603898
Change-Id: Ib32dafbd3c6fcbe11186dc8ecab6b09c9b734067
InputMethodManager has been a per-process singleton object. In order
to support behavior changes for multi-display support in Android Q,
however, InputMethodManager now needs to be per-display objects.
With this CL, context.getSystemService(InputMethodManager.class) will
start returning per-display InputMethodManager (IMM) instance.
Why?
There are two major reasons.
1. To support per-display focused window.
2. To support more simplified API for multi-session IME.
Currently per-process InputMethodManager instance directly receives
callback from ViewRootImpl upon windowFocusChanged, then it keeps
track of which Window is focused by storing its root view into
InputMethodManager#mCurRootView.
This design assumes that (within the same process) at most one Window
can have window focus, which is no longer true once we start
supporting per-display focused window (Bug 111361570).
Why we need to do this to support per-display focused window:
For traditional non multi-session IME cases (e.g. apps that use
Virtual Display APIs on phones), internal state of IMM can be easily
messed up once the system starts sending per-display
windowFocusChanged events to the same process, because IMM still
doesn't know that now each display has focused window. It is hard to
precisely predict what kind of issues we would see simply because such
a use case is most likely not expected in the original design.
Why we need to do this for multi-session IME:
For multi-session IME scenarios, in addition to the above concern in
InputMethodManager, the current design allows at most one IME session
per process. This means that if a process X is showing Activities to 3
different displays, only one Activity can interact with the
multi-session IME at the same time. If we do not change the current
design, the only way to work around is to ask app developers to
explicitly use different processes for each Activity, which may
require a lot of work (e.g. SharedPreference is not optimized for
multi-process use cases). This would also make multi-session IME
development complicated because the IME cannot know on which display
the IME is interacting until startInputOrWindowGainedFocus() is
actually called, and needs to do all the preparation and cleanup tasks
whenever startInputOrWindowGainedFocus() is called for a different
display than it's currently interacting with.
Alternative solutions considered:
Another possible approach is to update InputMethodManager singleton to
be able to maintain multiple mCurRootView and mServedView for each
display. This approach was abandoned because those fields and methods
are already marked as @UnsupportedAppUsage. I concluded that touching
@UnsupportedAppUsage things would have bigger compatibility risks than
per-display instance model.
Implementation note:
* Public APIs in IMM that take View instance as the first parameter
will verify whether the given View and IMM are associated with the
same display ID or not. If there is a display ID mismatch, such an
API call will be automatically forwarded to the correct IMM instance
IMM with a clear warning in logcat which tells that app developers
should use the correct IMM instance to avoid unnecessary performance
overhead.
* As a general rule, system server process cannot trust display ID
reported from applications. In order to enable IMMS to verify the
reported display ID, this CL also exposes display ID verification
logic from WMS to other system components via WindowManagerInternal.
* isInputMethodClientFocus() in WindowManagerService (WMS) is updated
to use top-focused-display to determine whether a given IME client
has IME focus or not. This is now necessary because with a recent
change [1] each display can have focused window. The previous logic
to check all the displays that belong to the given pid/uid [2] no
longer makes sense.
* Currently per-display InputMethodManager instances will not be
garbage collected because InputMethodManager#sInstanceMap keeps
holding strong references to them. Freeing those instances is
technically possible, but we need to be careful because multiple
processes (app, system, IME) are involved and at least system
process has a strict verification logic that lets the calling
process crash with SecurityException. We need to carefully
implement such a cleanup logic to avoid random process crash due to
race condition. Bug 116699479 will take care of this task.
Also to make sure that the performance regression (Bug 117434607) we
observed after my initial attempt [3] no longer exists, here are the
benchmark results with and without this CL.
testExpandNotificationsLatency on taimen-userdebug
without this CL:
results=[55, 46, 61, 67, 50, 48, 57, 50, 55, 63]
min:46.0, max:67.0, avg:55.2, median:55.0, std_dev:6.539
with this CL:
results=[45, 55, 58, 57, 47, 60, 59, 60, 56, 53]
min:45.0, max:60.0, avg:55.0, median:56.5, std_dev:4.980
[1]: I776cabaeaf41ff4240f504fb1430d3e40892023d
1e5b10a217
[2]: I8da315936caebdc8b2c16cff4e24192c06743251
90120a8b5b
[3]: I7242e765426353672823fcc8277f20ac361930d7
c53d78e992
Bug: 111364446
Fix: 115893206
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Test: No perf regression in LatencyTests#testExpandNotificationsLatency()
Change-Id: I78ad7cccb9586474c83f7e2f90c0bcabb221c47b
ContextImpl has an internal rule that when ContextImpl#mDisplay is
null the Context is associated with the default display. The problem
is that, as discussed in Bug 117709581, when ContextImpl#mDisplay is
null ContextImpl#getDisplay() tries to get some non-null Display
object by making an IPC to the system server, which is redundant when
the display ID is the only thing that the caller wants to know.
By having an @hide method Context.getDisplayId(), we can ensure that
display ID can be obtained without any IPC. This enables us to
re-submit my CL [1] that aimed to instantiate InputMethodManager (IMM)
for each display but then got reverted due to a performance regression
(Bug 117434607).
There should be no developer-observable behavior change.
[1]: I7242e765426353672823fcc8277f20ac361930d7
c53d78e992
Fix: 117712745
Test: atest FrameworksCoreTests:android.content.ContextTest
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/tests/coretests/src/android/content/ContextTest.java
Change-Id: I2534530a5ce90e2620c5039d793a6454a0a1e154
The suspending app has more context about why a particular app was
suspended by the user, but we do not want to delegate the interception
of the suspended activity out of the system.
Hence allowing it further customizations to the dialog to make
it clearer.
Test: atest com.android.server.pm.SuspendDialogInfoTest \
com.android.server.pm.SuspendPackagesTest \
com.android.server.pm.PackageUserStateTest \
com.android.server.pm.PackageManagerSettingsTests \
com.android.server.am.ActivityStartInterceptorTest
atest GtsSuspendAppsPermissionTestCases GtsSuspendAppsTestCases
Bug: 112486945
Bug: 113150060
Change-Id: If9f4d14587a2b75bb572e7984a90e300a2c72d16
