* Add the (recurring) text when the invite is for a recurring
meeting
* Add a test for message text creation
Bug: 2515474
Change-Id: Ifefbc2ba1ac444175180cb7a58f4ec554d9674a3
* The utility wasn't handling commas properly, causing the referenced
bug
* Fixed the utility and updated the relevant test case
Bug: 2515488
Change-Id: Id229e50fcaaed1a0142db301eedaaba9209bed13
- In memory attachments are now stored as byte[], not String.
We can store any type of contents now.
- Added blob content_bytes to the Attachment table.
The content field is now deprecated and not used.
- Explicitly convert ICS files to UTF-8.
- Added Utility.to/fromUtf8().
Bug 2509287
Change-Id: I3785a365a9a34039ec12ba82bd857dcdbc4de92d
* We weren't sending out appropriate emails for exceptions and other
event updates
* Write exception specific ics file code in CalendarUtilities (in
the existing ics file creator)
* Send appropriate Update: subject for updated events/exceptions
* Compose simple message text consisting of:
When: <time>
Where: <location>
* Prepend message text for exceptions to indicate that the message
relates to a particular instance of the event:
This event has been canceled for: <date>
The details of this event have been changed for: <date>
* New strings were added in CL#44141
* Updated CalendarUtilities tests
Bug: 2501270
Change-Id: I920de8120bc56d5bd565cbde26ff4807be41579f
* Ignore CR and change LF into backslash + n
* Write unit test for handling of CRLF's
* Rename mLineCount to mColumnCount, which is more appropriate
Bug: 2508283
Change-Id: I8b2081aa474cb07b6cb09383ff6ac58a1dab1bba
I missed a case where message-id should not be set locally, which is
the case where the Mime parser clears all headers *and* does not find
a message-id. The parsed MimeMessage should accurately reflect this.
In the old code, the local id was created at construction time and then
immediately discarded by the parser (calling headers.clear()).
In the new code, I was generating a message-id any time I couldn't find
one. Now, when explicitly cleared or removed, I set a boolean to inhibit
automatic generation of a new one.
I also missed the fact that a missing message-id no longer throws an
exception, it simply returns null, and so I changed the code that was
catching that exception to simply check for null.
(Note: Clearly, modeling of legacy behavior is becoming annoying here;
It would be better to do away with all of the automatic logic, and simply
generate message-id locally when appropriate: On locally-generated
messages. I don't want to touch this for the current release, but I left
a note in the code to this effect.)
Bug: 2504774
Change-Id: Ibfcbd2363c7ae39ee6d44e4c3295f88258cb4945
Added DiscourseLogger, which stores last N (currently 64) lines of IMAP
commands sent to the server and responses received from the server.
We dump it to logcat when the IMAP parser crashes, that is, a) getting a
RuntimeException in ImapFolder.fetch() or b) getting a Runtime/IOException
in ImapResponseParser.
Bug 2480227
Change-Id: I6b5a728a7df106627ec29bb3c7c04a97a99b444b
Message and MimeMessage were creating a lot of unnecessary sub-objects
even when not needed, so do a bunch of lazy initialization. This should
raise the bar on the size of gigantic inboxes giving us trouble.
* Specific optimizations:
* Replace date formatter with a shared static
* lazy create mHeader (ArrayList)
* lazy create mFlags (HashSet)
* optimize MimeHeader fields class
* lazy create local message-ID (expensive-to-make uuid String)
* make message-id string less expensive to create
* Other cleanups:
* add some override annotations
* privatize some members
* update a fragile test (not a deep fix, it's still fragile)
Side effect, should be faster too.
Bug: 2357564
Bug: 2093422
Change-Id: I8a873879d402e2662339d5398ad0b15da6e580e9
This test has been failing since I60974b85, which is obviously correct,
so I modified the test.
Bug 2488770
Change-Id: I5a2eea19d9f3c3647b7c88a1e0db9297727b8e66
* Split account copy loop to do POP3 accounts first, then IMAP
* After upgrading accounts, upgrade folders
* Upgrade messages in those folders
* Preserve attachments on outgoing messages (e.g. drafts)
* Enable composer and start syncing after upgrade
* Fix latent bug in LocalStore (which was not used in Eclair)
* Add tests for upgrade workers in LegacyConversions
Bug: 2065528
* 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
* Included is a (nearly complete) VCALENDAR parser that is
used to verify the contents of the ics attachments we create
* Added a test for meeting invitation
* More to come (always)
Change-Id: I31eeac66eb635f443c85aacf56e67a943cc3d53b
* 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
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
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
* 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
* 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
- 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
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
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
* 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
* 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.
* 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".
* Create full TZI strings for upload of events (previously, we
omitted DST information)
* Add documentation to some unit tests
* Put in correct logic for determining if upload needed
* Fix problem w/ parsing empty tags
Change-Id: I268ce8a2db30b3cfdf0e44f6a78befd6bd933243
remove-exchange-support.sh makes it possible to build the email app without
exchange support.
This script:
- removes all packages under com.android.exchange.
- removes all lines surrounded by EXCHANGE-REMOVE-SECTION-START and
EXCHANGE-REMOVE-SECTION-END
And the resulting source should still build and run fine.
Bug: 2369784
New behavior:
* There are two primary paths through this activity:
* Edit existing:
* Load existing values from account into fields
* When user clicks 'next':
* Confirm not a duplicate account
* Try new values (check settings)
* If new values are OK:
* Write new values (save to provider)
* finish() (pop to previous)
*
* Creating New:
* Try Auto-discover to get details from server
* If Auto-discover reports an authentication failure:
* finish() (pop to previous, to re-enter username & password)
* If Auto-discover succeeds:
* write server's account details into account
* Load values from account into fields
* Confirm not a duplicate account
* Try new values (check settings)
* If new values are OK:
* Write new values (save to provider)
* Proceed to options screen
* finish() (removes self from back stack)
* Added unit test for new loadFields method
Bug: 2412300
* Create unit test to reproduce crash
* Fix handling of empty bundle (the default return value)
* Clean up some exception handling in the policy module loader, which
reduces some unneeded logging.
Bug: 2413388
* Begin wiring into system DevicePolicyManager requirements
* Semi-real implementations of isSupported() & isActive()
* Added new API (placeholder) updatePolicies()
* Updated existing unit tests as needed
Bug: 2387961
* scrub all external strings to keep them compliant for IMAP protocol
* move Build.MODEL to x-android-device-model
* send x-android-mobile-net-operator
* send AGUID
* unit tests for above
* retrieve providers from VendorPolicyLoader
Bug: 2332183
Moved Eas.ACCOUNT_MANAGER_TYPE to Email.EXCHANGE_ACCOUNT_MANAGER_TYPE.
This constant is not related to the exchange protocol, and referred in
a lot of different places. Moving it out of the package will make it a lot
simpler when removing exchange dependency.
What should be working:
* Events sync down from server and appear in calendar
* Recurrences and exceptions appear in calendar
* Changed events on server should be reflected in calendar
* Deletions on server should be reflected in calendar
* Push of new/changed/deleted events should work
* Changes on device are NOT synced back to server
* New, single events on device are synced back to server
(no time zone, attendee, or recurrence support)
* Checkbox for syncing calendar added to setup flow
* System sync glue in manifest, etc.
* Bugs are to be expected
* A few unit tests; needs more
Change-Id: I7ca262eaba562ccb9d1af5b0cd948c6bac30e5dd
- Dynamically switch to the alternate exchange strings to substitute overlays.
- Added the mechanism to load the "vendor policy", which tells you when the
alternate strings should be used.
Bug: 2382710
Merge commit '08d92ebf4722e45216ee225775a3b86f9ceecc0d'
* commit '08d92ebf4722e45216ee225775a3b86f9ceecc0d':
Trim the mime type portion of Content-Type.
* AccountSetupExchange defaultly tries using EAS AutoDiscover, which isn't
appropriate in the unit test setting
* Add an Intent extra to disable AutoDiscover and use it in unit tests
Bug: 2382368
Change-Id: I3d4e8d7194b02da44ad583da0cf2fe60ffb19311
* Add IMAP ID command to all login sequences
* Send generic information for now
* Explicitly catch & discard parsing errors, since we really don't
care if the command succeeds or not.
* Unit tests
Bug: 2332183
* Upgrade accounts table to add security column
* Read/Write new column
* Backup/Restore new column
* Unit tests for all of the above
* First cut at defining bitfields (non-binding, just putting down ideas)
Bug: 2387961
* Followup to 85d765f4
* Workaround for (HTC bug: 2275383) & (Moto bug: 2226582)
* Restores mSyncKey as null instead of empty string, which is how
a new account is initialized. Bug: 2385980
* Cleanup synchronized logic in backup & restore
* Minor cleanups & improved comments
Cherry-picked from master d612717340
* Followup to 5e91cccd
* Workaround for (HTC bug: 2275383) & (Moto bug: 2226582)
* Restores mSyncKey as null instead of empty string, which is how
a new account is initialized. Bug: 2385980
* Cleanup synchronized logic in backup & restore
* Minor cleanups & improved comments
* Workaround for (HTC bug 2275383) & (Moto bug 2226582)
* Adds checkpoints for backing up and restoring accounts
* Uses legacy Account / prefs to back up accounts - this is because
some of this code will be reused for legacy account migration
* Unit tests of Account & LegacyConversions
* Unit tests of backup & restore
* Not done: testing of EAS/Account Manager interface (this will require
deeper dependency injection, to avoid the embedded calls to the Account
Manager and other system services.)
Cherry-picked from master 5e91cccd4b
* Workaround for (HTC bug 2275383) & (Moto bug 2226582)
* Adds checkpoints for backing up and restoring accounts
* Uses legacy Account / prefs to back up accounts - this is because
some of this code will be reused for legacy account migration
* Unit tests of Account & LegacyConversions
* Unit tests of backup & restore
* Not done: testing of EAS/Account Manager interface (this will require
deeper dependency injection, to avoid the embedded calls to the Account
Manager and other system services.)
* Addresses #2287439 incompletely
* The most likely reason for a reply/forward to get stuck in the Outbox
is that the referenced message has been deleted from the client, with
the deletion occuring BEFORE the message gets sent (currently, the two
are completely independent)
* This change causes deletes NOT to be sent to the server if the message
to be deleted is referenced by an outgoing message
Change-Id: Iad3777282385bea82276f363d6f95ba8b07cc01c
* Addresses #2226426
* Recognize the case in which there is no EmailProvider Account corresponding
to an AccountManager account (the case being addressed is that of the
EmailProvider database being deleted due to corruption
* In this case, delete the AccountManager account so that the two are in
sync
* Refactor and add unit test for account reconciliation
Change-Id: I356b8bfaa0846f85223cc15994b750df207a63ea
* Addresses #2287439 incompletely
* The most likely reason for a reply/forward to get stuck in the Outbox
is that the referenced message has been deleted from the client, with
the deletion occuring BEFORE the message gets sent (currently, the two
are completely independent)
* This change causes deletes NOT to be sent to the server if the message
to be deleted is referenced by an outgoing message
Change-Id: I146f63ab345c07e684790e1d7d1fc08870468bbf
* Addresses #2226426
* If the user deletes Email data, or if data corruption causes
EmailProvider.db to be deleted, we will be in an inconsistent
state with any existing Exchange accounts, since the AccountManager
will still know about them, contacts (and eventually calendar) items will
continue to exist, etc.
* Run an integrity check when the provider is created, deleting any
orphaned EmailProvider.db or EmailProviderBody.db
* Catch SQLiteException's in the Provider and do an integrity check
if any is caught
Change-Id: I47d523b90a6b8f71ba8e13fba4b04846b3da1b1d
