All of these activity-start intents might be unimplemented on some
Android products. Document this to make sure that developers are
aware of the need to safeguard against this.
Bug: 68300743
Bug: 62201251
Bug: 69587018
Fixes: 77282739
Test: atest CtsContentTestCases:.AvailableIntentsTest
Change-Id: Ia2346d03ccb7f2bdad2b84ba9efff72413fdc3c2
This change adds much needed detail to the new MATCH_EXTERNAL flag,
explaining some of the behavior changes that come with using it.
Test: none
Bug: 63117034
Bug: 79325769
Change-Id: Iab320d2171ffe8d8012a2928656ea61d5e0f0862
Micro-optimization: Instead of using a new instance of "#" and "*", reuse the
String literals. This will save 18 bytes for each "*" and "#" used in Uri
matchers.
Also, use switch/case rather than if/else for string matching.
Finally, add test and move TestClass in same package.
Bug: 32502682
Change-Id: Id672138a2213f68e05cafb4e88ed3c1e61c735a4
Test: Unit test
source build/envsetup.sh
lunch aosp_x86-eng
m -j 8
emulator -system out/target/product/generic_x86/system-qemu.img
make FrameworkCoreTests
adb -e install out/target/product/generic_x86/testcases/FrameworksCoreTests/FrameworksCoreTests.apk
adb -e shell am instrument -w -r -e class android.content.UriMatcherTest com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
(Minimal change for P, full change already in master)
Test: looked at package installer UI and saw that labels are not
truncated anymore.
Bug: 77964730
Change-Id: Ia181288a90501f4f563d24dacd6edb0c81406b82
Teach the OMS about static RROs (those with <overlay isStatic="true">)
and add a new OVERLAY_ENABLED_STATIC state to OverlayInfo. This makes
isStatic less of an edge case and something that can be reasoned about
together with the other states.
Bug: 78809704
Test: atest OverlayHostTests OverlayDeviceTests
Change-Id: Ia785554ed2bcf7679888c3ccdaeaedca1430a477
When an overlay package has been upgraded, OMS needs to reconcile any
previous settings about the overlay with the new state of affairs.
Sometimes it is possible to rebase the OMS settings on the new
information [e.g. the overlay has changed categories]; sometimes the OMS
settings have to be scrapped [e.g. the overlay has changed target
package]. Update OMS to do The Right Thing.
Bug: 78809704
Test: manual (adb shell stop, adb push specially prepared overlays, adb shell start, adb exec-out cmd overlay dump)
Change-Id: Icd1ae633dbee5b5ca957fa6b652af6209b4b1260
OverlayInfo.category was inadvertently omitted when calculating the hash
code for an OverlayInfo.
Bug: 78809702
Test: atest OverlayHostTests OverlayDeviceTests
Change-Id: Id196307f75569d851503ffd8ef778aec50c2de37
Also remove all references to old loadSafeLabel method to prevent
proliferation of old method via copy+paste.
The implementation assumes that there are three cases:
- Short labels that don't have anything wrong with them
- Labels that are fine, but are a little too long
- Intentionally bad label that try to break stuff and slow things down.
In the first two cases no characters are marked for removal, in the
third case we have an implementation that does not use a lot of memory
and has linear performance when there are a lot of bad characters.
Test: gts-tradefed run gts-dev -m GtsContentTestCases
Bug: 77964730
Change-Id: I3feb17b2a12018cd5407c88fe3603f2ebbc9d14e
This doesn't make sense on things like watches and appliances,
so make this an optional feature that the device must enable.
If the feature is not set, then the system will ignore
the app's request.
Bug: 76213401
Test: atest CtsAppTestCases:ActivityManagerProcessStateTest
Change-Id: I91abf9d86ec14fa632e3bcc83c4a3febade5d2e4
* limit the absolute maximum size of the label to 50000 characters
[which is probably far more than necessary, but, can be dialed down]
* use a string buffer while processing the string [instead of creating
multiple string objects]
Bug: 62537081
Test: Manual. Install APK in bug and see that it can be uninstalled
Change-Id: Ibf63c2691ad7438a123e92110d95b1f50050f8b1
In certains circumstances, only the base and split APKs were included in
the "old paths" list when updating the application info. Instead, this
list should contain _all_ elements, including any additional libraries
that may be added to the overall classpath.
Bug: 77342775
Test: Manual. Install a package. Install a split with --dont_kill. See that the path doesn't contain duplicate entries
Change-Id: Id9739cce215ab07bff1b17966583c0cf51a0b34a
Periodically remove references from the list whose referents have been
garbage collected.
Bug: 73961798
Test: Device boots.
Test: Take a heap dump of systemui and manually check that the state of
ThemeRefs looks reasonable.
Change-Id: I691027feb5dd217bcb60406b28897b9614e2a845
Clarify that the method does not imply the screen is color-managed.
A global color transform may still be applied depending on the user
settings, such as night light, accessibility, Boosted, or Stretched.
Bug: 78012876
Test: builds
Change-Id: Ie9cdf455cf4ca93be2357a5313cd63555ab91ff9
- So that AM can perform all the necessary caller checks, except for the cross-profile/user check.
- Note PixelLauncher is the recent app which gets extra privileges. So I used ShortcutLauncherDemo
and a 3p launcher for manual tests.
Fixes: 78635323
Test: manual test, with a 3p launcher. (nova)
- Launch primary profile app -> launches fine
- Launch work profile app-> launches fine
- Launch suspended work profile app -> "can't open this app" dialog is shown.
- Launch the primary counterpart of the suspended work profile app -> launches fine.
- Launch work profile app in quiet mode, with separate work challenge
-> "turn on work profile"? dialog is shown
-> then "cancel" -> nothing happens.
-> then "turn on" -> "re-enter your pin" is shown -> type pin -> work profile app starts fine.
- Launch work profile app without separate work challenge
-> "turn on work profile"? dialog is shown
-> then "cancel" -> nothing happens.
-> then "turn on" -> work profile starts and the app starts fine.
- "App info" on work profile app -> Setting page opens fine.
- "App info" on primary profile app -> Setting page opens fine.
Test: atest frameworks/base/services/tests/servicestests/src/com/android/server/pm/ShortcutManagerTest*.java
Test: atest cts/hostsidetests/devicepolicy/src/com/android/cts/devicepolicy/LauncherApps*.java
Change-Id: Ie665a8890407d05c1d877f04d9c5c3a1caad18e1
Incoming and outgoing call phone numbers are visible in the phone state
broadcast and via the PhoneStateListener. To enhance user privacy, change
to require the READ_CALL_LOG permission in order to receive the call
phone numbers.
This means to see phone numbers:
1. android.intent.action.PHONE_STATE - requires READ_PHONE_STATE and
READ_CALL_LOG permission.
2. PhoneStateListener#onCallStateChanged - now required READ_CALL_LOG
permission.
To support this new behavior, added sendBroadcastAsUserMultiplePermissions
method to context to allow sending the broadcast to all users while
requiring the two permissions.
Bug: 78650469
Test: Created PHONE_STATE broadcast receiver in test app and verified that
when no permissions are granted, the phone number is empty for incoming
and outgoing calls.
Test: Granted Phone state permission to test app and verified that phone
number is not populated.
Test: Granted test app read call log permission and verified that phone
number is populated.
Test: Created PhoneStateListener in test app and verified that when no
permissions are granted, phone number is empty for incoming and outgoing.
calls.
Test: Granted read call log permission to test app and verified that both
the incoming and outgoing numbers are populated.
Change-Id: I857ea00cc58a0abbb77960643f361dd6dd9c8b56
APIs that return package usage data (such as the new ArtManager)
must ensure that callers hold both the PACKAGE_USAGE_STATS permission
and the OP_GET_USAGE_STATS app-op.
Bug: 77662908
Test: atest vendor/xts/gts-tests/hostsidetests/dexapis/host/
Change-Id: I7a85d959f1682d2bd5cf3684415e368fece88101
