2/ Handle Subscription for alert.
3/ Support no_report_metric
Bug: 69522276
Test: all statsd unit tests passed.
Change-Id: I851b235f2d149b8602b0cad632d5bf541962f40a
Though not yet used, the Proof-of-rotation certificates are intended to be
used by the platform as equivalent to signing certificates, i.e. the presence
of a certificate in a Proof-of-rotation record should grant equivalent
capabilities as if the APK were signed by that certificate. For this to work,
each certificate needs to be signed by the previous one indicating a transfer
of trust all the way to the signing certificate of the APK. There is no case
in which the last certificate in the Proof-of-rotation record should not be
the one used to sign the APK, so enforce this during verification.
Bug: 64686581
Change-Id: Ia1b25a917a878fb378c8557b25a2bbfdd9da7d3d
Test: Builds, boots, passes
android.appsecurity.cts.PkgInstallSignatureVerificationTest
Add ApkSignatureSchemeV3Verifier to enable APKs to be signed with
the new signature scheme. Update the ApkSignatureVerifier to process
the results, but only pass on what's needed for the existing interface.
In the process, move the ApkSignatureSchemeV2 code into a common
area for use by any scheme that makes use of the APK Signature Block.
The primary purpose of APK Signature Scheme v3 is to enable applications
to rotate their signing key. This is accomplished by augmenting APK
Signature Scheme v2 to also include a new Proof-of-rotation struct, which
is fundamentally a singly linked list where each of the APK's signing
certificates is included in order, along with a signature over the next
certificate. Thus, each certificate contains proof that the private key
corresponding to the previous one blessed it. This provides evidence to
the platform that the new signing certificate should be as trusted as
the previously trusted one. This structure also includes some flags for
each certificate to indicate to the platform how the APK itself would
like to interract/trust the old certificates.
Bug: 64686581
Test: Builds, boots, passes
android.appsecurity.cts.PkgInstallSignatureVerificationTest
Change-Id: I0f98ff13950af78f5d9b269f80d13af8891f7a2d
There are currently two conceptual operations performed by PackageParser
while parsing APKs: collecting certificates and verifying them.
ApkSignatureVerifier relies on the systemDir flag to indicate whether or
not it should do a full verification of a package, but this only applies
when verifying V1 (jar signed) APKs. This distinction should be explicitly
made. This creates cleaner code and also saves time when verifying V2
signed systemDir APKs.
Bug: 64686581
Test: Builds, boots, passes
android.appsecurity.cts.PkgInstallSignatureVerificationTest.
Change-Id: Ie8a0f8cad3dd8f70da791f2f1f4516e84e2ae4d0
This is a first step at a larger goal of moving instant app
verifications from parsing logic into install logic.
Test: manual - install v1 and v2 instant app and static lib
Test: android.appsecurity.cts.PkgInstallSignatureVerificationTest passes.
Change-Id: Iab50b91a6fb8ef014b573bb9f733d30c1aa6022f
Bug: 68860689
This API allows app to construct custom metrics based on labels
chosen by the app developers. Also added some buttons to manually
test this functionality in the dogfood app.
Test: Verified that Android can be built and tested with custom app.
Bug: 69522276
Change-Id: Ifb7abea4c1d62fb435a9cb6f32df12bc2234d82f
PackageParser shoudln't really need to know the gory details of APK
verification, it should just get back the blobs it needs to do its
job. Move the package verification into its own class which is
*almost* exclusively responsible for verifying app signatures. This
is in preparation for adding APK signature scheme v3, which will add
yet another way to do this.
Bug: 64686581
Test: Builds 'n' boots without issue.
Test: android.appsecurity.cts.PkgInstallSignatureVerificationTest passes.
Change-Id: Ieb76b2353bd44ffdb83e7b894e5ad720d1697dc7
This introduces PooledLambda - a way of obtaining lambdas without the
allocations overhead.
See PooledLambda javadoc for a guide and PooledLambdaSample for code samples
of useful usages.
Test: ensure samples of PooledLambdaSample work as described.
Change-Id: I46f8ad27bc1de07e19f6e39f89d2cafe4238497a
This API can be used by clients to gather stats about statsd, eg.
memory usage, number of metrics/matchers, etc. This data can be used
to debug if devices are not providing expected metrics. The metadata
will be for all configurations, but will not contain the actual
collected metrics since those might have privacy implications.
Test: Tests that statsd and Android still build.
Bug: 69522276
Change-Id: I8e0fedc142f5deed7be6e6309f9444e67d8369ce
We log if the statsd is not available instead of throwing an
exception. This helps prevent a crash when calling this API since
statsd is not a system service and can potentially be down.
Test: Not applicable.
Change-Id: I776efede4a01c751924fa9a8abd0eec0c4c1306b
- Extract the battery saver mode transition logic to BatterySaverController.
This now also supports running different code when screen turns on and off.
- BatterySaverPolicy now takes a "per-device configuration" from config.xml,
which can be overwritten via a global setting. We'll use this to set up
max CPU frequencies.
- The actual part to write max CPU frequencies is not finished yet.
Test: atest BatterySaverPolicyTest
Bug: 68769804
Change-Id: Ife38c2cd94ac9902911b005dbbca8b0d0a62e6d7
It's not used by anything yet, but will eventually be used to query
feature override from different data sources (such as Settings.Global)
Bug: 36222960
Test: atest
Change-Id: Ie32f7c59b4a27199da72d8c9fbfdd1aeee6c0b34
The stack is truncated up to 5 lines at parcel time. When unparceling,
a separate RemoteException will be created and set as a cause of the
exception being thrown.
Performance results(in nanoseconds):
timeWriteExceptionWithStackTraceParceling 4168
timeWriteException 2201
timeReadException 15878
timeReadExceptionWithStackTraceParceling 23805
Test: manual + ParcelPerfTest
Bug: 36561158
Change-Id: I18b64a6c39c24ab067115874ddb5bd71f556a601
This API will primarily be used by GmsCore to send updated configs.
Also, sending a config will implicitly notify the StatsD that this
client wants to know when it should request data for this config.
We send a broadcast so that all interested subscribers can know if
data needs to be pulled.
Test: Manually tested that sending broadcast works via new adb
command added in StatsService.
Change-Id: I23cdd1df706036e14b32c3d01af30c3d4af819fa
No libcore dependencies on these classes remain, so they
can now move to framework which already has all of the
other classes from android.util.
After this CL topic, libcore and framework no longer have
any classes from the same package.
Bug: 67901714
Test: make droid
Test: Treehugger
Change-Id: I65871516b762d8a53ebe01697e4d92f94903bfd3
The current JobInfo.NETWORK_TYPE values offer basic network selection
ability, but more precise requirements continue to come up. Instead
of creating more NETWORK_TYPE constants, add support for the existing
NetworkRequest object, which is the idiomatic way for an app to
express the type of network they'd like to use.
Move the implementation details of NETWORK_TYPE constants to use this
new NetworkRequest functionality. Deprecate NETWORK_TYPE_METERED,
since the lack of the NOT_METERED capability doesn't imply that the
connection is metered. (Apps using this API to get to a cellular
network should use TRANSPORT_CELLULAR instead.)
Add new SystemClock APIs that return java.time.Clock instances for
various Android-specific clocks. This gives us a clean interface
(with negligible overhead) for swapping in artificial clocks for
testing purposes.
Improve JobStoreTest to validate new NetworkRequest features, and
add one last sanity check to assertTasksEqual() to compare raw
bits-on-wire, to catch people who forget to check new fields. Watch
for IoThread to go idle to run tests faster.
Test: bit FrameworksServicesTests:com.android.server.job.
Bug: 67040695
Change-Id: I189e7602132a0ec26d2f0cc6dadc188664961a47
Test: with CPU locked to low freq, verification time of a 400 MB apk is
reduced from about 2528 ms to 1942 ms, vs 915 ms of the old
algorithm. Writing directly into ByteBuffer's backing array saves
around 100 ms but it does not work for DirectByteBuffer, thus I
didn't implement this optimization.
Bug: 30972906
Change-Id: I00cf782e18a8351569eaf4593188c1ce6796a634
Test: Locally add some code in PackageManagerService to generate the
verity tree. Root hash and the tree is consistent with the output
of apksig.
Test: With local mod, with apk size of 400/100/20/5 MB, verification
time is about the same for the existing algorithm before and after
the refactoring.
Test: With local mod, with a 400 MB apk, verification time of the new
algorithm is slower (2s) than the 1MB-based algorithm (600ms).
Bug: 30972906
Change-Id: Ie429cf9b80884e56a8e0882e1c125c8a3f8feab4
It is very unlikely the protobuf changes the value in descriptor.h,
and if defines an extra mapping, there are several places to maintain:
1. java-stream,
2. cpp-stream,
3. ProtoOutputStream.java
4. ProtoOutputStream.cpp
5. Privacy.h (GetFieldId)
6. StatsLog to generate field id (type << 32 + field number)
Therefore use the current value in descriptor.h seems reasonable unless
they change that, very very unlikely, they probably will just add new
types, and deprect the existing ones like Group.
Test: test output of dumpsys proto
Change-Id: I6e150ab427851dd3b5dd55d3b273deeed7a0963c
