Cause: It revoked the user consent of the vpn app without reseting always-on vpn.
In addition, prepareVpn sets legacy vpn as the current package, the state in
Vpn.class is broken, as it thought the current always-on package is legacy vpn,
(mAlwaysOn is only for app vpn, not for legacy vpn). As a result, prepareVpn rejects
all VpnService.prepare.
Bug: 29031820
Change-Id: Id6bf1d6f38cf134a872811806301b8a602fb5725
- Cache media_standard_iso
- Cache labels between configuration changes (localization might
change labels)
- Use ints instead of String's for standards
- Use HashMap instead of Array map as the lookup is faster for
larger arrays
Fixes: 29068056
Change-Id: I027c80fac4d7e8ea6c2cac0f1a2d52b54807f5be
Right now, because of the way that configurations are applied, when
the display turns on because of an incoming phone call the fact that
the lid is "shut" will automatically put the phone back to sleep,
causing the ringer to be silenced. By making this edge triggered, the
display will only sleep or wake up when the lid is initially shut or
opened, respectively, avoiding this issue. In the future we may want
to revise this so that the lid-shut state is better understood
throughout the system to avoid these types of issues, but for now
this is sufficient.
Bug: 26600446
Change-Id: I10d403b62944ed6eceaff58cddad5c243a2884df
am: 33d03a9e43
* commit '33d03a9e435eb474e3bdd3e958943e0057866477':
OP_ACTIVATE_VPN should not map to DISALLOW_CONFIG_VPN
Change-Id: Ib8e3b7fae441adf95b928d7139455d3ca13c1fb6
They are two different things.
OP_ACTIVATE_VPN means can we allow a vpn app to establish without user
interaction while DISALLOW_CONFIG_VPN means can the user modify vpn
config.
Testing:
1. Turn on DISALLOW_CONFIG_VPN, user cannot modify vpn config through
setting
2. Turn on DISALLOW_CONFIG_VPN, Dpm.setAlwaysOnVpn works.
3. Reboot after 2, vpn established automatically.
Bug: 29086229
Change-Id: I24899d6c7f0dd62bf441a44c6ee66fee35973a11
Native stack does not handle being put from OFF -> ON state without
doing a complete cleanup. Hence instead of going from start -> ON -> OFF
-> cleanup it goes start -> ON -> OFF ->ON -> ... usually leads to race
conditions down the road in native.
This patch is a workaround so that we can throw away the requests if we
are in currently "turning off" phase. The side-effect would be that user
will need to turn it ON again. The race happens when the turn OFF time
is longer but usually it is found to be close to order of seconds hence
the wait should be bounded.
Bug: b/28318203
Change-Id: I14f6633f31311e5b561e1dcbc8a9d6d2a5dd6fdc
am: 0bc61eb176
* commit '0bc61eb176644e243b0e131a29a5f66a4303d9b0':
Delay handleEnable() until Bluetooth state is OFF
Change-Id: I8953c12b4df0a60bd3649a055a4dbe03c93534e5
We need to figure out the default voice interactor to give
it default permissions. This happens before the user has
been unlocked and if the voice interactor is not direct
boot aware we fail to find it, hence no permissions are
granted. Now we query the package manager for both direct
boot aware and unaware components. This is fine as we
don't interact with the assistant until the user is
unlocked.
bug:28963642
Change-Id: Ide5471fa1798e868c6e3a4b5e87570a5556e2d3f
During shutdown of the Bluetooth stack, if a request to
enable Bluetooth is received, the request is processed immediately.
As a result, we don't let the Bluetooth service to shutdown cleanly,
and the Bluetooth process with the native backend doesn't go away.
This creates various issues in the native backend stack.
Now, after an enable request is received, if necessary we delay
acting on it, until the Bluetooth state is OFF.
Bug: 17723234
Change-Id: I55db4bbd4f45227aa49eae996dcc328f76557a9b
When task was selected for activity launched with flag FLAG_ACTIVITY_NEW_TASK
first matching task was omitted if there was another match lower in stack.
This lead to task shuffling in same stack.
Bug: 28848683
Change-Id: I94e55693fc7ed926fc151ba988d257bd2417dd45
