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
We're wrongly showing the BigText content after ag/5928752
Fixes: 141446552
Test: post big text notification, look at lock screen
Change-Id: I02506a160afefb457f86eb00adccdaff44ddbd29
And also pre-grant it to all apps that currently get any storage
permission pre-granted
Test: atest SplitPermissionTest
m -j gts && gts-tradefed run commandAndExit gts-dev -m GtsPermissionTestCases --test=com.google.android.permission.gts.DefaultPermissionGrantPolicyTest#testDefaultGrantsWithRemoteExceptions
Manual testing:
All combinations of
- App targetSdk = 28 and 29 (and 22 for extra credit)
- App having the <uses-permission> tag for
ACCESS_MEDIA_LOCATION or not
- Upgrade from P->Q-QPR and from vanilla Q->Q-QPR
Further upgrade of targetSdk from 28->29 while on Q-QPR
==> All permission behavior should make sense. Sometimes there
are weird, but expected behaviors. Hence we need to
collect the results and then look at the unexpected ones.
See SplitPermissionTest for some tests I added for the
location-background permission which was split from
the fine/coarse-location permissions
Fixes: 141048840,140961754
Change-Id: Ib9f50d25c002036f13cf2d42fc4d1b214f20920c
- Make flags is the last parameters in access decipher methods.
All calling code assumes this.
- Get proxyUid info from the appropriate field
- Don't create proxy entries if uid is invalid
- Fixed some incorrect docs
Test: adb shell dumpsys appops now shows proxy information
Fixes: 141328071
Change-Id: I2f94e9b171133141643e628c9224d8d74ec5ad87
