* Create new activity to encapsulate account upgrade
* Populate it with a list of legacy accounts, and progress bars for each
* Sidestep Welcome when there are legacy accounts to convert
* Super lightweight account migration:
- Account login info only
- no folders, messages, or attachments
* Scrub out old data
* Return to Welcome screen
As noted, the copies working (useable) POP & IMAP accounts, but does
not try to deal with folders, messages, or attachments.
Bug: 2065528
* Fix anouther in a series of Exceptions that can occur if SyncManager
is shut down abnormally. These tend to happen runnings tests, and
nowhere else.
Bug: 2228604
Change-Id: I064f11017431c1f1a73e8040dbc174f5ba03d7de
* After receiving a provision response from the server, first check
for a remote wipe command, as this should always take precendence
* After that, see if the requested policies are active, and if so,
acknowledge them to the server
* Otherwise, indicate that we are blocked due to a security failure
Change-Id: Ie70fae18772f4e3161cf72132982e429c6548e48
* When the UI indicates that security policies for a particular
account are now in force and releases the security hold (a bit
in the Account flags), we release any syncs that had been
waiting due to security errors
* Clean up code related to sync holds
* Add unit test for sync hold release
* Add support for server-directed remote wipe
Change-Id: I6209f75e4b57c850ae1ac27f407630c9c740514f
On new accounts, we can accelerate the process of setting up security
by explicitly checking (at the end of the security process). The user
is not required to "answer" the asynchronous notification.
This is an imperfect solution, as a slow initial sync could leave the
user in a non-synced Inbox (with a notification waiting for them), but
we can come back to this after we evaluate real-world performance.
Bug: 2387961
If an account is deleted, immediately recompute the aggregate
security policy, and apply it immediately.
When applying policies, handle "no policy" case by releasing device admin
status entirely.
It turns out that we have already implemented the built-in version of
local-wipe-after-failed-passwords, and the notes about it were not
necessary.
It should be possible to connect to an account with local wipe
requirements and see proper operation.
Convert all usages of com.android.email.codec.binary.Base64 to use
com.android.common.Base64 instead, except for Base64OutputStream
(which doesn't exist in android-common yet).
Change-Id: I339a1f451245138187080c7444fcabef8d13f8aa
* Add hold flag to Account flags
* Add code to set it (when EAS reports policy failure)
* Add code to clear it when we see changes from the device admin side
* unit tests
This should be sufficient to restart sync of an account which is on hold
due to security policy requirements. Note, this is considered a "retry",
and if the account still does not meet requirements for some reason, it
is expected that EAS sync will call policiesRequired() again.
Fix the case in which an Email account is deleted in the Account Manager
UI, and we delete the provider account, but we did not also update the
backups. In some cases, the deleted account would be accidentally
restored from the backups.
Bug: 2414469 (internal)
Bug: 2427663 (external)
* The color chip resource table was duplicated in three files
* Move these into a common location in Email.java and add
convenience method for retrieving color chip resource id based
on accountId
* Simplifies future changes to account color selection
* Add RGB color information on these resources (provided by
rfulcher) and add a convenience method for retrieving these
Change-Id: If1c2d22fba91cfce46a2618cd2b73cf7a534ce51
* For some reason, the recurrence expansion system requires hr, min, and sec
to be zero for DTSTART when allDay=1
* Force hr, min, and sec to zero for all day events
Bug: 2427658
Change-Id: Ief6b5b571fa6bc6947bcbc9cda02ab2c04f27549
* Add more final plumbing for exchange security
* If policies are supported, we now check to see if they are active;
if so, we acknowledge this to the server, after which we are given a
final policy key which can be used for syncing
Change-Id: I5992c790294e35b5ec5343c7665e2e7fd31a75ca
* This first implementation integrates with early CLs for
Email app integration with device security
* Check for policies added to validation process
* If the server has no policy requirements, there is no change
to the existing process
* We automatically declare a set of policies to be unsupported
if any are known to the sync adapter to be unsupported
(e.g. no attachments or password history)
* We call isSupported (PolicySet) to determine whether other
policies use values that the OS can support (e.g. password length,
inactivity time, etc.)
* Depending on whether the server's policies are unsupported or
supported, we throw the proper exception back to the caller
Change-Id: I704cb2151dd87f54c83c2aa23976a8ac8e2c501a
* Exception is due to the presence of values in ContentValues that
are null (would normally expect those fields to be absent)
* Fix all relevant cases that might produce an NPE in this case
Bug: 2422815
Change-Id: I637a21307c2d518912edce093de90a06d94614e5
* Create notification to display when syncs fail due to security
* Create psuedo-activity (no UI) to manage device admin state transitions
* Clean up and flesh out SecurityPolicy APIs'
* Add placeholders in EasSyncService showing how to react when policies
are not met and sync cannot continue.
Note: There are some STOPSHIP todo's at the top of SecurityPolicy.java.
These should explain any code that you might think is "missing".
* Exchange calendar sync created Event records for exceptions
that didn't have a _sync_id
* This caused google calendar sync to try to upload these
Events as new, which caused an Exception to be thrown
* Fixed EAS calendar sync adapter to generate a _sync_id for
exceptions in the form <parentId>_<exception start time>
Bug: 2420732
Change-Id: I46769175ca89ffa4cec4fe8b0c35ef2242536185
* Rename SECURITY_POLICIES_REQUIRED to SECURITY_POLICIES_UNSUPPORTED
* Create new pathway for SECURITY_POLICIES_REQUIRED, making it advisory
* Cleaned up strings for account setup error dialogs
* Refactored AccountSetupExchange.onActivityResult() to split up the
three primary use cases, making them more readable.
* Always finish() in AcccountSetupAccountScreen, because it's usually
cleaner to return to the previous screen (enter username & password).
* Exchange account validation tests security policies by sending a
FolderSync command and determining whether this generates an
error
* Unfortunately, we use the real deviceId when sending the command
and this causes the next real sync to fail such that all data is
wiped and reloaded (the bug)
* The fix is to use a false device id while doing validation
Bug: 2415185
Change-Id: Ibe577e36f770d737ba5952b347aa0d73bda3568a
satok