This is a lightweight placeholder so calendar functionality can be
tested. Simply presents a message about the invitation, and a set of
yes/maybe/no buttons to click.
The UI is shown whenever the message appears to contain an invite.
There are many elements left to be done here:
TODO: response code (EAS protocol) doesn't seem to work
TODO: use real assets & design
TODO: provide a click-link into calendar event
TODO: show calendar icon in messagelist too
TODO: (if possible) persist user's response in button state?
Use SSLCertificateSocketFactory.getDefault() to get an SSLSocketFactory
which performs SSL certificate checks, and getInsecure() to get one
which doesn't (for "accept all certificates").
Bug 2226160
Removed the hardcoded package name in account_preferences.xml. Now we launch
the PreferenceScreen with only the action. Added an intent-filter to the
preference screen to catch it.
Bug 2447903
If the user revokes device admin status, reset our internal state and
the state of any accounts that might have been depending on it. This
halts syncing immediately and rewinds the security/provisioning state
of any such accounts to a known state (as if the account had just been
created.)
Bug: 2387961
* Added a meetingInfo column to the Message database
* When a meeting invite is received, the start time is stored here
in ms from start of epoch. Note that this field is defined to be
a String, for extensibility
* Update ProviderTests
Change-Id: If44892d27ccc5ebdc1f8667befafb8b8a27a2cf4
* Provisioning for Exchange 2003 and Exchange 2007 now supported
* Added end-to-end test of Exchange 2003 provisioning parser
Change-Id: I1f86f2909351a8220b963551cd33fecdf59a7e26
* Use a content observer to detect changes in Calendars; we use this to
determine whether or not sync has been turned off. If sync is turned
off, all events will be deleted, so we need to reset the sync key
* Make sure that all code working on Contacts also now works on Calendar
(push, etc.)
* Remove some old crufty logging and out-of-date comments
* Addresses 2433061
Bug: 2433061
Change-Id: I6299168903fcce9bf820b72b5f6bb157d9169653
* 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
Ying Wang