Document that the addPersistentPreferredActivity method does Disk I/O
and so should not be called on the main thread.
Bug: 142648455
Test: m docs
Change-Id: Iadf2ab82f4f573e53ff68cad0b981494acf6f9b6
Currently only used by app-ops, but can be used by other modules too.
AppOps will collect app-ops based on feature. Only the most basic
parts of app-ops are supporting features yet. The rest will be added
later.
Test: atest CtsAppOpsTestCases
atest RunSettingsLibRoboTests
atest com.android.server.wm.ActivityStarterTests
m -j doc-comment-check-docs
Bug: 136595429
Change-Id: Ia664f4ff1c1c2ceea721d76dc491ec50c237e9ce
This change kept AppWindowTokenTests as it's originally based on top of
WindowTestBase, and merging that into ActivityRecordTests needs to
change the base class to ActivityTestBase, which requires additional
work and may change test behaviors. Therefore delay that to
follow-up CL.
Bug: 80414790
Test: Existing tests pass.
Change-Id: I6d73975ee77be9817c41b297f067de2d92a68499
* Remove USE_BUGREPORT_API check that enabled us to switch between
legacy bugreport flow and API workflow.
* Undeprecate requestBugReport flavors as these will not be deprecated.
Initially it was aimed to remove these methods and use the API
directly. But now these methods have all been migrated to
use bugreport API.
* Add @BugreportParams annotation for requestBugReport function.
* Title and Description are communicated via the broadcast instead of
setting system properties.
* Description is not a system property anymore, so add a check on its
length by defining MAX_BUGREPORT_DESCRIPTION_SIZE.
Bug: 137825297
Test: Takes interactive and full bugreport as expected
Change-Id: Ib96ad774f5e21491c0dad82cb2292960aa45d6d0
The documentation for the setPermittedAccessibilityServices method
attempted to explain that system accessibility services cannot be
disabled but the sentence did not make sense.
Bug:
Test: m update-api && m javadoc
Change-Id: I84d27a8c281551bbd8a82621234cd49e205956a7
1. decouple IOnSubscriptionChangedListener AIDL from telephonyMainline
2. other refactor. moving APIs which will not be included in
telephony mainline to frameworks/base/core/java/android/telephony.
Moving internal classes like AIDL which will not be included in
telephony mainline to
framework/base/core/java/com/android/internal/telephony
Bug: 140908357
Test: Build & unit test
Change-Id: I9413ef758cceadd251d03f3b5ea1054cc48ef044
The periodic parole window is the 10 minute window that occurs every
24 hours to let RARE apps run. Now that we have the quota system in
place, there's no need to have the periodic parole window. Alarms and
jobs will still be allowed to run when charging. Network will continue
to be restricted for RARE apps even when charging. JobScheduler requests
an exception for RARE jobs in quota, so they will still be able to run.
Bug: 136184981
Test: atest AppStandbyControllerTests
Test: atest CtsAlarmManagerTestCases
Test: atest NetworkPolicyManagerServiceTest
Test: atest com.android.cts.net.HostsideRestrictBackgroundNetworkTests
Test: atest com.android.server.AlarmManagerServiceTest
Test: atest com.android.server.AppStateTrackerTest
Test: atest com.android.server.job.controllers.QuotaControllerTest
Test: atest com.android.server.net.ConnOnActivityStartTest
Change-Id: Ide382ad7fb9c7441f0a5232833ad39bf8c3a1e94
* <p>
* Throws a SecurityException if policy access is granted to this package.
* See {@link #isNotificationPolicyAccessGranted}.
The security exception should be thrown when policy access is NOT granted
Test: no test required. documentation change only
Fix: 138459179
Change-Id: I980392104cb38e921b6eafd1a8897b374e73b83c
1. PasswordMetrics now doesn't have 'quality', it is only used inside DPMS.
This allows easier and unambiguous comparisons.
2. Password complexity code reworked.
Future work: factor validation code into a android.app.PasswordPolicy class
to make PasswordMetrics just represent metrics. It is still used in two ways:
specifying an actual metrics and specifying a minimum metrics for comparison,
this will be addressed later.
Test: atest com.android.cts.devicepolicy.PasswordComplexityTest
Test: atest com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testResetPasswordWithToken
Test: atest FrameworksCoreTests:PasswordMetricsTest
Test: atest FrameworksCoreTests:PasswordPolicyTest
Test: atest com.android.cts.devicepolicy.ManagedProfilePasswordTest
Bug: 138375712
Change-Id: I8ad55f373712ac1dc8343f8cbae23ebb1efe78b9
for oems which take telephony mainline module, all telephony related
apks will be signed with non-platform certificate. that said apks won't
be able to grant platform signature permission. Solution is to add a new
telephony protection level.
Bug: 141479803
Test: cts & manual
Change-Id: Ib3be016080d42fd76e7c131f4e44d815ce431e6e
ResourceLoaders allow inserting another .apk/.arsc into AssetManager's
resource resolution search. The effect is similar to overlays,
where a entry of >= config later in the path list will return that
ApkAsset's resource value instead.
Because loading from an .arsc is supported, which doesn't contain
any actual files, ResourceLoader exposes loadDrawable and
loadXmlResourceParser to allow an application load those files from
anywhere or create them in code.
The data being loaded is either pushed into an .apk or .arsc that
mocks itself as the package being "overlaid" and is passed in
through ResourcesProvider, an interface with static methods that
supports loading from a readable path on disk or a FileDescriptor.
The APIs are accessed through a Context's getResources(), which
has been changed to be unique per "Context-scope", which is usually
the lifetime of the Java object. The exception is that Activities
who get their Resources object persisted across recreations
maintain that logic for persisting ResourceLoaders.
Bug: 135270223
Test: atest FrameworksResourceLoaderTests
Change-Id: I6929f0828629ad39a21fa155e7fec73bd75eec7d
Without it, apps (mainline modules) will need to use createPackageContext...,
which is a bit painful.
Bug: 142472686
Test: atest android.content.cts.ContextTest#testCreateContextAsUser
Change-Id: Id640e03862462724df1a4a3101f0b08faafba22f
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
