These are now available as user restrictions.
Bug: 113298946
Test: make RunSettingsRoboTests -j100
Change-Id: I637083c8edcf43b99cebbf5a7dfd60afee441ade
This patch focused on fixing compile errors and some runtime errors.
Test: We can't test it now. But we will have an integration test later.
Bug: 110259478
Change-Id: I16c471ddcd0fa1460c665b7f74d86fcace5ee67b
getPreferenceControllers() -> createPreferenceControllers() for the same
reason as in ag/3647936
Bug: 73668763
Test: robotests
Change-Id: I97670a91a2a38d1c844d1b9d37f4222c5e6f45a0
This implements an explicit toggle to enable/disable automatic 12h/24h
time formatting detection based on the current locale.
Previously automatic detection was the norm on a freshly wiped device,
but could never be re-enabled once either 12h or 24h format was
configured.
Bug: 32761619
Test: m RunSettingsRoboTests
Change-Id: Idbbb8f79fccec95e33bf2f12767d5736e1118fa7
Use the centralized registry to look up category key instead.
Bug: 32936784
Test: make RunSettingsRoboTests -j40
Change-Id: I0b8c72d70f93e4b5c58871ac90de41f69ad15653
In settingslib, now the two public functions in ZoneGetter have
the same logic(display the same name based on locale). This cl
is to deal with changes in Settingslib.
Bug: 19764807
Test: ag/1490275
Change-Id: I3e1c0bface752dc2ef4653ff58c4639c262964c1
Bug: 30681771
Test: SettingsUnitTests
Refactor visibility logging from InstrumentedFragment into a mixin. And
apply mixin in remaining fragments.
Change-Id: Ibbb59904336254a3e4bb9e8c7d0b36e5a6bc2622
When running in demo mode, additionally disable
the following settings screens:
- Date & Time
- More (network settings)
Bug: 27280140
Change-Id: I3132d0c46b24e1e9ca3842af058073eee3df0c90
Almost all of our date formatting goes via icu these days, so this is
a no-op almost everywhere. (And should be a no-op everywhere soon.)
There's no obvious way to fix it, so remove it. UI guidelines say we
should use spelled out month names anyway.
Bug: 18322220
Change-Id: Ic9e903eceab3c096426f313bf4ef3a38644774e1
Per UX request, use a Switch for:
- Automatic date & time
- Automatic time zone
- Use 24-hour format
Change-Id: Ie35816febe2469705446fdd2c703b52ff8b0929a
We fixed this for Settings in 7ccfa0614c,
but @sonymobile.com point out that it's still broken for SetupWizard.
Change-Id: I59348200105246f3ed7c0892e5f19b901d3e95ac
In case of using DatePickerDialog, user could select any date
before 1970-01-01. However, the system clock cannot be set to
a date before 1970-01-01.
As a result, user couldn't select date before 1970-01-01.
So, use date from 1970-01-01 to 2037-12-31 of DatePickerDialog.
Steps to reproduce:
1. Settings -> Date & time
2. uncheck Automatic date & time
3. Set Date
4. choose any date before 1970 and Done
Change-Id: I075b3fcaa86df1c314c85dd3dd85474a28b8c637
This way secondary users' settings app can request the system server to
set the time. Alarm driver cannot be opened as a secondary user.
Bug: 7459635
Change-Id: I1ae1630dc448021d35280a297c5d9960f8e8fc2e
Changed the way that date format selector is shown excluding ambiguity when day and month have same value.
- i.e. 01/01/2012 (mm-DD-YYYY) and 01/01/2012 (DD-mm-YYYY)
Now it displays 31/12/2012 for DD-mm-YYYY and 12/31/2012 for mm-DD-YYYY.
Change-Id: I27434c9d5713491950d4f345dccf65d647d399cf
The original code was actually correct, but code calling inDaylightTime
and getDSTSavings directly is inherently suspect, so I want to clean up
this false positive along with the real abusers.
Bug: 6901488
Change-Id: I6c89e7aa29d88b81ed2c7fd6c915e0346b90a442
Didn't have an API for this before so people used a hacked system property (ro.carrier)
to determine if the device supported mobile data. Added new API and switching callsites.
bug:5087537
Change-Id: Ibd799559be102a9e2fd552d1a23d1afbcf8f4614
If the timezone changed too far, the example date would be "1/1/yyyy+1"
instead of "12/31/yyyy"
Move the setting of the Calendar time to where the string is calculated
to make sure we have the most up-to-date Locale.
Bug: 4596841
Change-Id: I67a253a65b1ea03ee717945c5df819beb8515662
Adjusted the screen size test to fall back to phone version of
DateTimeSettingsSetupWizard on large screens.
I made the following changes from how the phone version works:
1. Some layout changes. (Tablet look, bigger margins.)
2. Use zone picker to select time zone.
3. Added isFirstRun boolean extra to hide the pref fields
we don't need to see from setup wizard
Furthermore, I made the following fixes to the existing phone flow
(which had probably never yet been tried on a phone):
1. Added conditionals around access to some variables that only
exist in the xlarge layout.
2. Implemented PreferenceFragment.OnPreferenceStartFragmentCallback
in DateTimeSettingsSetupWizard in order to catch the user tapping
on the timezone preference and show the time zone picker popup.
(Note: for phones in ICS, we might want to launch the zone picker
preferences style, like it would have been had this been a
PreferenceActivity. Or maybe we should just create a separate
DateTimeSettingsSetupWizardPhone activity that subclasses
PreferencesActivity and doesn't need to play this trick.)
Change-Id: Ib5774a005c9f44d730d86c13746d91eb712141cc
Bug: 3488384
Bug: 3487976
Bug: 3488381
Removed Cell standby entry from Battery use screen.
Removed Mobile signal strength from BatteryHistory screen.
Added wifi IP address to About->Status
Remove auto-timezone checkbox in Settings->Date & time
Change-Id: I228721a3613b1aeb600026e42274337886552698
Bug: 3173067 - Auto timezone checkbox out of sync with dependency
Bug: 3175116 - Crash when launching Manage Accounts screen
Move "Add Account" to a menu item from a button at the bottom.
User can now enable auto-time but disable auto-timezone, especially
if we don't have NITZ time from the cell network (or wifi only)
and only have NTP time that gives us date and time.
