Before this cl, we use the first package name if there is a name
list in BatterySipper.
We should use BatteryEntry.defaultPackageName instead, which could
describle the batterysipper more accurately.
Bug: 62417935
Test: RunSettingsRoboTests
Change-Id: I44fa151c0cf8f14cba305f179c7e94e5bc3ce434
This removes the jitter when the cache is empty and there is
initially no summary, and then it is replaced by the fetched summary
when it's available.
Bug:36463348
Test: make RunSettingsRoboTests
Change-Id: I92cafbf23e3c562a470488dea28fd5106bbdf885
This reverts commit c1e9f8787f.
Reason for revert: There is an issue when dropdown menu text has a '%' sign in it.
Despite testing it on my own devices, the bug did not show up immediately.
Instead of continuing down this path for OC, we'll just revert
this patch, and then as an ugly, band-aid solution, check the
summary text for the "%s" substring, and hide it when found.
In O-DR onward, we'll look for a more permanent solution.
Change-Id: Ia7a04bfb7b09c436dc0f13564f2134a1f0c436e2
Bug: 36101902
Fix: 62211676
In order to hide dynamic summaries which use SettingPref,
we check if the summary is equal to "%s".
This is a temporary, band-aid fix which should be
changed in the next release.
Bug: 36101902
Test: make RunSettingsRoboTests
Change-Id: I6cadb3ba68f09ba18ad9a6d2a817804c5d4a08e5
1. Set mNetwork before the NetworkCallbacks can be delivered.
Previously, the code would set mNetwork in updateInfo, relying
on the fact that the BroadcastReceiver registered in onResume
is immediately invoked. However, this races with the
callbacks, which are also immediately invoked. If the
callbacks won the race, mNetwork would not be set and they
would be ignored.
2. Call updateInfo in onResume instead of in displayPreference.
This ensures that it's always called exactly once before the
activity starts running, regardless of whether it's being
displayed the first time (i.e., after onStart) or resumed
by switching from another app. displayPreference is only
called in the former case.
3. Don't call getLinkProperties and getNetworkCapabilities in
updateInfo. These calls are superfluous, because this
information is update by the NetworkCallbacks, and they can
cause jank because updateInfo is called on the UI thread.
This requires that the tests be changed so they always call
onResume, since no UI elements are populated until onResume is
called.
Bug: 62209358
Test: make -j64 RunSettingsRoboTests
Change-Id: Iccb1b9ae51188755d890a6df83004dbe9bec565e
When user update the setting for flip camera, check if there is managed
profile for the user, and update the setting for the managed user id as
well, so that the work profile camera app can read the correct setting
value.
Change-Id: I757041289329870311bc8473b19fd49ecdd0fadb
Fix: 62078588
Test: make RunSettingsRoboTests
- replace it with ConnectivityManager.stopTethering() instead.
Change-Id: I112863b1be37c0fef5d59c16d73f0c6cf71c6dea
Fix: 62191978
Test: make RunSettingsRoboTests
This stops the AP summary from getting stuck on "Connected, no
Internet" even when the system has validated Internet access.
Bug: 62209358
Test: make -j64 RunSettingsRoboTests
Change-Id: I235404408f7d8b958653d25656d97da8206e35ce
We need to refresh batterystatsHelper in onResume, so we need to
call restartLoader instead of initLoader
Bug: 62237848
Test: RunSettingsRoboTests
Change-Id: I6f7e1b57b945c92d34587ca24db192600e7f797f
Merged-In: I6f7e1b57b945c92d34587ca24db192600e7f797f
The admin of a manged device can take a number actions that will be
listed in the "Changes made by your organization's admin" section of
Settings. If the admin has not taken any such actions, the section
will be empty and should be hidden. This is accomplished by having a
PreferenceController for the section that observes the state of the
PreferenceControllers inside it.
Bug: 35912953
Test: m RunSettingsRoboTests
Merged-in: Ia95754493ee6c5a19b4aa9731fd56fd558e61849
Change-Id: I82ca00b757001390f9a517b0c07057bdc49dab20
Add makeNetworkCapabilities and updateNetworkCapabilities
methods, and use them. These are not very useful in the current
code but we introduce in their own CL to limit test changes in an
upcoming CL that will make use them to test new code.
Bug: 62209358
Test: make -j64 RunSettingsRoboTests
Change-Id: I67269e1add40ecb3c2b693548e8bf29ae776a79f
The method that crashes is removed in O-DR, and thus
does not need to be merged down.
Change-Id: If30bd8bd92d578133984f7f35e7ec5288adfc390
Fixes: 62100634
Test: make RunSettingsRoboTests
Merged-In: Id36f7bf4ceaaa3a2bd326ecafbfe97fd0b247df2
Styling doesn't look exactly right yet but there's a bar.
Creates an ItemDecoration to add a spacer above the first view.
Removes the action bar and replaces it with a SearchView
inside of a CardView.
Remaining work: pixel pushing
Bug: 37477506
Test: make RunSettingsRoboTests
Change-Id: Ibf38c3c2725551bc4cd90e98d0020ec49c2eab2b
Merged-In: I4a0f0c91c51ff5820b61a596520d80a3337c3466
At the moment we include disabled profiles when deciding
whether the Work section needs to be added, and then only
include enabled ones when searching for the managed profile's
user handle
Change-Id: I96b0c36aad6b9326abc2992fa3309716f5cd1e74
Fix: 62021410
Test: m RunSettingsRoboTests
Currently, when anything changes, the wifi detail status page
removes and then redraws all IP address information. This causes
the whole screen to flicker. Instead, only add and remove things
when they actually change.
In order to do this, convert the IPv6 addresses from a list of
Preference objects to a single newline-separated text field.
This removes the need to keep track of addresses as they are
added and deleted, and also looks a bit better.
Also, minor correctness fixes:
- Get the gateway from the default route, not from the last route
with a non-null gateway.
- Get the IPv4 subnet mask from the IPv4 address prefix, not from
the last route with prefix length > 0.
Bug: 62171690
Test: make -j64 RunSettingsRoboTests
Test: IP information does not flicker when signal strength changes
Change-Id: Ia9f2a277e53a2800407ae327701c5b95a9eec20a
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
OEMs can now force grey out the "disable" button for important apps on
device.
Change-Id: I8ea431b52e50e424be55946f70175db5412e2f4a
Merged-In: Ic075a07ad12592bd60238c7b1c9ab84932c8db3c
Fix: 38250742
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
This is a test-only change whose goal is to increase our
confidence in future changes that touch the actual code.
Bug: 62171690
Test: make -j64 RunSettingsRoboTests
Change-Id: Ic5122453c9fec2b166fcfe0c5c33be2705c10906
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
