* Prune all folders, messages & attachments that won't migrate
* Clean up SSL/TLS values for better connection results & security
* Move account setup lookup code to AccountSettingsUtils to share it
* Cleanup config/auto-rotation settings to prevent relaunch of
auto-discover or account check (from exchange).
* A couple of other very small fixes
Bug: 2065528
If the account specified with an Intent doesn't exist, show the Welcome
activity instead, which will navigate the user to the appropriate activity.
(e.g. account list if there're more than one account)
Bug 2479609
* Unlike EmailProvider, CalendarProvider can return null from queries.
* Put checks for null around code using the result of query to
prevent NPE's
Change-Id: Ia9e8e2f44406dce07dcb2ffa40c22933ec2d4f07
* We needed to check that clientId wasn't null before sending it back
to the server
* Exceptions don't have a clientId
Bug: 2478711
Change-Id: Ic0d42bb699605a7bb77535b050a4d03b4b6b8b09
* We want an NPE to be thrown, since we need to locate/fix errors
of this kind.
* Add logging to help isolate the error
Change-Id: I0f4336b42cbdb88c72459bdeca9c9fc236d9299f
* VTIMEZONE blocks must be sent in our ics files for meeting
invitations that are recurring, as the originator's time zone
is critical in making attendee's calendars accurate
* Created a utility to convert TimeZone to VTIMEZONE data; the
utility successfully generates data (including recurrence rules)
for the entire tzinfo database (the source of TimeZone).
* Updated our ics files to include VTIMEZONE when appropriate and
send DTSTART/DTEND in local time in that case
* Wrote some unit tests, but more are needed
Change-Id: Iccbdd00cd3b2be2da058b344ebacd17ed6fb0e3d
* My Calendar observer registration code was storing the wrong id
in the hash map. Because of this, the code could be called again
and again, generating lots of extraneous queries and generally
creating a lot of havoc, including ANR's
Bug: 2450322
Change-Id: I03db8156ee99a0c7243a9188558dffc6a843a65a
We've observed that the secure.emailsrvr.com email server returns an excess
FETCH response for a UID FETCH command. Excess responses don't have the
UID field, even though we request, which led the response parser to crash.
This patch fixes it by making the parser ignore response lines that don't
have UID.
Bug: 2441065
* Syncs in progress weren't checking the getSyncAutomatically setting in
the account; therefore, a long sync would continue running even though the
user unchecked the "Sync Calendar/Contacts" box in the settings
* Make the adapters check the flag each time through its sync loop (which
is currently 5 items); this should cause in-progress syncs to stop within
a few seconds
Bug: 2185319
Change-Id: Ie181f6de4219ecf27fff58ed59a277ae285622c5
* We weren't retrying the initial account sync after policies are
successfully enabled. This results in failure to sync, as we
go right into a ping loop.
* Retry account sync after provisioning is first successful
Bug: 2474554
Change-Id: I20165a5941626b690710f82088d8d861679084b2
On the first boot after upgrade from Eclair, enable calendar sync for all the
existing Exchange accounts, if any, and show notification.
Note on this version, nothing happens when you click on the "Calendar added"
notification. We're waiting for an API (action or something) to launch
calendar.
Bug 2428718
* Fill in this missing piece of meeting related functionality.
* We keep track of the last synced attendee status in the newly
created syncAdapterData event column
* When this changes, we (in addition to syncing up the change)
send an email to the organizer (unless we're the organizer, of
course)
Bug: 2467153
Change-Id: I6332fb6d0839e33d4c54bd4358ee0f154bff6612
* In #2469254, uploaded new events were rejected because the time zone was
sent after dates; this doesn't matter to Exchange 2007, but it apparently
does to Exchange 2003
* Also, I noticed that upsync was upsyncing all new events, regardless of
whether the event belonged to the Calendar being synced! So this is
fixed as well.
Bug: 2469254
Change-Id: I651d591cf26e00b414f6da19897fddcdb840c97c
* When the user selects accept/decline/tentative in MessageView, we now send
an email to the organizer, with an iCalendar attachment indicating the reply
* Added a unit test for the reply case, but more tests to be added to handle
other circumstances
Change-Id: Iff799d88a92b6546735bf4965b22febf3a82b56f
* Was checking for any meeting related email
* Changed to look specifically for incoming meeting invites
* Bug noticed during debugging
Change-Id: I8f43d7a506939dbfc0504f96b249e5c17107bf47
* Wrote utility to create an ics file (iCalendar) based on a
CalendarProvider Event. This is a good first pass, but we need
to consider whether to include alarms, etc.
* Use aforementioned utility and new convenience method to send
meeting invitations to attendees of newly created meetings (events)
when they are uploaded to the server via the CalendarSyncAdapter
* Overall, attempted to modify existing provider and rfc822 output
code as little as possible. Rfc822Output is actually very limited
in its capabilities and should be made more robust in future
Change-Id: Ie20b9137df56dc414de6737d05fa40ec9cdf47e0
* We can use this for meeting request information which will start out with
one or two pieces of information, but might grow in the future.
* Binary compatible with Address.pack() format, so we can eventually
combine code.
* Added two columns to Attachment in EmailProvider
content: content that is written directly as an attachment
suppressDisposition: to suppress the content-disposition header
All meeting invitation emails use these two columns; the first
for ics attachment data (which is quite small, rarely over 1k),
and the second to indicate NOT sending the content-disposition
header; without this, Exchange will consider the ics as an
attachment rather than an iMIP style message (rfc2447)
* Modified tests to include these columns; added upgrade code for
new database version
* New columns and code are designed to be usable outside Exchange,
although there are no other clients of the code at this point.
* Modified Rfc822Output to use the content field, if present, in
lieu of retrieving attachment data via URL; added support for
suppressing the Content-Disposition header
- The entire android.pim package is hidden.
Use java.text.ParseException instead of android.pim.DateException.
- TelephonyManager.getDefault() is hidden.
Use Context.getSystemService() instead.
- Use newly added Base64 in the framework.
Bug 2226160
- Now that reconcileAccountsWithAccountManager() is static, we don't need to
instantiate SyncManager.
- Don't need to set mResolver. reconcileAccountsWithAccountManager() doesn't
use it.
* Make the field and label GONE for EAS accounts
* Enable the "Done" button at all times for EAS accounts
* Add test case for this, and clean up bad formatting in tests
Bug: 2443881
Change-Id: Ic80b001e443fa37b7cfeb810b1f31edf22b065b9
* The "hasAttendeeData" column needs to be set to 1 for all Exchange
events (the case in which the value would be zero doesn't pertain
to Exchange events)
* Also, move code for organizer attendee to the proper place
Bug: 2457665
Change-Id: I3260f883135bb222ce475ccbabf5ba151ab7f557
1. Destructive of existing user accounts in device
2. Can get confused (miscounting) due to existing user accounts
3. Cleaned up use of context and mock context
4. Disallow account backup and account security updates when testing
5. Make account manager removeAccount() calls blocking, so the test
does not proceed until the accounts are really deleted.
Bug: 2454870
* Initialization of CalendarProvider Calendar was being done at
account creation time, but Eclair accounts won't have had this
done.
* Move Calendar creation code into CalendarSyncAdapter where it
will be created before the first sync.
Bug: 2451630
Change-Id: I74c669d99f4c8aae4c5847f5cb9b0ca7f44929e2
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
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.
