Allow VPN apps to lookup the UID owner of a network connection.
Requires specifying the:
- IP address and port for both the source and destination of a TCP
connection.
- IP address and port for either source and destination or just
source for a UDP connection.
Only TCP and UDP protocols are supported. Only connections for UIDs
that apply to the calling VPN app will be resolved. This is intended
to replace direct app access to /proc/net/{tcp,tcp6,udp,udp6}.
The implementation uses netlink inet_diag sockets[1] to perform
the lookup on TCP sockets as well as UDP sockets when supported
(kernel has CONFIG_INET_UDP_DIAG=y).
[1] http://man7.org/linux/man-pages/man7/sock_diag.7.html
Bug: 9496886
Bug: 109758967
Test: atest HostsideVpnTests
Test: atest InetDiagSocketTest on Taimen with CONFIG_INET_UDP_DIAG
and on Sailfish without CONFIG_INET_UDP_DIAG.
Change-Id: I2bbc7072dd091e2e653dadf6dc05024c04180f34
* changes:
3/n: Add FaceDialogView and "confirmation" plumbing
2/n: Refactor common code from FingerprintDialogView
1/n: Rename FingerprintDialogView to BiometricDialogView
This change adds plumbing from <Biometric>Service to SystemUI for requiring
user confirmation (or not). This change also fixes some layout bugs
that were hard to notice.
Bug: 111461540
Fixes: 113130114
Fixes: 116135579
Test: With confirmation, crypto operation does not work until token
is added to Keystore
Test: Without confirmation, crypto operation works when biometric is
authenticated
Test: BiometricPromptDemo works, UI elements are all correct
Test: Talkback messages are correct
Change-Id: I2c05577699a29c09777cae4db6c7334c1e6bc179
Somehow InputMethodManager#peekInstance() has not been thread-safe.
Although we basically do not care this deprecated method, but let's
just update it for consistency.
Bug: 115891476
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I56bf05f76a7939f004efefdd956776e533bae058
This fixes a minor mistake in the TracingController class usage. The
example previously used a bare `CATEGORIES_WEB_DEVELOPER` instead of
`TracingConfig.CATEGORIES_WEB_DEVELOPER`.
Bug: 116227333
Test: make docs
Change-Id: I648dd0d5e61666e61adb27303c185013bd80b0ea
- Moved CompatModePackages to ActivityTaskManagerService since it is mostly used for activity stuff.
- Moved mHeavyWeightProcess to ActivityTaskManagerService since it is set for activities.
- Set AMS.mBooting and AMS.mBooted as volatile to allow setting from both AM and WM side with hold locks.
- Allow updating of cpu stats, usage stats, and foreground time from WM side.
Bug: 80414790
Test: Existing tests pass.
Change-Id: I48ab55bdd5aacc864cb6a82d19d1a24b7605a5b0
Add ThreadLocalWorkSourceUid and Message.workSourceUid
which will store the UID which caused, directly or
indirectly, the Message to be enqueued.
This was needed because using Binder.getCallingUid() does
not give us enough data since quite a few Binder services
call Binder.clearCallingIdentity() when processing the
call.
Test: UT and manual
Change-Id: I35af3a9ca5193477070990b41ff5d9c52f420069
This is the last step to remove the dependency on IInputMethodClient
from WindowManagerService.
With my previous CL [1], now WindowManagerService (WMS) depends on
IInputMethodClient just because it implements lifecycle management of
IInputMethodClient on behalf of InputMethodManagerService (IMMS).
This CL mechanically moves that responsibility from WMS to IMMS for
better separation of concerns. It is a bit ironic that this CL is
partly undoing my previous CLs [2][3] that removed
IInputMethodManager.addClient() though.
This CL aims to preserve the current observable behavior (e.g. when
InputMethodManager instance is being created) as much as possible.
Most likely there would be no observable behavior difference when seen
from other components.
[1]: I444077b1e4af4033f67ab72c181fac85b601e08a
41f89c3bcc
[2]: I453200fd5847e9a78876affb6a1caec221525e1d
e24ed79edb
[3]: Id91dd600120e4981aa1d9005ce644728968430c9
fffc0e53c6
Fix: 115993358
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I7726c70613ea72d6e78fa5754e9fc840f0a40f11
InputMethodManager#sInstance is a long live static object so we have to
set its field with right value, otherwise any object referenced by it
cannot be gc including potential activity context.
Now InputMethodManager#mCurRootView is set to null in
InputMethodManager#onPreWindowFocus which is invoked when app's
ViewRootImpl received ViewRootImpl#W#windowfocusChanged from WMS.
However, in the ViewRootImpl#W#windowfocusChanged, mViewAncestor is a
weak reference which get() may returns null sometimes.
One scenario is the ViewRootImpl#W#windowfocusChanged is called after
ActivityThread#handleDestroyActivity. The activity is destroyed and its
ViewRootImpl get GC'd. Then InputMethodManager#onPreWindowFocus won't
get called and InputMethodManager#mCurRootView won't be set to null.
And it is a proper time to set InputMethodManager#mCurRootView to null
when the window it served dismissed.
Fix: 116078227
Test: Break at ActivityThread#handleDestroyActivity and ViewRootImpl#W#windowfocusChanged
Change-Id: I8fabb30f14bcb2cd7019e29b6642b4562d49d248
Signed-off-by: daqi <daqi@xiaomi.com>
