Core system components (such as those marked as "persistent") are
aggressively restarted by the system, so crashing them as a side
effect of wtf() could easily cause system instability.
Instead, this change now treats persistent processes the same as the
system_server; we still log the wtf() event, but we don't crash
the app.
This change also causes wtf() events to be fatal on "eng" builds,
which will result in bugs being caught earlier during development
instead of later during QA testing.
Test: builds, boots, SystemUI no longer crashes
Bug: 32976626
Change-Id: Ib2d1a73379be40556f8dab5d1f15b9ed91ba7082
When device upgrades from L->N, sid(in gatekeeper) could be 0
even primary profile screenlock is set.
We are now trying to catch the exception so when sid==0 happens,
it will try to tie profile lock again when primary profile is unlocked.
Bug: 32490092
Change-Id: I73011d872ac15e7e09be9bda0165cf7f6a75493a
The supports-multiwindow command allows the ability to
check if the device has multiwindow support in the shell.
Bug: 30120559
Change-Id: I466e28d8a794fa457826a6526ef9ef660cd3856c
Test: Manual, usleep(16000) in DrawFrameTask and tap
on recents
Merged-In: I88bb30a2503bc908ec45650c7d36b6fb3cc750d0
Change-Id: I88bb30a2503bc908ec45650c7d36b6fb3cc750d0
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
This CL adds bookkeeping to DPMS which will allow us to tell the user
in the Settings UI whether/when the admin requested a bug report or
retrieved logs from the device.
Bug: 32692748
Test: Full DevicePolicyManagerTest unit test coverage; end-to-end tests
will follow as Settings CTS verifier tests
Change-Id: I89728fce4b7e0ff061b354c73caf3742e95a3a3e
Settings needs to access a variant of getInstalledApplications() which
takes a |userId| argument. Since this is not currently exposed by
PackageManager, Settings calls into PackageManagerService directly. This
is ugly and breaks the regular abstraction layer hierarchy.
The CL fixes the problem by exposing the required variant of
getInstalledApplications() as a hidden API, analogously to what was done
before with getInstalledPackages().
Bug: 32692748
Test: Will be CTS-verifier-tested together with Settings
Change-Id: Id9c4e8e18524d312159821f1a4d5527263c7e950
For phase-2, instead of taking a hash prefix, we will send the
hostname to the resolver.
Bug: 25119046
Test: build & install the sample resolver and run 'adb shell am start -a android.intent.action.VIEW -c android.intent.category.BROWSABLE -d "https://www.tripadvisor.com/Tourism-g33020-San_Jose_California-Vacations.html"'
Change-Id: I6e621139e182f9a9cfcf608c26d4763f1379bdb2
Added a new flag that allows carriers to ignore data disabled
(e.g. data reaches limit or user disables data) so VT calls
will not be downgraded/torn down and VT service will not be
disabled.
Test: telephony unit tests
bug: 32880745
Change-Id: Idd33a022b5a31cbc58592587bcb496bd78923ae7
