Since these are hidden it cannot be accessed by system service registery
Removing it for now and can be added later when these becomes SystemApi
Bug: 140768340
Test: Build & basic sanity
Change-Id: Ibb007f0a761bcbd006ebffbb552d0da82b586d03
By default instrumented processed have access to @TestApis; however for certain CTS tests we want to disable access to test APIs, where this flag would be used.
Test: manual
Bug: 133832325
Change-Id: Id56ce3079bcea2632d4002edcf120d9d5c9e0a26
Merged-In: Id56ce3079bcea2632d4002edcf120d9d5c9e0a26
go/cleanup-greylist-txt
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Bug: 137350495
Test: m
Change-Id: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
Merged-In: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
See go/UnsupportedAppUsage for more details.
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Bug: 137350495
Test: m
Change-Id: I5aa29a49b193db47aaee4d3a756c17f48cc9f0b1
Merged-In: I5aa29a49b193db47aaee4d3a756c17f48cc9f0b1
today telephonyRegistry lives in system process
this is intended to persists all telephony listeners when
phone process crash. Telephony today notify system server by
using AIDL APIs directly. Instead, we are exposing a proper API
surface: telephonyRegistryManager where only phone app and
carrier privileged apps are allowed to use APIs in
TelephonyRegistryManger to notify telephony related status update.
Bug: 140908357
Test: Build & Manaul
Change-Id: I1b750751148925b4a7bd94553318907654012fc1
(cherry picked from commit 288b71c8c1)
Merged-in: I1b750751148925b4a7bd94553318907654012fc1
Make TimeDetectorService more aware of a time signal's origin by making
the time signal from telephony less generic.
When TimeDetectorService was written it was assumed that the TimeSignal
could be generic and there would just be a String source identifier to
indicate origin.
With multiple SIMs / phones on a device it makes sense to keep track of
the originating phone of the signal so that the time detector service
could implement stickiness if it wanted. This would avoid a device
alternating back and forth between two signals and help with debugging.
As new signals are added, new "suggestXxxxTime()" methods will be added
to TimeDetectorService. That is the point at which the strategy for
ranking different sources can be decided. e.g. should NTP always rank
higher than NITZ?
The main change here is that TimeSignal is renamed to
PhoneTimeSuggestion to indicate it's only for use by signals from
telephony, sourceId has been removed and it has been given a phoneId
instead. Extra free-form metadata (mDebugInfo) has been added to assist
with logging / debugging.
Bug:140712361
Test: atest android.app.timedetector
Test: atest com.android.server.timedetector
Change-Id: I5305c34516e5f4e254309193183f00e054801a46
Make TimestampedValue Parcelable for simplicity.
TimetampedValue objects are not generally parcelable, depending on the
type of the value held. Previously, TimestampedValue did not implement
Parcelable to avoid committing to a general contract. Developers
parceling TimestampedValue objects were expected to call
TimestampedValue.writeToParcel() / TimestampedValue.readFromParcel()
explicitly when they knew it was safe to do so. This also meant that
TimestampedValues couldn't be used directly via AIDL.
This change makes TimestampedValue parcelable because it's more
familiar / convenient. Attempts to marshall a TimestampedValue that
contains a non-parcelable value will still throw a RuntimeException.
Bug: 140712361
Test: atest android.util.TimestampedValueTest
Change-Id: I8ca9c72f0433b380ce720cd813f650e743b3ddae
We were performing agent startup-attach during bind but this was too
late for some agents, as it occurred after Context was created. Change
implementation to make this occur prior to bind.
Test: atest CtsJvmtiAttachingHostTestCases
Bug: 142010970
Change-Id: I5f75e8b3c508116762b7863d9b47251d0e808ea9
There isn't much users can do to get app developers to care anyway, so
leaving this on just for apps with debuggable="true" should be
sufficient.
Bug: http://b/141754375
Test: treehugger
Change-Id: I3a796f9c4b9358fce499649c3f289e956ee9a97a
Only log once per change-package-state(resets every app launch if used
from within the app process).
Next: reset every app launch for server usage as well.
Test: using the test app.
Bug: 138374585
Change-Id: I5587f7138cf2cd8d144e88cf294e65c14bb32bfb
Add a new atom and log from both the app process API and the system server API
Bug: 136794938
Bug: 138378110
Test: statsd_testdrive 228
Change-Id: I80f07d0beb30c779c4bce70bebf2bb4ab22f6bfe
Merged-In: I80f07d0beb30c779c4bce70bebf2bb4ab22f6bfe
Add a new atom and log from both the app process API and the system server API
Bug: 136794938
Bug: 138378110
Test: statsd_testdrive 228
Change-Id: I80f07d0beb30c779c4bce70bebf2bb4ab22f6bfe
Merged-In: I80f07d0beb30c779c4bce70bebf2bb4ab22f6bfe
This reverts commit cfe38cdb1c.
The CL 8f712189dfc02285573337e2b4ab17678011db14 in libcore project avoids
the need for adding the new paths in LoadedApk. With the CL, a classloader
does not give up even when loader.findLibrary() has failed due to some
paths are not added to it. Instead, the classloader converts the given
libname into a filename (e.g. foo -> libfoo.so) then calls dlopen()
with the filename. The classloader reports failure only when the dlopen()
call has failed. Therefore, manually adding these paths to the classloader
is no longer needed and thus removed.
Bug: 109720125
Test: System.loadLibrary("adsprpc") is successful in Pixel (because
libadsprpc.so is in Pixel's vendor public lib list)
Test: atest cts/tests/tests/jni
Merged-In: I1970eba7e732728699042a36b89571915ec81451
(cherry picked from commit 37131e1ee6)
Change-Id: I1970eba7e732728699042a36b89571915ec81451
This reverts commit cfe38cdb1c.
The CL 8f712189dfc02285573337e2b4ab17678011db14 in libcore project avoids
the need for adding the new paths in LoadedApk. With the CL, a classloader
does not give up even when loader.findLibrary() has failed due to some
paths are not added to it. Instead, the classloader converts the given
libname into a filename (e.g. foo -> libfoo.so) then calls dlopen()
with the filename. The classloader reports failure only when the dlopen()
call has failed. Therefore, manually adding these paths to the classloader
is no longer needed and thus removed.
Bug: 109720125
Test: System.loadLibrary("adsprpc") is successful in Pixel (because
libadsprpc.so is in Pixel's vendor public lib list)
Test: atest cts/tests/tests/jni
Merged-In: I1970eba7e732728699042a36b89571915ec81451
(cherry picked from commit 37131e1ee6)
Change-Id: I1970eba7e732728699042a36b89571915ec81451
To prepare for enabling MissingNullability Metalava check this CL
works on adding missing nullability issues that metalava flags if
we tell it to flag new things since API 29.
This is not a complete CL, mostly addresses public api and
toString/equals for @SystemApi
Exempt-From-Owner-Approval: Large scale nullability clean up
Bug: 124515653
Test: make -j checkapi
Merged-In: I109260842cfc25f06e40694997fcbb4afa02c867
Change-Id: I109260842cfc25f06e40694997fcbb4afa02c867
To prepare for enabling MissingNullability Metalava check this CL
works on adding missing nullability issues that metalava flags if
we tell it to flag new things since API 29.
This is not a complete CL, mostly addresses public api and
toString/equals for @SystemApi
Exempt-From-Owner-Approval: Large scale nullability clean up
Bug: 124515653
Test: make -j checkapi
Merged-In: I109260842cfc25f06e40694997fcbb4afa02c867
Change-Id: I109260842cfc25f06e40694997fcbb4afa02c867
- Moved exclude filters to existing stanzas
- Removed new stanzas added w/ filters
- Removed un-needed filters because existing "include-filter"
already excludes failing tests.
Disabling in preparation for merge to aosp-master (Q release).
Disabling the following tests:
FrameworksCoreTests:android.view.textclassifier.TextClassifierTest#testSuggetsConversationActions_deduplicate
CtsAppTestCases:android.app.cts.ServiceTest#testAppZygoteServices
CtsAppTestCases:android.app.cts.SystemFeaturesTest#testLocationFeatures
CtsProviderTestCases:android.provider.cts.MediaStore_Images_ThumbnailsTest
Test: Forrest
Exempt-From-Owner-Approval: Disabling known failing TEST_MAPPING tests
for AOSP push to Q.
Change-Id: I4dc2408c5bc6d421654f871c5d63d402c1d96d91
Add ability to give 'startup-agents' that are automatically loaded
when a (debuggable) app starts. These agents are any files in the
'code_cache/startup_agents' directory. The agents are started with the
apps data_directory as an argument.
Test: Install debuggable apk (here com.antonioleiva.bandhookkotlin)
walleye:/ $ run-as com.antonioleiva.bandhookkotlin sh
walleye:/data/data/com.antonioleiva.bandhookkotlin $ mkdir code_cache/startup_agents
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libtifasts32.so code_cache
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libtifasts64.so code_cache
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libchainagentss32.so code_cache/startup_agents/
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libchainagentss64.so code_cache/startup_agents/
walleye:/data/data/com.antonioleiva.bandhookkotlin $ echo $PWD/code_cache/libtifasts32.so=log,ClassLoad > chain_agents.txt
walleye:/data/data/com.antonioleiva.bandhookkotlin $ echo $PWD/code_cache/libtifasts64.so=log,ClassLoad >> chain_agents.txt
Start bandhookkotlin
Examine logcat
Bug: 135627501
Cherry-picked from commit c0fce111c8b due to merge conflict.
Change-Id: Ib82b27df90c7964a995288d8b2b3d348a11cdd80
Merged-In: Ib82b27df90c7964a995288d8b2b3d348a11cdd80
Add ability to give 'startup-agents' that are automatically loaded
when a (debuggable) app starts. These agents are any files in the
'code_cache/startup_agents' directory. The agents are started with the
apps data_directory as an argument.
Test: Install debuggable apk (here com.antonioleiva.bandhookkotlin)
walleye:/ $ run-as com.antonioleiva.bandhookkotlin sh
walleye:/data/data/com.antonioleiva.bandhookkotlin $ mkdir code_cache/startup_agents
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libtifasts32.so code_cache
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libtifasts64.so code_cache
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libchainagentss32.so code_cache/startup_agents/
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libchainagentss64.so code_cache/startup_agents/
walleye:/data/data/com.antonioleiva.bandhookkotlin $ echo $PWD/code_cache/libtifasts32.so=log,ClassLoad > chain_agents.txt
walleye:/data/data/com.antonioleiva.bandhookkotlin $ echo $PWD/code_cache/libtifasts64.so=log,ClassLoad >> chain_agents.txt
Start bandhookkotlin
Examine logcat
Bug: 135627501
Cherry-picked from commit c0fce111c8b due to merge conflict.
Change-Id: Ib82b27df90c7964a995288d8b2b3d348a11cdd80
Merged-In: Ib82b27df90c7964a995288d8b2b3d348a11cdd80
Add ability to give 'startup-agents' that are automatically loaded
when a (debuggable) app starts. These agents are any files in the
'code_cache/startup_agents' directory. The agents are started with the
apps data_directory as an argument.
Test: Install debuggable apk (here com.antonioleiva.bandhookkotlin)
walleye:/ $ run-as com.antonioleiva.bandhookkotlin sh
walleye:/data/data/com.antonioleiva.bandhookkotlin $ mkdir code_cache/startup_agents
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libtifasts32.so code_cache
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libtifasts64.so code_cache
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libchainagentss32.so code_cache/startup_agents/
walleye:/data/data/com.antonioleiva.bandhookkotlin $ cp /data/local/tmp/libchainagentss64.so code_cache/startup_agents/
walleye:/data/data/com.antonioleiva.bandhookkotlin $ echo $PWD/code_cache/libtifasts32.so=log,ClassLoad > chain_agents.txt
walleye:/data/data/com.antonioleiva.bandhookkotlin $ echo $PWD/code_cache/libtifasts64.so=log,ClassLoad >> chain_agents.txt
Start bandhookkotlin
Examine logcat
Bug: 135627501
Change-Id: Ib82b27df90c7964a995288d8b2b3d348a11cdd80
Merged-In: Ib82b27df90c7964a995288d8b2b3d348a11cdd80
Force SurfaceFlinger to update synchronously by applying an empty
transaction. Without this, SurfaceFlinger will only update after the
next vsync, which may only happen after the instrumentation already
starts.
Since InputFlinger will only have the proper InputWindowInfo after
SurfaceFlinger updates, waiting for the vsync caused some
instruemntation tests to be flaky.
Bug: 138263890
Test: atest android.view.cts.HoverTest
Change-Id: I5457ab67ac574530dc1aa84549ca11e7e3f0d714
(cherry picked from commit 03dde38efc)
Force SurfaceFlinger to update synchronously by applying an empty
transaction. Without this, SurfaceFlinger will only update after the
next vsync, which may only happen after the instrumentation already
starts.
Since InputFlinger will only have the proper InputWindowInfo after
SurfaceFlinger updates, waiting for the vsync caused some
instruemntation tests to be flaky.
Bug: 138263890
Test: atest android.view.cts.HoverTest
Change-Id: I5457ab67ac574530dc1aa84549ca11e7e3f0d714
