The logic for this is quite simplistic, for now: When the store
reports that it has new messages, it triggers a service refresh,
just as if a pull-mode interval had expired and it is time to
check the server.
Note, unfortunately at this time there are no tests, because there
are not currently any good test seams in MailService.java.
Original author: stadler
Automated import of CL 145230
The logic for this is quite simplistic, for now: When the store
reports that it has new messages, it triggers a service refresh,
just as if a pull-mode interval had expired and it is time to
check the server.
Note, unfortunately at this time there are no tests, because there
are not currently any good test seams in MailService.java.
BUG=1776149
Automated import of CL 145227
1. Generalize the code for the various spinners that control
account check frequency.
2. Provide an API for looking up store attributes (and refactor
existing instatiateStore logic to use it).
3. Cleanup the old code that was used to setup frequency spinners.
4. Hardwire Exchange accounts to default into push mode.
Notes to tester:
1. For each account type (POP, IMAP, EAS) we need to check that
auto & manual creation "do the right thing" for frequencies.
POP & IMAP should offer "none" or time intervals, while EAS
should offer "push", "none", or time intervals.
2. EAS accounts should default to "push", all others to "15 min"
3. Make sure that you can edit existing account settings and see
the right choices (only EAS should be offered push).
4. I couldn't write an automated test for the mail checker service,
please confirm that POP & IMAP accounts are checked at the right
intervals (or never, if set for "none".)
Original author: stadler
Automated import of CL 145128
1. Generalize the code for the various spinners that control
account check frequency.
2. Provide an API for looking up store attributes (and refactor
existing instatiateStore logic to use it).
3. Cleanup the old code that was used to setup frequency spinners.
4. Hardwire Exchange accounts to default into push mode.
Notes to tester:
1. For each account type (POP, IMAP, EAS) we need to check that
auto & manual creation "do the right thing" for frequencies.
POP & IMAP should offer "none" or time intervals, while EAS
should offer "push", "none", or time intervals.
2. EAS accounts should default to "push", all others to "15 min"
3. Make sure that you can edit existing account settings and see
the right choices (only EAS should be offered push).
4. I couldn't write an automated test for the mail checker service,
please confirm that POP & IMAP accounts are checked at the right
intervals (or never, if set for "none".)
BUG=1776149
Automated import of CL 144953
the shipping client will include the necessary generic pieces for
configuring an Exchange client (e.g. account setup) but will not
include actual Exchange client code (e.g. transport / protocol).
Also added a "sample code" implementation of Exchange for use
as a starting point for implementors. (Note, this will not ship
in Donut, it's a placeholder for working on the "framework"
aspects.)
Original author: stadler
Automated import of CL 144527
the shipping client will include the necessary generic pieces for
configuring an Exchange client (e.g. account setup) but will not
include actual Exchange client code (e.g. transport / protocol).
Also added a "sample code" implementation of Exchange for use
as a starting point for implementors. (Note, this will not ship
in Donut, it's a placeholder for working on the "framework"
aspects.)
BUG=1740621,1740626
Automated import of CL 144525
errors, inconsistencies in passing Application/Activity/Context, and
some error handling cleanups. These are all changes that would have
probably been made before the original submits, but I didn't want
to fix them in the integration step.
Original author: stadler
Automated import of CL 144522
errors, inconsistencies in passing Application/Activity/Context, and
some error handling cleanups. These are all changes that would have
probably been made before the original submits, but I didn't want
to fix them in the integration step.
BUG=1740621
Automated import of CL 144520
*** Reason for rollback ***
Roll back US Spanish import because it made the build too big.
*** Original change description ***
Import US Spanish translations, and a few Japanese changes.
Automated import of CL 144355
If you absolutely must add a string after string freeze, and that
same string has already been translated for another application
in a similar context, you can copy the translation by specifying
it by numeric message ID.
Fix the incorrect IDs I had told people for a couple of strings,
add the script that will make a flat-file version of translations
so you can find out the IDs yourself, and reimport the translations
for the couple of applications that wanted to copy translations.
Original author: enf
Merged from: //branches/cupcake/...
Original author: android-build
Merged from: //branches/donutburger/...
Automated import of CL 143313
If you absolutely must add a string after string freeze, and that
same string has already been translated for another application
in a similar context, you can copy the translation by specifying
it by numeric message ID.
Fix the incorrect IDs I had told people for a couple of strings,
add the script that will make a flat-file version of translations
so you can find out the IDs yourself, and reimport the translations
for the couple of applications that wanted to copy translations.
Original author: enf
Merged from: //branches/cupcake/...
Automated import of CL 143164
