- follow the UX spec by no more using a Drawer
- the Dashboard is now a Fragment that contains the list of Headers
- the search results are also put into a Fragment that is replacing
the initial one (Dashboard or other) when expanding the SearchView
- use a SearchView for query input
- when tapping on a Header or a Search Result, re-launch Settings as
an Activity so that we are benefiting from the Activity stack for
UP affordance and BACK button
- manage UP affordance to show it only when needed
- move some Actions to the Menu in the ActionBar for allowing space
to the Search action and removing some clutter
- fix an issue with the Index and WiFiEnabler and their cached Context
that was not updated when there was a Configuration change
- simplify the SettingsActivity code by extracting some inner classes
Change-Id: I50b5f77bb44a7fade1886114dbbc820609a5e63d
- define SettingsSearchIndexablesProvider as an internal
SearchIndexablesProvider
- protect access thru using android.permission.READ_SEARCH_INDEXABLES
- update WallpaperTypeSettings and WifiSettings for taking care of
the new model
- update the Dashboard for taking care about external Icons for the
search result
- update sqlite model/version for taking care about Intents
(enable launching external applications for showing the settings)
Change-Id: I2e38599327e6480f1754f52666becce0884cee9d
...java.lang.NullPointerException: Attempt to read from field
... 'long com.android.settings.SettingsActivity$Header.id' on a null object reference
- fix the AndroidManifest for missing meta data
- fix NPE causes in getHeaderTitle()
- update how we are putting Fragments on the BackStack
Change-Id: Ifc0bba744c3b2a0603c2f11f711ef493cbacc9d2
Read-only version of the configuration screen for
Limited Interruptions. Defaults to the logic implemented
for this mode, namely block notifications except for
Calls & Alarms.
This settings panel will serve as a target for the
configure affordance in SystemUI.
Change-Id: I33fd1e11ab76dbb7044bb94cb096cd892945947d
- revert back to an Activity instead of a fragment. This
is a straight reverse of the changes introduced for trying
to have a Fragment.
Basically ChooseAccountActivity was previously an Activity for
choosing an account type. If the list of account types was containing
only one item, then the ChooseAccountActivity was just a pass thru
and was falling back to the only account authority available.
In the current reported bug, this was happening by disabling the
Email app and thus having only the GoogleAuthenticator as an
Authority.
Then in the onCreate() the ChooseAccountFragment was seeing that
there was only one account authenticator and issuing a BACK button
press. Too bad, this was done into a non finished Fragment transaction
and leading to a crash.
All in all, we NEED to have an Activity and cannot use a Fragment
in that case.
Change-Id: I4a867a25fe9580929ec50a6775105adac1f88c52
Cancel the pairing notification on bond state change happens from
BOND_BONDING to BOND_NONE. Otherwise it will present in the
notification area until it gets cancelled by opening it and press
cancel on pairing dialog.
Change-Id: I96f673e29e612cd748165a1323a5b4a4276a843c
- ApnSettings is now a fragment so introduce a new ApnSettingsActivity
- ApsSettingsActivity will use the ApnSettings fragment
- move the getListView() call to onActivityCreated(...) as the ListView
needs to be created before this call can be done.
- add also an alias for the old activity name ".ApsSettings"
Change-Id: Id228722d7f34415d4b036282f0845e28546111df
Follow up from the previous CL that was trying to fix it.
- remove the dialog theme android:theme="@android:style/Theme.Holo.Dialog" as
a Dialog does not support a Drawwer
Change-Id: I8b3fe89c157f0b454464c04a4acd4f32049bde71
- get rid of PreferenceActivity as much as we can and use fragments instead
- add Drawer widget
- add Dashboard high level entry into the Drawer (but this is work in progress and would be done in another CL)
- add bypass of fragment's Header validation when launched from the Drawer but *force* validation if external
call thru an Intent
Be aware that WifiPickerActivity should remain for now a PreferenceActivity. It is used by SetupWizard and should
not trigger running the SettingsActivity's header building code. SetupWizard is a Home during the provisionnig process
and then deactivate itself as a Home but would make the Home header to appear in the Drawer (because momentarily we
would have two Home).
Also, verified that:
- the WiFi settings still work when called from SetupWizard
- when you have multiple Launchers, the Home header will appear in the list of Headers in the Drawer
Change-Id: I407a5e0fdd843ad7615d3d511c416a44e3d97c90
Merged remote display route selection into the existing wifi
display preference UI. Moved the on/off toggle over to a menu item.
The preference page is now mainly implemented in terms of the
media router. It only interacts with the display manager for the purpose
of pairing with new devices or making wifi display certification
controls available.
This means that the observed state is now completely consistent across
the system ui, settings, and applications that use the media router.
Bug: 11257292
Change-Id: I3705570812384fef4bfffeccaaccf7895d370d12
We used to show a single notificaiton for every print job but
this is against th UX guidelines. Since we have to lead by
example, this change adds coalescing of multiple notifications.
bug:11155212
Change-Id: I865450495e7e85bd6620c1f42aeef07d2f83a01a
This will be redesigned soon, but for now it allows access to quick
setting tiles for testing display adjustments.
BUG: 9057596
Change-Id: I4b760487b2fe0a336b188930306000e5dfc01951
Also make us much better about determining which app to blame for
a particular running process, organize the display of services by
their owning app, apply some new heuristics for deciding what goes
in the process list so that we can still display interesting processes
when we haven't collected pss data for them yet, etc.
Change-Id: I7e87225d3dabc66cf3ff020b5db48401b14aaf47
Security fix for vulnerability where an app could launch into the screen lock
change dialog without first confirming the existing password/pattern.
Also, make sure that the fragments are launched with the correct corresponding
activity.
Bug: 9858403
Change-Id: I0f2c00a44abeb624c6fba0497bf6036a6f1a4564
Security fix for vulnerability where an app could launch into the screen lock
change dialog without first confirming the existing password/pattern.
Also, make sure that the fragments are launched with the correct corresponding
activity.
Bug: 9858403
Change-Id: I0f2c00a44abeb624c6fba0497bf6036a6f1a4564
Multi project change:
The changes in this project update the settings app to support the new
default SMS app setting. I have also updated the order of the wireless
settings in the UX as per request from rachelg.
Bug: 10449618
Change-Id: Iba1ac6ea3f29c2a72af83b122ec5ea3a16a28e58
Add the MonitoringCertInfoActivity, used by Settings, QuickSettings
and notification to explain about CA certs enabling network traffic
monitoring.
Add a button on the Security item in Settings when a cert is installed.
Bug: 10633199
Change-Id: Ic753fe22b66c30d837a9ba471a0632a07bb7471f