b/9566150
- Install PublicPreferenceActivity
- Create AccountServerSettingsActivity to contain all the crazy
logic we don't want in AccountSettings
- Add restoreAccountWithAddress to Account
- Refactor almost everything out of AccountSettings
- Tidy the QuickResponse fragment
- Majorly refactor the AccountSettingsFragment to decouple it from
the activity, and make it save settings immediately instead of
when pausing
- Move login warning dialog to AccountSettingsFragment
- Tweak HeadlessAccountSettingsLoader
Change-Id: Ie69181d968b9c3e5940cfef9690b1f5c70e21aa8
b/14998528
These are particularly important since they are stored in JSON form within the
Account Manager, so maintaining backward compatibility when future changes are
introduced is crucial.
Change-Id: I51333a364726a4c7e2fe88ee888e8c4cc11d962f
table and connect the data to the Settings object in the existing
location (SettingsColumns.MAX_ATTACHMENT_SIZE).
Change-Id: Iaf48995757511e1dfb65aa35ff6d81bbc47187bd
Conflicts:
src/com/android/email/provider/DBHelper.java
Now you can authenticate your account using oauth
for google hosted accounts (e.g. google.com, gmail.com)
The setup ui is still not up to spec.
Change-Id: Ib2826653550a823b4d1b8739c1e483746cccbc22
The problem is that exchange isn't compiled with this
change, so HostAuth parcels to or from exchange fail.
Ultimately, we'll need to probably create a HostAuth2
object or something along those lines. For now, just
change the format of HostAuth parcels back, so they
stay compatible with exchange, I'll figure out a real
solution later.
Change-Id: I9c8c8639b7b474fe82dfdc37a9e51a0451820105
These settings need to be migrated from the database, not the
SharedPreferences file that likely shouldn't even exist.
Everything added to Account.java was removed in
Ie6ec389b5b5d2e7ab1b299d0877811ae716526e2
when it was believed to be unnecessary.
Bug: 10211615
Change-Id: If6193758febda8a3272d82792492503549a44e32
The user no longer has control over this. Now, the "default" account
(which is only used for prepopulating the name of new accounts is
either the last used account (to be defined), or the first account in
the database.
This removes a setting, and simplifies a lot of code.
We may also want to auto-select the default account when entering the
compose screen from the combined view, but we do not currently have
an easy way to do that.
Bug: 7442992
Change-Id: Iff5bb36d8cbd327334211b670fa4851cbda6b9a0
Also includes a fix for saving a draft that's already
been saved (used to create a new one).
The following were unused:
- accountIdAddToField
- mailboxIdAddToField
- uisendmail
- uisavedraft
- uiupdatedraft
- uisenddraft
Deleting those also allows us to remove the translation
from the Bundle used by calls to the ContentValues used by
update (since the update paths are now gone).
Change-Id: I87f2875e3272177a128a8ff65541e51b1f2d05fc
This involves redoing the persistence model, to split general,
account, and folder settings into separate SharedPreference stores.
It also requires some preferences to be moved into UnifiedEmail.
Depends on Ibe2e3f93ec164370535ffc5f5b2409544cc8d36d (UnifiedEmail)
Change-Id: Ie6ec389b5b5d2e7ab1b299d0877811ae716526e2
Migrate the old value as necessary.
Update the unit tests.
Cherry-picked from I1c276ffde3496cbc66846ed4a007088d39f20382 with
minor changes.
Bug: 7624838
Change-Id: I1b3fa331b62f556701bacba5ce9cd64305d9b52a
* We need to call this out to the user (a surprised user is an
unhappy user)
* Required for fix to bug referenced below
Bug: 5533550
Change-Id: I64a870a703de7e02ce882aefc3636a1668021eb8
* We need to call this out to the user (a surprised user is an
unhappy user)
* Required for fix to bug referenced below
Bug: 5533550
Change-Id: I7da337057b9b28300ddd485283920e12c1ae53da
* Remove PolicyService APIs policiesRequired, policiesUpdated,
isSupported, clearUnsupportedPolicies, and isActiveAdmin
* Add PolicyService API setAccountPolicy, which is the sole
method by which security policies are promulgated
* Add protocolPoliciesEnabled and protocolPoliciesUnsupported
to the Policy class; these are packed, localized strings
indicating policies that the protocol itself have enabled
and/or cannot support (i.e. these are policies that are
unknown to the DPM, e.g. don't load attachments)
* Differentiate in security notifications between three kinds
of policy changes - changes that don't require user
intervention (e.g. reducing requirements), changes that
require user intervention (the legacy notification), and
changes that make the account unsyncable (e.g. the server
adding an unsupportable policy). Handle all possible policy
changes cleanly.
* Make security notifications per account (with multiple
accounts, notifications would get arbitrarily munged)
* Expose ALL enforced policies via the account settings
screen in two categories: policies enforced (including
both policies enforced by the DPM and policies enforced
by the protocol) and policies unsupported (note that these
can only be seen if policies are changed after an account
is created; we do not allow the creation of an account
when any required policies are unsupported). Add a
button that forces a sync attempt, for accounts that
are locked out, but whose policies have changed on
the server (this would otherwise require a reboot).
* Updated unit tests
Bug: 5398682
Bug: 5393724
Bug: 5379682
Change-Id: I4a3df823913a809874ed959d228177f0fc799281
There were two issues:
- the default account ID from the provider wasn't consistent: it was
using a snapshot from the cached data but that simply returns a Map, and
the values aren't guaranteed to be sorted (and indeed I saw that the
order was different on consecutive calls!)
- hitting app up from Compose always just kicked you out to the inbox
for the default account, but it probably should have used the account of
the compose screen, since it can be specified in the Intent
Bug: 5012008
Change-Id: Ic9a753b261e047790453bc1a9417bc0c6d2f87f9
There were two places where account flags were being set on setup: one
was in manual setup when the user selected the account type
(pop/imap/eas), and another was when it was automatically determined
from XML. The two paths were inconsistent and one was setting bits like
SUPPORTS_SEARCH but the other wasn't.
This fixes being able to search in IMAP
Bug: 5011932
Change-Id: I50eada7485aaef4e2a85d25fa7eb9ac7ab03093a
* Guarantee that up to 16 Account (with HostAuths), and Policy rows
are always cached. Also, 6 commonly used Mailboxes per Account
(Inbox, Outbox, Drafts, Sent, Trash, and Search)
* Precache these rows when EmailProvider starts up
* Ensure that newly added, precachable rows are cached when created
* Clean up some inefficient/wrong caching code
* Fix a commonly called method in NotificationManager in which we
load a single Mailbox row using selection vs withAppendedId
* Confirm that we don't read from the database in typical use and
heavy message loading
* Add a special URI for finding mailbox by type (using the cache)
* Add special-case code for EmailContent.count(Account.CONTENT_URI)
which is used in a number of places (including on the UI thread)
and whose value is easily determined
* Add a special URI to get the default account id
* Confirm that all unit tests work
The goal here is to be able to load all Account, HostAuth, Policy,
and Mailbox objects (by id) without worrying about disk access.
There will still be a single disk read for uncommon Mailbox reads,
but this should be considered acceptable.
Change-Id: Ibc9aa7acc73185e360b0b6f3053b90a985e97210
TODO: Unit tests
Jorge Ruesga