Also disables all setting of PAC networks through the internal AsyncChannel
methods. PAC can only be saved through addOrUpdateNetwork for permission
checks.
Bug: 11316946
Change-Id: I51016b578080c342a5e5d536ea9a3fdd4fe16644
Fix CountryDetector NPE by calling CallerInfo.getCurrentCountryIso() which
checks for potential nulls.
Bug:11291034
Change-Id: I0a4412c432551c64ec30652d69636442653ee337
In this case:
1. Privileged system app FOO is overlain by an installed update,
2. FOO was replaced during an OTA,
3. The new in-system FOO introduced new privileged permission requests
that had not been requested by the original FOO,
4. the update version of FOO still had a higher version code than
the new FOO on the system disk, and
5. the update version of FOO had been requesting these same (newly-
added-to-system-apk) permissions all along;
then the newly-added privileged permission requests were incorrectly being
refused. FOO should be able to use any privileged permission used by the
APK sited on the system disk; but instead, it was only being granted the
permissions used by the *original* version of FOO, even though the system
FOO now attempted to use them.
Still with me?
The fix is to (a) properly track privileged-install state when processing
known-to-be-hidden system packages, and (b) to tie the semantics of the
permission grant more explicitly to that evaluated state, rather than
using the prior (rather fragile) fixed-up privilege calculation applied
to the overlain apk's parse records.
Bug 11271490
Change-Id: Id8a45d667e52f3b5d18109e3620d5865f85bb9c9
The VPN permission check required internal knowledge that
other checks in the system would ensure that
package "com.android.vpndialogs" was genuine. In the
off chance those other checks change, or someone is
able to spoof the package name, this will at least
check to see that the app is on the system image; one
more hurdle to jump.
The original code for this change came from
https://android-review.googlesource.com/62270
Change-Id: I55580bee0b30036b0fee9ca4e43de9b736b194fe
Signed-off-by: William Roberts <wroberts@tresys.com>
Bug 11291911
These deleted classes were previously public APIs and so need to remain
in the build (but hidden) in order to keep existing apps working.
(Partially reverts Change-Id: I02549a71104b35d86d99058c71f43e054730ec7d)
Change-Id: I28e53b056f41e66645136f5e18fba2ff55a65fe5
Although the IME windows are now allowed to extend into
the nav bar, some IMEs were making assumptions about
computed insets based on the height of the content view.
So our navigation bar view (opaque view blocking the nav bar
area to avoid the island effect when transparent) needs to live
above the content view in the hierarchy, making the content view
the same height as it was before.
A surgical spot to put the guard view is up at the root view
(PhoneWindow.DecorView). fitSystemWindows is always called since
this view is not recreated, and the layout is stable: waiting until
the IME is attached to the window is too late to add a guard view.
This is above the screen_* layouts, so will work without having to
touch all of them. And it only affects windows of TYPE_INPUT_METHOD.
Bug:11237795
Change-Id: I6a93f30aec83f1cecfb854073046cbc87ab4aa66
