am: 709c46a60a -s ours
am skip reason: change_id I64b05adcb46baf3fca116dbdc5177bc31c71e06d with SHA1 c0274d1315 is in history
Change-Id: I8b637490b79bc202530e095644ad7e23c434e59f
Split-tunnel VPN (which are the only ones affected by this change)
always fall through to the default network for routes they don't
handle, and even if the underlying network(s) don't provide access
this may be a pinhole that can actually reach the broader network.
In practice this behaves like the original release of P and is the
safest thing to do for Q. In R we should evaluate giving the VPN
app the ability to simply tell the network stack whether it does
provide Internet access or not.
Bug: 119216095
Test: FrameworksNetTests NetworkStackTests
Change-Id: I262ca41fe0225660551c9a421562405366b6acac
Merged-In: I262ca41fe0225660551c9a421562405366b6acac
(cherry picked from commit 6d5a4a3b1d)
Add a check that callers with UID 1000 always have the same PID. This is
a proxy for checking that no system is designed to bind to the network
stack unless it is the system_server, as otherwise either the
system_server would start crashing, or that system would not have access
to binder calls.
Also remove access from PHONE_UID as it is not being used.
Test: Flashed, WiFi working, Bluetooth reverse tethering shows no
permission issue.
Bug: 133209255
Change-Id: Ib848aaaedfd599c1d4437378846c7dda74352019
No internet notification may be prompted before partial
connectivity being detected. Partial connectivity status will
be set into NAI and prompted in the Setting. Behavior is not
aligned between Setting and notification. Thus, update
notification again if partial connectivity is detected.
Also, sliently show the updated notification if no internet
notification has already been shown to user to prevent alerting
user in short time.
Bug: 130683832
Test: Verified with simulated partial connectivity
Test: atest FrameworksNetTests
Change-Id: Ie16a8ce6e0fa437048e8c1eea240314ca30e9520
System server | NetworkStack
|
NetworkMonitorCallbacks ←----|--- NetworkMonitorCallbacks$Stub$Proxy
↓ | ↑
NetworkAgentInfo | NetworkMonitor
↓ | ↑
NetworkMonitor$Stub$Proxy ----|---→ NetworkMonitorImpl
Bug: b/133174607
Test: Manual. The simplest artifact is observed by watching the output of
adb shell dumpsys meminfo -d com.android.networkstack | grep 'Proxy Binders'
while connecting and disconnecting multiple times to any network.
This will display the number of binder proxies. Before this, the binder
proxy count increases by 1 with each connection and never goes down (there
is some noise, as proxy objects are sometimes created for other reasons,
and get GC'd eventually). After this, the binder proxy count is always
eventually stable at 27 + connected network count.
See the bug for the complete analysis.
Change-Id: Ide2428dab3fcd6d7cd00aa2a9fd99d6c99b815a4
Split-tunnel VPN (which are the only ones affected by this change)
always fall through to the default network for routes they don't
handle, and even if the underlying network(s) don't provide access
this may be a pinhole that can actually reach the broader network.
In practice this behaves like the original release of P and is the
safest thing to do for Q. In R we should evaluate giving the VPN
app the ability to simply tell the network stack whether it does
provide Internet access or not.
Bug: 119216095
Test: FrameworksNetTests NetworkStackTests
Change-Id: I262ca41fe0225660551c9a421562405366b6acac
am: 8608b9e115 -s ours
am skip reason: change_id I43640d87c4fcd0a8211dc04c4203a7b80b150f58 with SHA1 5ec20d472e is in history
Change-Id: I0f0851a45797278eb8092242c2b5c7d5b453a9d8
1. Previously, getDnsNetId doesn't handle all the cases.
Fix it with cosidering bypass private DNS flag.
2. Make getDnsNetId return Network instead of netId,
and change name from getDnsNetId to getDnsNetwork
Bug: 129530368
Test: atest DnsResolverTest DnsUtilsTest
Change-Id: Ic8d45b802d72a266f9ec97bfea620c1ede6967e5
Captive portal overrides two shouldOverrideUrlLoading methods,
but show certificate logic only be implemented in deprecated one.
Bug: 133714666
Test: -build, flash, boot
-atest FramworksNetTests
-manual test
Change-Id: I2656bb709cb0bf259279ca75ad8411cd8c92fb43
Merged-In: I64b05adcb46baf3fca116dbdc5177bc31c71e06d
(cherry picked from commit 9161b5e845)
When IME window switches from current display to another display and back quickly,
system will re-bind InputMethodService to re-attach window token for each moving,
the IME service lifecycle will be onBind -> onUnBind -> onDestroy -> onBind.
Ideally, system will deliver window token when onServiceConnected and system should
only receive one onServiceConnected when the last service bound.
But due to user switch display very quick, before unbind service callbacked from client,
the next bind service request comes, caused the connection exists in system side and
client will then callback 2 onServiceConnected to system.
Since CL [1] introduced InputMethodPrivilegedOperationsRegistry to deal with token
registraction singleton-ness, the exception will be thrown for above case due to
the duplicate window token passed to client.
Add InputMethodPrivilegedOperationsRegistry#isRegistered to check if the token
already registered, if so, skip this duplicate initialization request.
[1]: I4a61470f06ffac5f7a512536f8431489db0108f4
Fix: 133624278
Test: manual as below steps:
1) Settings > Developer options, enable "Simulated display" & "force desktop mode"
2) Reboot device.
3) Launch app from simulated display.
4) Launch app from primary display (i.e. contacts), focus EditText to show IME.
5) Tapping primary & simulated display repeatly & quickly.
6) See if any exception log from IME application. (i.e. Gboard)
Change-Id: Ie6bfbae735724fe744590e715124d2737d2b665d
All new code in LMS wrapped with try/catch and swallowing exceptions
to make sure new code never crashes LocationManagerService.
Bug: 133906682,133190291
Test: Tested with (statsd_testdrive + gnss test apk). Work as intended.
Change-Id: I989b1361c029e76d35861cf23d5c3d152f0bf81a
am: 4311022170 -s ours
am skip reason: change_id Ia6b00dd88f8f31823647c56c20b8c7edd20280f7 with SHA1 b38065dd3a is in history
Change-Id: I88245117b4c90de8faa3d7976213249eaa73b9d4
Asynchronicities in activity teardown -> service connection teardown
introduced a race in which the teardown could race with new service
bindings to "the same" service instance, and then wind up attempting to
shut down a new, valid instance inappropriately. Fixed by making sure
to clear the "what needs to be torn down" bookkeeping as part of the
act of doing that teardown, removing the possibility for stale state.
Fixes: 131029480
Test: manual
Test: atest CtsAppTestCases
Change-Id: I33a63f524d147ff6ec97dd3efb0127dcace8bf3c
am: d5109d1bd2 -s ours
am skip reason: change_id I49fbde1fe73b33aadcf8fd23ad224f363b137bf3 with SHA1 bd0005b43d is in history
Change-Id: Icfe0c92b130b7bde5686ec8186d5df0fa16aa126
