- Merged all three BroadcastReceivers into one.
(Changed class name because old ones may have been disabled.)
- Use IntentService to perform the tasks in a worker thread.
Note the new receiver will never be disabled. We always need to start
exchange.SyncManager.
Bug 2722155
Bug 2416929
Change-Id: I8241880fc1ee38d85dcdca7e1d46fc2f6b2d375b
Part 1: MessageView
- It's an attempt to get rid of Handlers from Activities, and
reduce the amount of code that runs run a BG thread in them.
- Introduced ResultUiThreadWrapper, which wraps another Controller.Result
and make callbacks get called on the UI thread.
- It'll make the logic in ControllerResults cleaner and more straightforward.
- ResultUiThreadWrapper isn't too memory efficient because it allocates a
Runnable even if the wrappee's target method is empty.
However these callbacks don't get called often, and optimizing it would
make code more complicated, so I don't think it's worth optimizing.
- Now we can assume all the methods in activities except
AsyncTask.doInBackground runs on the UI thread, with some special exceptions
like MediaScannerNotifier.
In my previous abandoned change, I named methods that can run on BG threads
'*OnUiThread', but now there's no need to do that.
This also means we can minimize the use of synchronizations.
Change-Id: Ia6d9d2a266ebf5a4b23d712e9eaea3272adbd2a6
- Almost completely re-wrote ImapResponseParser layer
- We no longer use simple ArrayList and String to represent
imap response. We have classes for that. (Type safe!)
These classes are also NPE-free.
(which isn't necessarily a good thing, though)
- A lot of clean-ups and fixes in ImapStore.
- More tests for ImapStore.
Now ImapResponseParser moved to com.android.email.mail.store.imap.parser,
but inside, it's 99% new code.
This CL introduces many new classes, but most of them are small classes
to represent the IMAP response.
Problems that this CL fixes includes:
- Special characters in OK response
- Handling BYE response
- Case sensitivity
- ClassCast/ArrayIndexOutOfBound/NumberFormatException
- Handling NIL/literals at any position
Bug 2480227
Bug 2244049
Bug 2138981
Bug 1351896
Bug 2591435
Bug 2173061
Bug 2370627
Bug 2524881
Bug 2525902
Bug 2538076
Change-Id: I7116f57fba079b8a5ef8d5439a9b3d9a9af8e6ed
* Extract AccountAdapter from AccountFolderList
* Use callback instead of hardcoded launch of MailboxList
* Unit tests
Change-Id: Icafce1ef73a99fb61985c649620440656f9b51a3
* To avoid having to use a mock deviceId with FolderSync in validation, we now
simply use the real deviceId with the correct SyncKey ("0" for a new account,
or the actual sync key if the account already exists)
* Rework utility code that finds existing accounts
* Write unit test for findExistingAccount
Bug: 2589243
Change-Id: Ia532b2e209aec3aa01ca06617b4da78c3d986b32
* Three format strings had multiple replacement tokens, but the ordering
information was missing.
* In five languages, the translations reverse the order, and the formatter
crashes (because of types mismatching).
* This patch adds in the ordering information where needed
Bug: 2719864
Change-Id: I084e9c9ddab54901a5142710e8ef986223902c17
* Support required protocol changes
* Handle new security policies based on current device capabilities
Change-Id: Id1d629d41d957911344e6c503d28418f5e7e1386
Merge commit '77e2161559467ac94ffdbaa2d51716354741ae17' into kraken
* commit '77e2161559467ac94ffdbaa2d51716354741ae17':
Handle case of null organizerEmail in changed event
Merge commit '8c742a4c65e1ff2618e1005803edb65a42994fb6' into froyo-plus-aosp
* commit '8c742a4c65e1ff2618e1005803edb65a42994fb6':
Handle case of null organizerEmail in changed event
* A recent change assumed that organizerEmail couldn't be null while
an event was being added. However, there is an unusual case in
which it CAN be null, and this CL handles that case
* Regression caused by: SHA 7f448dcd47
Bug: 2719254
Change-Id: Idb8fc79c898bcd2e53fcc8b3e42d0ba67ba762fa
Merge commit '17c8b3388c1aceb5a4886f7d783e1db1913d9d05' into kraken
* commit '17c8b3388c1aceb5a4886f7d783e1db1913d9d05':
Remember to store modified organizerEmail
Merge commit 'b6a08f68d7c49835fffed0719e99c13b50fa525c' into froyo-plus-aosp
* commit 'b6a08f68d7c49835fffed0719e99c13b50fa525c':
Remember to store modified organizerEmail
Merge commit 'd3951041f613008dcbd3cd4b3ddebdad5ccab806' into kraken
* commit 'd3951041f613008dcbd3cd4b3ddebdad5ccab806':
Limit the number of attendees in a synced event
Merge commit '7f448dcd470ac509a85368a84f5a55c346ae7e70' into froyo-plus-aosp
* commit '7f448dcd470ac509a85368a84f5a55c346ae7e70':
Limit the number of attendees in a synced event
* If there are over 50 attendees in an event, we only store the
organizer as an attendee (the rest are redacted) and we set
the hasAttendeeData flag to 0
* If the user is the organizer, we reset the owner of the event
to a bogus address, which causes the UI to prevent edits to
the event (we can't upload without losing all of the attendee
information on the server). We also prevent the event from ever
being uploaded (belt & suspenders)
* If the user is an attendee, we allow changes to be uploaded
(this would be attendee status and free/busy), but the list of
attendees on the server is removed.
* We also mark events with redacted attendees, even though we don't
use that information currently. In a future version, however,
we could use this to indicate the redacted state to the user.
Bug: 2709816
Change-Id: I2b44af59c598cedf906af12bf9b4eaf7484b9d20
Merge commit '4c8adbc4aa81308e57ae129e9587ec50483af6a8' into kraken
* commit '4c8adbc4aa81308e57ae129e9587ec50483af6a8':
Fix bugs related to TZ handling for all-day events
Merge commit '027a6ddfaa7228854cb3c4238434f87fc69078b6' into froyo-plus-aosp
* commit '027a6ddfaa7228854cb3c4238434f87fc69078b6':
Fix bugs related to TZ handling for all-day events
* In bug 2703075, all-day events from time zones at GMT or later
appear a day early; this is because the time was calculated from
the GMT date/time of the event rather than the local date/time of
the event; this CL correctly changes this to use local date/time
* In bug 2707966, device-edited all-day events disappear in Outlook
and OWA after upsync; this is due to the fact that we store all-day
events in UTC on device, whereas we need to upload all-day events
using the original (local) time zone. In this CL, we save away
the original time zone and use it on upsync
* In our decoding of Exchange time zone information, we default to
local time when we can't find a time zone that matches the bias
and DST information; we should really default to a time zone with
the same bias, if one exists; we do that in this CL.
* Add/modify unit tests
Bug: 2703075
Change-Id: Id80c481ecc0eae980b2e91dae7f105f924cfca28
Merge commit '5c0f3b332f6104d6526d546a470cf7eb9978de47' into kraken
* commit '5c0f3b332f6104d6526d546a470cf7eb9978de47':
Fix problem w/ sync of large calendars (never syncs)
Merge commit '6bd7a167249727f4b7d4d4cfe713be421f400e51' into froyo-plus-aosp
* commit '6bd7a167249727f4b7d4d4cfe713be421f400e51':
Fix problem w/ sync of large calendars (never syncs)
* While working w/ Microsoft on this issue, we determined that Windows
Mobile 6.0 does not suffer from this issue; when we compared our
logs with those from the WM client, we noticed a difference in the
commands being sent to the server on initial sync (we send some extra
options whereas WM doesnot)
* As an experiment, I removed these options from the initial
sync, and this change solved the problem with a persistently unsyncable
account (time to receive: 60-70 seconds vs. > 240 seconds).
* The fix is to remove all "options" from the initial sync for a given
collection (i.e. with SyncKey=0)
* Note that Microsoft's documentation does not generally address the issue
of what should/should not be sent in an initial sync command
Bug: 2569162
Change-Id: Ib20ea56fb380ee8c9a01b139f7fa98b7ff505e7a
* While working w/ Microsoft on this issue, we determined that Windows
Mobile 6.0 does not suffer from this issue; when we compared our
logs with those from the WM client, we noticed a difference in the
commands being sent to the server on initial sync (we send some extra
options whereas WM doesnot)
* As an experiment, I removed these options from the initial
sync, and this change solved the problem with a persistently unsyncable
account (time to receive: 60-70 seconds vs. > 240 seconds).
* The fix is to remove all "options" from the initial sync for a given
collection (i.e. with SyncKey=0)
* Note that Microsoft's documentation does not generally address the issue
of what should/should not be sent in an initial sync command
Bug: 2569162
Change-Id: I69642cc0097296956029485abb85ac750303c865
We have singletons that store a Context passed to getInstance().
The problem is that when we call them, we casually pass any Context at hand.
If it's an activity (which is often the case), it'll never be GCed.
This CL make them store the application context insteaed.
Change-Id: I1abcc2c08d3f8201416d6c14720f041693823b4e
