am: 1e8362d4
* commit '1e8362d44959da7d80e6da626c53ef8cda2f0718':
Wait for JobService to start before scheduling syncs
Change-Id: I54c74b747b16012ec513c8e9f38fec10f38a8ee3
am: a16a336
* commit 'a16a3362b535fcb970756a39fd4657bd15922592':
Wait for JobService to start before scheduling syncs
Change-Id: I05eb60240bb9cf4885e9e5df4470a93f89930b21
am: f35865b
* commit 'f35865b71a1030d8b68b720ff073a4a3f4945155':
Close open sockets when enabling firewall rules.
Change-Id: I3a1a13f20322d0e93f3cc083c2abb63d05fd68f5
am: 05227fd
* commit '05227fd3d09af9ea9391140be421919273dcb59f':
Close open sockets when enabling firewall rules.
Change-Id: I61358cc68858cb37af7cfb633d6b55eb086b47f4
am: b414eb8
* commit 'b414eb8de66153d835090a1518017bc11489bce4':
Close open sockets when enabling firewall rules.
Change-Id: I915ce66c1d3c1a65e005324fedb7f76557e3b006
am: b414eb8
* commit 'b414eb8de66153d835090a1518017bc11489bce4':
Close open sockets when enabling firewall rules.
Change-Id: I2bb4be1cec701e9e99d264ab4fd2322bc20e7d2c
Now that it's long since been unused also delete the locking that was
introduced to make it possible.
Bug: 17733693
Bug: 24837343
Change-Id: Iee817a7c2e1d1dc9c080d3124d5986232dcda00f
When enabling a firewall rule that will deny networking to apps,
first close any sockets opened by those apps. Just dropping an
app's packets without closing its connections has the following
problems:
1. The app has no way to know this has happened until a network
timeout occurs.
2. The app's connections stay open, so the other end of the
connection (e.g., a server) might continue to retransmit
packets. These packets will wake up the kernel and cause
battery drain, but we cannot respond to them because packets
on those connections are dropped by the kernel (since the app
is blackholed). So the other end might keep retransmitting.
3. Even though we think the connections are still open, the
other end of the connection, or any intermediate NATs or
firewalls, might time out and close the connection (e.g., by
sending a RST). Because the app is blackholed, we have no way
of knowing that this has happened, so when the app is granted
network access again, these connections might just get stuck.
Bug: 27824851
Bug: 27867653
Change-Id: Iaaad1b26954fc5f1ba5c9ed8bdee039282f5e249
am: c394db8
* commit 'c394db8013be6fdb334b782fc145d3eec0dd3b52':
Fix a few issues with occluded Keyguard
Change-Id: If030fe3991c94145e62f0465c6873c6999d69175
am: a5bc2fe
* commit 'a5bc2fe41d7a0fb694f5409766f7cdd3f085490f':
Fix a few issues with occluded Keyguard
Change-Id: I04393556e2739435e44e7cc8f4e265a07ed9bc81
am: c5804af
* commit 'c5804afa73edbf229e789570d288e66f70b54fa2':
Fix a few issues with occluded Keyguard
Change-Id: I0e805ee2b7cf37b60b08f951bf1e0e4fdde93464
am: c5804af
* commit 'c5804afa73edbf229e789570d288e66f70b54fa2':
Fix a few issues with occluded Keyguard
Change-Id: Ibf2f0848c597a0223e2a8c5e361c669f23e2c0fb
- When we get a collapse before the layout happened in SystemUI,
don't expand the panel after the layout.
- Don't reset waitingToShow when coming out of sleep. This will cause
win.isVisibleOrBehindKeyguardLw to return false and then occluded
state will change rapidly from true -> false -> true, leading to
flickering in SysUI.
Bug: 23898941
Change-Id: I2b941188de777086bb2b477f5bfc00cc0cd6abe0
am: c8cd948
* commit 'c8cd9483ea98d07d73be556148c1a44e206278a2':
Don't hide app windows due to not showing when locked when keyguard is hidden
Change-Id: Ie6487a016af109f9f07c844c48a49f0bc5f96fb0
am: e482eaf
* commit 'e482eaf6dffbae98e533b01628f161ce0a48be6d':
Don't hide app windows due to not showing when locked when keyguard is hidden
Change-Id: Ib7128e2019536c8570de81b060ae256ffd256a46
am: 72c216f
* commit '72c216f25072123f498105bc7ad98a65a7a3cdaf':
Don't hide app windows due to not showing when locked when keyguard is hidden
Change-Id: I93e02ad16b4dc0c92a7e02432b992cbbe9c77aa1
am: 72c216f
* commit '72c216f25072123f498105bc7ad98a65a7a3cdaf':
Don't hide app windows due to not showing when locked when keyguard is hidden
Change-Id: I33795a8690e52d26b6f66f991b03b16bdeb665f4
In some cases, recents didn't get resumed, so divider was never
notified and thus we didn't start the animation. Instead, move
the first drawn logic into onStart.
Bug: 28366529
Change-Id: Ia71d6b517451bba727ae31a184bb55cecf5af198
This worked in pre-N because the only visible app was the app that can be
shown when the keyguard is hidden. That isn't the case in multi-window mode
where one of the apps can be shown when locked and the other doesn't have
the show when locked flag. Only hide the other app if the keyguard is shown.
Bug: 28368875
Change-Id: I5039098db74492fadf667fed24fc58448436681a
