Setting shares system uid and can be used to bypass different security
checks.
We add proper handling for intents which resolve toexported=true
activities with permission filed.
Added nested preferences filtering.
Bug: 33123882
Test: manual tests
Change-Id: Ib5bab7989fc44b4391f9050c6b18f81c58c09cf6
Remove the learn more link during setup wizard, because HelpUtils is
returning null for the intent while the device is not provisioned.
Bug: 31246856
Change-Id: I4cf5c282f170188aef98a02d3b96af5e63ea7f39
- Prevent external tiles from system apps
- Don't let user settings run
- Disable help
Bug: 29194585
Change-Id: I74ab8aaab62d62cc4dbbdf3164429a503f3a572b
The privilege for an app to write to the system settings is protected
by an app-op signature permission. App-op permissions are special: if
the app-op is deny/allow we deny/allow write access; if the app-op is
default holding the permission determies write access. The settings
code assumes that CHANGE_NETWORK_STATE is an app op permission
(system|appop) while it is a normal permission which any app gets by
declaring it used in the manifest.
The side effect is that the state of the toggle in the UI for write
system settings will initially be in the wrong state if the app uses
both WRITE_SETTINGS and CHANGE_NETWORK_STATE. However, the code in
the public API an app uses to check write settings access would return
the opposite since it checks the WRITE_SETTINGS permission and its
app op. Hence, if an app requires write settings to start the user
will see in the settings UI it has access but the app will not have
access, so the app would prompt the user to allow write settings.
The non-obvious fix is for the user to toggle the setting off and on
to get the app op in the right state and be able to launch the app.
bug:25843134
Change-Id: I3d726a66c7f9857bc7dbd5946fdbb8f340c6eb4d
(cherry picked from commit 356fb2d10d)
(cherry picked from commit 119d589ea5)
Guard against FRP attacks by keeping the persistent data block
intact, if a factory reset has been issued during SUW.
Bug: 25290269
Change-Id: Id26b4c10235ad126632b71875592a4fa70a39b24
Guard against FRP attacks by keeping the persistent data block
intact, if a factory reset has been issued during SUW.
[resolves merge conflicts with ag/808069]
Bug: 25290269
Change-Id: Id26b4c10235ad126632b71875592a4fa70a39b24
+ In BT pairing dialog, uncheck checkbox for contact sharing by default
for devices not recognized as carkits at pair time.
Bug: 23607427
Change-Id: I7f1d40d86e713e248d3c225459be4895c4f75d76
(cherry picked from commit dbc47fb262)
+ In BT pairing dialog, uncheck checkbox for contact sharing by default
for devices not recognized as carkits at pair time.
Bug: 23607427
Change-Id: I7f1d40d86e713e248d3c225459be4895c4f75d76
Block access to development settings by tapping on the build number
in "About phone". Once SUW has completed, taps will be allowed.
Bug: 25290269
Change-Id: I9b2787712237f28fba446abab15a9e1c075d0419
Make sure the duration shown for z-ram is sane (the maximum of the
other process durations of that app).
Change-Id: I62c46b89f927b2c7c16f5c31f6910419b2bdd130
Just distribute them across all of the running apps, by creating
an additional fake "z-ram" process for each of them.
Change-Id: I9b4efe9c7b907779a0ec76cb8652709619e2e686
When building list of historical data usage cycles, omit cycles
that don't contain any data usage. A bad NITZ or NTP fix may have
caused us to record some usage in 1970 or 2038, which would have
shown all the cycles in between. Now we hide empty cycles to keep
things clean.
Bug: 18282691
Change-Id: Ib04c95d1411400ba9967d311b59402a26d39cfe3
Without clamping, they can wrap around to negative values and cause
all sorts of havok. 1TB ought to be enough for anyone: that's 3Mbps
for a solid month.
Bug: 24555152
Change-Id: If92c87f9920c3f05cd3ff2cc6630b1bbb65335b8
Fix problems from unsupported intents being launched through adb.
Remove the ones we can, fix the other.
Bug: 19634064
Change-Id: Iba0adeb135e76ee70365e5891380ba8b55110c26
Currently, if the user clicks "forget" on the configuration
dialog for the profile that is currently being used by the
always-on VPN, we don't disable the lockdown VPN, and we crash
on next boot because ConnectivityService tries to start
LockdownVpnTracker with an invalid configuration.
Fix this by removing the LOCKDOWN_VPN variable in the keystore
(which disables the always-on VPN), and notifying
ConnectivityService.
Bug: 23625458
Change-Id: I3545286c9fc23517306aa94607a4b2cb55cc56c4
Also make sure that the 'Clear defaults' action unsets the app's
standing as the default browser, when applicable.
Bug 23751034
Change-Id: I6131b763bfa76ba38d18cad2abbb35caffe789aa
Copied ExploreByTouchHelper, LinkAccessibilityHelper and LinkTextView
from setup wizard and switched fingerprint_settings_footer to use
LinkTextView, so that users can navigate to the link in TalkBack
mode.
Bug: 24343933
Change-Id: I0ff0c054510dfef4263ea223cb0044a4bddf321f
