b/14596165. When setting the package of the service intent,
query the app that implements the Email content authority since
that is the same app that should handle the intent.
Change-Id: I29a34a056516edda78acb83b9c89547ca0dc5ca1
Add support for abbreviated dates with no timestamp (eg, "2009-01-02") to
parseEmailDateTimeToMillis.
Bug:14496986
Change-Id: Ifc77cb75fd9e23536b48c8f6ecefc0e2e8f1cc2c
Detect fully qualified and abbreviated date/time stamps in parseDateTime.
Previously parsed fully qualified forms like 20090211T180303Z; now also
parses 20090211.
Bug:14279251
Change-Id: I9a99ae16a5c1fe87b977fbebdba307baa653d539
Performed some cleanup and updated the source key projection
to include an ID to make sure that EmailMessageCursor works
properly.
Change-Id: I272fac474de876fdd2a08136e0ba97b3f5dc2c7e
Found this issue when addressing the root problem for this bug and testing
with various mixes of text and html content in emails.
Change-Id: I875fd9fac85b07484c27db383e3ac4a3cb935ee6
These attachments have a contentUri where the attachment ID is not equal
to the ID of the actual attachment.
b/13900073
Change-Id: Ic62b8165be2e80bc47eac40dc9eb5ac53c3cd6c5
table and connect the data to the Settings object in the existing
location (SettingsColumns.MAX_ATTACHMENT_SIZE).
Change-Id: Iaf48995757511e1dfb65aa35ff6d81bbc47187bd
Conflicts:
src/com/android/email/provider/DBHelper.java
This supports the EasService design.
Yes, I just removed a startSync function from this interface last month. No,
I didn't quite know at the time that I'd be adding one back. :)
Change-Id: I19d9c7838473d8982560764fdba0056cba03d132
(cherry picked from commit 4a5b11d650)
the loadAttachment() call. This work was necessary to support
the new EasService & EasOperation infrastructure.
Change-Id: Idd507aec999596ccd4afa5f03ff2b3c2e38a9029
(cherry picked from commit efac8255ed75d22e60036e19e7a95f8407d18ad3)
This call lets the service know that the push settings for an
account have changed.
Change-Id: I7ed41853df6af6762c80283a2a3510ce41551657
(cherry picked from commit 446136a2278652c627068ecddff534de1ad431ab)
b/11551107
This is caused by ImapConnection.doLogin() only throwing
AuthenticationFailedExceptions and not other varieties of exceptions.
While fixing this bug, I discovered that the ConversationListFooterView
that is displayed in response to a authentication failure contains a
button called "Sign In" that didn't actually do anything. I made it
navigate to the incoming account settings fragment where the user is
free to change the relevant account credentials.
Change-Id: I2c772ecab18f3e57059eceeae01de08f1fdab4c2
Now the password entry is removed from AccountSettingsBasics,
and the user is taken to either SignInActivity or AccountSetupType
after hitting the next button. This is a lot closer to the
desired setup flow as it allows for oauth signin.
Ideally this is not what we will ship for Algol, but it put us
in a state where we could ship if we had to.
Change-Id: I5b28bccd27c515572e4947ca877bd1772732507d
Motorola 0009-IKXREL1KK-5011 patch. Hanging on an SSL handshake is
a real situation that needs to be handled. 30 seconds is more than
enough of a timeout to abort on a potential hang. The coincidental
thing is that there was a fix that was made a while back to email 1
that addressed the same issue in similar code. You can reference it
here: b/7583420.
Change-Id: I0533e57f8c5d45d241adb7f37d54ebe1f0ad9368
IllegalArgumentException. Make sure we catch it.
This fix comes from Motorola 0007-IKXREL1KK-3886 but part of that
patch was reverted because we already had found and fixed the
other problem.
Change-Id: I0b6aa1f91e7d2fa4dfc3af5ff590781c8812c14e
