The builder supports all the standard builder set* methods as well as
setting a parent builder to use when values are not set (recursively).
This allows us to have a level of inheretence in configurations without
complicating the lookup and trust checking logic by doing inheretence
when building the configs.
Change-Id: I054af83451e52761227479eadf9cb9803437505f
Initial implementation of a unified application wide static
network security configuration.
This currently encompases:
* Trust decisions such as what trust anchors to use as well as static
certificate pinning.
* Policy on what to do with cleartext traffic.
In order to prevent issues due to interplay of various components in an
application and their potentially different security requirements
configuration can be specified at a per-domain granularity in addition
to application wide defaults.
This change contains the internal data structures and trust management
code, hooking these up in application startup will come in a future
commit.
Change-Id: I53ce5ba510a4221d58839e61713262a8f4c6699c
I think what probably happened is that since we only report an app
going in to the "interaction" state as an interaction event to usage
stats, apps that sit around in that state forever will only see one
interaction at the start and never again. So usage stats could start
thinking they are idle.
Fix this by having the activity manager report an interaction event
for such long running applications at least once a day.
Also, because it is correct and for paranoia by protected us another
way, system uids should never go in to standby.
Change-Id: I8a3805bfca86cbe78560488a649ecd07427da99a
During system boot, we prune app-ops belonging to apps that have
been uninstalled. However, apps installed on adopted storage devices
haven't been scanned at this point, so they appear to be uninstalled.
To avoid pruning app-ops for these apps, we need a getPackageUid()
variant that also considers "uninstalled" apps for which we still
have PackageSetting values.
Bug: 25206071
Change-Id: I1820f674d45c5ddc1c5f10ed7d859e7025005e28
This is needed in order to allow implementations of the HFP HF side to
define when audio can be routed to the device. This allows for calls dialed
from an AG to be kept on the AG if desired.
Bug: 25332357
Change-Id: I35a554cfc53f88c7dd3059bf52df5c69df9c7415
This is being added to help identify system apps so that
the UI can filter on that type.
BUG: 24955055
Change-Id: Ie4be3717ce997f60eeb48a389c0f54ce5803141a
A crash occured on updating after calling removeSelection with showing
selection handlers. This was because some selection-handler code didn't
consider the case the selection index was -1 (-1 means there is no selection).
This patch fixes this crash.
Bug: 23299977
Change-Id: I736d315e073f773aec597522203015205a8da42b
This is a partial revert of http://ag/738523 , but not a full
revert because M apps that have gone through the WRITE_SETTINGS
route to obtain permission to change network state should
continue to have permission to do so.
Specifically:
1. Change the protection level of CHANGE_NETWORK_STATE back from
"signature|preinstalled|appop|pre23" to "normal". This allows
apps that declare CHANGE_NETWORK_STATE in their manifest to
acquire it, even if they target the M SDK or above.
2. Change the ConnectivityManager permission checks so that they
first check CHANGE_NETWORK_STATE, and then ask Settings
if the app has the WRITE_SETTINGS runtime permission.
3. Slightly simplify the code in the Settings provider code that
deals specifically with the ability to change network state.
4. Make the ConnectivityService permissions checks use the
ConnectivityManager code to avoid code duplication.
5. Update the ConnectivityManager public Javadoc to list both
CHANGE_NETWORK_STATE and WRITE_SETTINGS.
Bug: 21588539
Bug: 23597341
Change-Id: Ic06a26517c95f9ad94183f6d126fd0de45de346e
