Replaces the default Toolbar in SettingsActivity with one that looks
like a search bar. It uses a Toolbar inside a CardView with some custom
styling.
Since the search bar is a floating element, the new toolbar lives in the
content frame of the dashboard. A FrameLayout is used to provide the
layering that is desired.
Since the search bar is on top, an additional spacer view is added to
the list of items in the dashboard. Its color changes based on what
the first view is so that it always matches.
Adds android-support-v7-cardview as a dependency (and reorders the
other deps to be in alphabetical order).
Remaining work (in future CLs):
- remove search menu option?
- clean up initial window
- remove the line between the header and the first condition
when there's a condition
Change-Id: I627b406735c8e2280ac08f44ca32f7098621a830
Merged-In: Id7477b90fbaf30eb5cac1ee244c847bddb95b3fd
Bug: 37477506
Test: make RunSettingsRoboTests
Bug: 62133292
Test: make RunSettingsRoboTests -j100, and manually verified FR is
available in carrier demo mode.
Change-Id: Ia793bf234b229da0490accfea6d44b72395a04bc
Cache was being counted as cache and also as data in the app info page.
This is due to a faulty assumption I made that getDataBytes() and
getCacheBytes() measured distinct areas of storage (in actuality,
getCacheBytes() is a subset of getDataBytes()). This improper assumption
also led to the unit test being incorrect.
Change-Id: I4144d50800f82feaecb7a0a8dff26be3e4f14da8
Fixes: 62182151
Test: Settings robotest & manual
Fix several bugs related to storage accounting. Since getDataBytes()
already includes cached data, we need to subtract it to avoid blaming
apps for it.
We also need to blame app code on someone, so we blame it on the
current user. StorageStatsManager was fixed awhile back to only
return the app code size on the requested storage volume, so we can
remove the system app checks.
Subtract "appBytes" from external storage accounting, since it's
already been blamed elsewhere against specific apps.
Pass along storage results from all users on the device, and subtract
them all when estimating size of "system" data. To avoid embarrassing
estimation bugs, make sure that "system" data is at least 1GB.
Bug: 38008706
Test: cts-tradefed run commandAndExit cts-dev -m CtsJobSchedulerTestCases -t android.jobscheduler.cts.StorageConstraintTest
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Change-Id: Ide1e6d0690e5ad4e751c87891f63ba1036434619
If there is a managed profile, launchers that don't support managed profiles
cannot be selected as default Home
Change-Id: I7a19b5951402ec87a48464d783a539a607adabfe
Fix: 62013411
Test: m RunSettingsRoboTests
The override filter for storage to ensure that we filter by UUID and
user id was designed as an override filter. This worked as long as there
never was any other filters which could be used out of Storage Settings.
It turns out the instant apps filter applies here.
As a result, I've moved these filters into being "composite filters"
which are composed with the primary filter instead of overriding the
primary filter.
Fixes: 35245772
Test: Settings Robotests... but as for the composing part it is
b/34768986
Change-Id: I6f5acb909568ab02e81187c09fdda9533d635781
Then we could make sure the app list is sorted
Bug: 62035385
Test: RunSettingsRoboTests
Change-Id: I3fa3d6ffc5930cf011e382632143e459fdbc4369
Merged-In: I3fa3d6ffc5930cf011e382632143e459fdbc4369
The reason for NPE is that callback is registered too early, so
one callback is invoked before controller is fully inited. This
cl fix it in two ways:
1. Add NPE check in refreshUi, since this method in InstalledAppDetail
is robost to NPE
2. Move the callback to the end of constructor.
Bug: 37913054
Test: RunSettingsRoboTests
Change-Id: I54b03fb51a958a8e63bfe8a7ccfda79be1fa1956
User can navigates to the page and turn hotspot on or off from the quick
settings. Need to listen to the tether state updates to refresh the
summary for the Hotspot & tethering preference accordingly.
Change-Id: I7c6869b909306b09556e19cf7b7543ce9dcd890e
Fix: 38452559
Test: make RunSettingsRoboTests
The preference framework does not remove pref recursively. So when a
preference is nested in preference hierarchy, it's not safe to simply
call screen.removePreference(). We need to first find its parent and
remove pref from its parent.
Change-Id: Ic7fefa498ed71a8877d862845ddcc2d6d6034a55
Fix: 38507066
Test: make RunSettingsRoboTests
Before this cl, user could go to "Battery usage" page only if
related app has battery usage. This cl breaks this rule so we
could open "Battery usage" without battery data.
Bug: 38497822
Test: RunSettingsRoboTests
Merged-In: Ic53c33b7dcbac82de58f31cf96e0bd8fa54e53ea
Change-Id: Ic53c33b7dcbac82de58f31cf96e0bd8fa54e53ea
