* Create new activity to encapsulate account upgrade
* Populate it with a list of legacy accounts, and progress bars for each
* Sidestep Welcome when there are legacy accounts to convert
* Super lightweight account migration:
- Account login info only
- no folders, messages, or attachments
* Scrub out old data
* Return to Welcome screen
As noted, the copies working (useable) POP & IMAP accounts, but does
not try to deal with folders, messages, or attachments.
Bug: 2065528
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
* 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
* 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.)
*** Reason for rollback ***
Rollback global lock because bug (now fixed) was not caused by
threading/concurrency.
*** Original change description ***
Evidence from failures, and inspection of source, leads me to believe
that SharedPreferences has some non-thread-safe paths. As a quick,
brute-force workaround, I'm putting a global lock around our use of it.
This is a bit inefficient, but cases of multiple threads writing to it
should be very rare.
Note, we don't have an explicit test for this (I will think about
finding a way to write one), but the evidence of this failure is that
after some amount of activity in the Email app, we see corrup
... description truncated by g4 rollback ...
Automated import of CL 149140
*** Reason for rollback ***
Problem found (bug in ICU encoder/decoder) so instrumentation no
longer required here.
*** Original change description ***
Heavily-instrumented Account.java that's looking for the precise moment
when an Account string gets corrupted. Looks for bad base64 strings
and bad store Uri's. Logs the error, and (optionally/disabled) throws
an exception (good for debugging).
BUG=1822859
Automated import of CL 149088
when an Account string gets corrupted. Looks for bad base64 strings
and bad store Uri's. Logs the error, and (optionally/disabled) throws
an exception (good for debugging).
BUG=1822859
Automated import of CL 148488
that SharedPreferences has some non-thread-safe paths. As a quick,
brute-force workaround, I'm putting a global lock around our use of it.
This is a bit inefficient, but cases of multiple threads writing to it
should be very rare.
Note, we don't have an explicit test for this (I will think about
finding a way to write one), but the evidence of this failure is that
after some amount of activity in the Email app, we see corruption in
the string mSenderUri.
BUG=1822859
Automated import of CL 148333
combine it with the same code that handles folder persistent data (in
the database). The schema is really simple; Rows with a folder id of
-1 are store data. This also adds the ability to use keys to store
multiple values, instead of a single string per account. Added/updated
unit tests.
3rd party stores will need slight code changes because the persistent
callbacks now accept keys.
BUG=1807499
Automated import of CL 148145
The current design for Store classes (e.g. IMAP) did not provide for
any persistent storage. This is the beginning of a mechanism to
provide that. It's quite simplisitic - each Store can read/write one
persistent string - but that's enough for the first simple use case
(saving some sync data for EAS).
The core changes here - suggest reviewing first - are in Account.java,
Store.java, and AccountUnitTests.java. Everything else is just
following the API change that was necessary.
Note that, by definition, this only applies to remote stores (e.g.
IMAP, POP3). You'll see everywhere that LocalStore is passed null, and
this is correct - LocalStore *is* persistent storage and does not need
access (so far, at least).
BUG=1786939
Automated import of CL 146061
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
Andrew Stadler