Replace usages where the Long is immediately unboxed or thrown
away with Long.parseLong().
In TaskRecord.java, I also fixed up similar uses of
{Boolean,Integer}.valueOf()
Tested: built frameworks/base successfully.
Bug: 28289401
Change-Id: I1fad536853a68c7b0707cbf02989aca155064843
Bug: http://b/26987366
This code was accidentally casting a uchar4 to a single integer, which
the latest llvm-rs-cc will flag as an error. The comparison was also
incorrectly using a single integer comparison, instead of looking at all
4 uchar vector components.
Change-Id: Id680d642cb0079461429f3910343c6dbe8d488ef
Even if the hostname aware method is called if the hostname is null then
the destination is unknown and the configuration can be ambiguous.
Change-Id: I7cacbd57a42604933fdc882371f143dc0a20902d
Bug: http://b/25497185
These APIs have been deprecated for quite some time, and it makes sense
to remove the obsolete tests.
Change-Id: Ief413633c49b304042e191fbc200901bf9a794ad
This will be used to create a custom conscrypt TrustedCertificateStore
to avoid loading all of the trusted certificates into memory in a
keystore.
Change-Id: Iaf54b691393ecadae6c7ff56b8adc6a2a2923d29
This allows for faster lookups of TrustAnchors when checking pin
overrides without needing to iterate over all certificates.
Currently only the system and user trusted certificate store are
optimized to avoid reading the entire source before doing the trust
anchor lookup, improvements to the resource source will come in a later
commit.
This also refactors System/UserCertificateSource to avoid code
duplication.
Change-Id: Ice00c5e047140f3d102306937556b761faaf0d0e
Debug overrides are only used if the application is debuggable in
order to help local debugging and development by trusting additional
CAs. In a non-debuggable version of the application the debug-overrides
are ignored.
Trust anchors in the debug override configuration have two key
differences from those in base-config and domain-config:
1) trust anchors in the debug-overrides are trusted for all connections
in addition to any trust anchors included in the relevant base/domain
configs.
2) By default trust anchors in the debug config override pins, as their
purpose is for connecting to non-standard servers for debugging and
testing and those servers should not be pinned in the production
configuration.
Change-Id: I15ee98eae182be0ffaa49b06bc5e1c6c3d22baee
Nested domain-config inherit unset parameters from the domain-config
they are nested in. This helps avoid copy and pasted configs that are
almost the same except a few minor differences for a domain with
slightly different requirements.
For example: Consider a domain-config for example.com that, among other
settings, does not enforce hsts. Now if you want the rules for
example.com to apply to secure.example.com except that hsts _is_
enforced you can make a nested domain-config for secure.example.com
under example.com that sets hstsEnforced="true" and nothing else.
Change-Id: I9e33f7e62127fd7f4f15c3560fff2f2626477bd4
XmlConfigSource parses an ApplicationConfig from an xml resource.
Currently this supports app-wide default configuration via the
base-config element, per domain via the domain-config element and
inheritance of unset properties at parse time.
Inheritance of unset properties is currently only:
domain-config -> base-config -> platform default configuration
Where the most specific value is used.
For example: If the base-config specifies trust anchors, all connections
will use those anchors except for connections to a domain which has a
domain-config that specifies trust anchors, in which case the
domain-config's trust anchors will be used. If the domain-config or
base-config don't set trust anchors, or don't exist, then the platform
default trust anchors will be used.
Nested domain-config entries, debug-overrides, and thorough
documentation of the xml format will follow in later commits.
Change-Id: I1232ff1e8079a81b340bc12e142f0889f6947aa0
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
Bug: 25497185
These tests all use deprecated graphics APIs along with unsupported
pragmas. Removing them first will make our pragma cleanup simpler.
Change-Id: Icd0f2690d79dd8deb709724b47607483d6e3dea2
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
...with protection flag PROTECTION_FLAG_DEVELOPMENT
Bring back the old grant/revoke code for development permissions.
Also some more dumpsys output to help debugging.
And new dumpsys command for checking a permission.
Change-Id: I6e27e62a9ca5ec1ecc0f102714a448ea02f0f41c
Add new Activity.isVoiceInteractionRoot() API that an activity can use
to determine whether it is the root activity of a voice interaction
session started by the user's designated voice interaction service.
This is a special new API that apps must explicitly check, because as
with visual activities the model behind an activity should usually be
that it accomplishes its task by interacting with the user (implicitly
getting their approval) rather than trusting that whoever invoked it
is telling it to do what the user once. In the voice world, however,
there are some cases where quick interactions want to allow for immediate
execution without further user involvement, so this API allows for that
without opening up security holes from other applications.
Change-Id: Ie02d2458f16cb0b12af825641bcf8beaf086931b
The main change here is to not allow the dialog to go in to its "focus
on the last app the user selected" when running in voice interaction mode,
instead just always giving a simple list.
This also fixes some problems with cleaning up active commands when
an activity finishes and not forcing the current session to go away
when the screen is turned off.
Also added some debug help, having activity print the state of the
voice interactor.
Change-Id: Ifebee9c74d78398a730a280bb4970f47789dadf5
