- Don't clobber the state if we are deferring resizing due to finishing
activities.
- Fix issue with PiP tasks being visible after the stack is removed, due
to it being put below a non-fullscreen task in the fullscreen stack.
Instead just move it to the back of the stack.
Bug: 36592307
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: Ia18fe155b8a045a8ffea84612fd08af3ef3982d8
When resolving activtities for the USB device/accessory connection UI a
special intent that allows to switch between profiles get added. This
also gets added if there is no activity in the secondary profile that
can be started.
Fixes: 36544815
Test: Added work profile. Add USB handling app only to personal profile
and plugged in USB device -> no crash anymore
Change-Id: I311ddd53b3ff0c8406e62bac57972d4b790ebddc
Do not dispose Bridge on tearDown. The concept of disposing the Bridge
only made sense when we were loading it dynamically. Some classes have
static initializers that will fail after the dispose (like Typeface).
Test: N/A
Change-Id: I9c934432232bda02a4d26425587096fb6dc957b0
(cherry picked from commit f1532e36e16e2b55f175a24f11df91cf344833ff)
Intents triggered from QS should be resolved as the current user,
not as the user that QS is running as (which will always be user 0).
ActivityStarter knows how to do this and can handle this for us
automatically.
Bug: 36118203
Test: Manual
Change-Id: I48d880f0a17d7a9f218ab07ef807ad49ebeda624
Tests various combinations of empty / non-empty NetworkSpecifiers
and changing specifiers on the fly.
Test: ConnectivityServiceTest passes
Bug: 27533960
Change-Id: Ibd6b4efc861dc51689e46f3882ba859223411bf0
Previously we can have duplicated tasks sharing the same taskId in
RecentTasks due to race condition.
1. A task is created before RecentTasks#loadUserRecentsLocked
(e.g. through adb)
2. RecentTasks#notifyTaskPersisterLocked eventually writes the task file
to storage (e.g. XX_task.xml)
3. RecentTasks#loadUserRecentsLocked tries to recover XX_task.xml while
the task has already been added to RecentTasks.
To fix the issue, the CL stops restoring tasks added before recent is
loaded.
Bug: 36796576
Test: Build and boot Android, check the recent is correctly loaded
Change-Id: Ib57977f2a0a63f7bf7db4d3fd70bdcc359e76f7d
UserManager may not have been started yet, so discover users by
looking at filesystem.
Fix disabled bug where default should be "false."
Test: builds, boots
Bug: 36794413
Change-Id: If91fd27b955175072228a93aab4b8ac3b27df0bf
It's confusing, but f_bsize is not the value you're looking for; the
real block size is f_frsize. Fix all those bugs.
Also, the vast majority of clients are interested in the usable
disk space, not including reserved space.
Test: builds, boots
Bug: 36840579
Change-Id: Ib1470389afd49c14cab62282ec1e978ebb2c4791
Previously FuseAppLoop instantiates Runnable for each command, which
causes lots of instantiation and GC.
Test: CTS
Bug: 35229514
Change-Id: Ifea098e5ade044b1a954c0b714c5b3270a95cd1a
Some system services are offering package usage data through both
public/system APIs and through dump() calls. In principle, usage
data hould always be protected with PACKAGE_USAGE_STATS, so start
enforcing that. (Otherwise if a user blocked PACKAGE_USAGE_STATS
access to an app, that app could still obtain the data via dump()
if they held the DUMP permission.)
Bottom line, let's respect the user's wishes.
Protecting the entire output like this is pretty blunt, but future
CLs can add more nuance to the output if desired.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: I46173562713bea7d89e12a4313c78eb52ea8d77d
This change introduces new methods on DumpUtils that can check if the
caller has DUMP and/or PACKAGE_USAGE_STATS access. It then moves all
existing dump() methods to use these checks so that we emit
consistent error messages.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: Iaff6b9506818ee082b1e169c89ebe1001b3bfeca
Previously FuseAppLoop instantiates Runnable for each command, which
causes lots of instantiation and GC.
Test: CTS
Bug: 35229514
Change-Id: Ifea098e5ade044b1a954c0b714c5b3270a95cd1a
