The code related to the comment didn't ship as part of Kitkat MR2 and instead will go out with the platform L release.
Change-Id: Ib9ece3390005b5b0217e0c5540322802b1c096ad
The reason why the UI is wedged is becasue it doesn't
see a state transition in the status. So now we detect the situation
where the user is trying to download an ineligible file and force
the status to indicate that it was a failure to dismiss the UI and
to show the correct error message.
Change-Id: I9264966830a317724bf2fe469ae570860ba7c2a9
b/13304929
The solution being delivered introduces a new folder capability:
UIProvider.FolderCapabilities.SHOW_RECIPIENTS which indicates a folder
should display "To: " in front of its participants list because it
is a folder containing outgoing mail or sent mail (thus viewing
recipients is more useful than senders). This capability is returned
for Drafts, Sent, and Outbox.
Note that extra work was required to make this function properly in
the widget we export to the launcher. See BaseWidgetProvider and
friends for details.
Change-Id: Ie7b077b8dd8934182de5e94a90fa163e8105faac
b/11658428
As per Yu Ping's advice, we alter the storage of all email addresses (from, to, cc, bcc and
replyto) to be stored in *decoded* format within our database. This makes them both human
readable when inspecting the database manually and alleviates the need to repeatedly decode
them before they are displayed anywhere in our UI layers.
As part of this bugfix, I resurrected several tests related to the LegacyConversions class out of
LegacyConversionsTests and into a new (not Suppressed) test class: LegacyConversionsTest
Change-Id: Ie2e3264646e25c08c4ba74f60b3e1090c052e6c6
Disable the code that translates the max attachment size column of
our db to the EmailProvider max attachment size column. They mean
different things as our max attachment size column refers to the max
size of any file that we can download where the EmailProvider's version
represents the max attachment size of a file that we can upload.
Change-Id: I93202766d7b1782c902f17ce20b2823aaf647ec4
b/11818312
We were using the existance of OPTIONS_CALENDAR_SYNC in the
bundle to indicate that syncing was possible, and it's value
to indicate whether automatic syncing should be enabled.
This is misleading.
Now, we check the serviceInfo for the account type to figure
out if sync calendar and contacts is possible, and use the
options passed in to indicate whether or not it should be
automatic.
Change-Id: I776519668c6630dc71153fb008218a7ca6357c74
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)
Tony Mantler