- Removed dead code/dead comment.
- Moved static utility methods to Utility.
- Renamed some methods.
- Changed the timing to call super methods.
Also:
- Internationalized formatSize()
- Added unit tests for createUniqueFile() and formatSize()
- createUniqueFile now uses File.createNewFile() instead of exists().
Change-Id: Ibc30e15b029ed5088954bd6fc9032e25dddf176e
Dial *#*#36245#*#* on the dialer to activate the debug screen.
"36245" = "email"
It's useful when
- There's no keyboard.
- There's no account set up yet.
(You can do it by entering the special username/password on new account
screen, but that's a bit of a pain.)
It's also easier to tell to people.
Also, removed "sensitive logging", which should never be used.
Change-Id: Id692f8b216f2d85abe1880c452d2067f170dac83
When connecting to an IMAP, POP3, or SMTP server using SSL, perform
an explicit test of the certificate's host name against the server's
host name. Refuse connection if they do not match.
Bug: 2807409
Change-Id: Ib223170f1a5d57323a88037ad30fec15c6bbce20
* During the fix of a previous late-Froyo issue, a change was made that
appeared superficially correct, but was semantically incorrect. This
changed the sense of the test for whether a reply email was required
and caused the referenced bug.
* The trivial fix is to replace the test with the (older) proper one
Bug: 2764551
Change-Id: I7c72366252cf0607aee31ee0d76aca96a7d5fc2b
Note: This does not appear in UX wireframes, this activity is going
away eventually, but it's a good testbed for ActionBar to be tried out.
Open issues:
1. Waiting for progress indicator support, using unattractive hack
2. Subtitle doesn't seem to work so putting account name in title
(which is the wrong font size for phone portrait mode).
Change-Id: Iee3cac7d4f30ea210bd8f3838b69ed12cd498375
* We need to encode the itemId and collectionId for SmartForward and
SmartReply
* Add unit test for the fix
* Small change + test to EasSyncService usage of URI encoding to use
a non-deprecated method
Bug: 2787725
Change-Id: I428b308b56cc359b8cdd9e42bc3f42c65b6797dc
Displays actionbar properly, and the two buttons work.
Submitting with one open issue:
1. The indeterminate progress indicator is not directly supported in the
ActionBar. We're waiting for a UI call or framework support. Until
then there is a placeholder using an incorrect icon to show progress.
Change-Id: Iaf1546931376cc5b540820cd0fc020ebd176dabf
* Use the new Account.getProtocol() method to determine whether an
Account "isMessagingController" (i.e. uses the legacy controller)
* Cache the result of this test, so that it's only done once per
Account
* Add unit test
Change-Id: I6a0ec789a84bdf30b55156e6337a627fb4e81a08
* The setup flow is changed such that the user is asked to activate
device administration before leaving the setup flow, rather than
having to wait for the notification to appear, etc.
* Accounts requiring security are created in a security hold state
to prevent initial sync until device administration is active
Change-Id: I7e33cf98466370ae27414b99018f7aee71e9e237
* We weren't sending the proper protocol version to GAL search, which
causes errors when using 12.1
* The simple fix is to send the agreed upon protocol version, instead
of the default (which is 2.5)
* Replace parsing of protocol version with lookup
Bug: 2793588
Change-Id: Ib2a255d8467004ce985d2d688b37066e1e09d78a
- Long-press an item to go into the selection mode.
- In the selection mode, tap items to toggle selected/non-selected.
This also means:
- No checkboxes any more.
- No context menu any more.
Color scheme hasn't been updated yet, so it looks a bit ugly for now.
Change-Id: I3cb6c45c1dc5461a234c9e9ab9e038c90a9fe8b2
* Minimum complex characters
* Password history (i.e. disallow re-use of past n passwords)
* Password expiration
* Password expiration is NOT yet supported in the framework; there
is a TODO in this CL and a trivial change will be needed when
support arrives; for now, we report this as unsupported
* The two implemented policies are testable
Change-Id: I477adbc000577c57d1ab1788378c97a60018c10c
* Add intent filter for application/eml and message/rfc822 mime types,
launching MessageView with a Uri
* Modify loadMessageTask to handle the Uri by parsing the attachment's
input stream with Pop3Message.parse(), and then creating an
EmailProvider message in a special Mailbox created to hold
"attachment" messages
* Delete all "attachment" messages after the parent message is closed
* Add unit tests
Change-Id: I20276ee006b9f05b889f3c808d3dc407cde26d49
- Now open, reply, reply-to, forward are handled by activity.
- Renamed onDelete. (I was thinking about renaming more methods, but I ditched
the idea because the current ones aren't that bad.)
Change-Id: Ie88e8cc3c6bd598199cfd9f4cd61d51e8b7023b7
* Introduce AccountFolderListFragment and its layout
* Extract all list-related UI into it
* Fix leaking cursor in AccountsAdapter and add unit test
Change-Id: Ica566847d97927b736f515d434c6691c82343290
- Introduced EmptyCallback to avoid the flood of null checks.
- Fixed some TODOs in MessageListFragment.
- Notably, sendPendingMessages() is now handled by the fragment itself,
rather than by the activity.
- Moved two DB accesss from the UI thread to a worker thread.
- Replaced the 'mailboxid < 0' check with isMagicMailbox(), which is more
explicit and easier to understand.
- Renamed some methods in preparation of moving to the activity.
Change-Id: Ie730c2c561050bbfa83a38252fcf09d59238f7ea
* Send policy key of "0" when validating; this gets us the policies
even if "Allow..." is enabled (currently, we simply don't see the
policies)
* If we don't support all of the policies, send back the response
code indicating support for partial support. If we get a positive
response back, then we're good to go - the server allows devices
with partial support. Otherwise, we fail as we always have - with
the toast indicating that the device doesn't support required
policies
* Remove PolicySet.isSupported() and ensure proper field ranges
within the constructor
* Update tests as appropriate
Bug: 2759782
Change-Id: I5f354a0e2d81844aff75d8a8a6de3b97f0020c1f
- Extracted MessageListFragment out of the MessageList activity.
- This is basically pure extraction, with the following conceptual change.
- Now the MessageList activity doesn't know the mailbox id or
the account id. If it needs these ids, it needs to ask the fragment.
- MessageListFragment.LoadMessagesTask tries to determine the account ID
if it's unknown.
Most code in MessageListFragment is directly copied from MessageList
with minimal changes (e.g. pass mActivity instead of 'this' as a Context).
There's a few cleaning up oppotunities. I'll work on them later in a separate
CL.
Change-Id: Ie004cc49b429f2cd8f9de73df5abb94f3054ea0a
One thing that bothers me regarding the new ImapStore is that there is no
tests to verify if the way how getImapId() uses a vendor policy hasn't changed.
This part is hard to test with a real vendor policy, and it can easily be
overlooked even if it's broken.
This CL offers ImapStoreUnitTests a way to test the interaction between
getImapId() and a vendor policy.
Also fixed a bug in VendorPolicyLoaderTest where it assumed the test apk
package name is "com.android.email.tests", but it may actually be
"com.google.android.email.tests" now. (Broken since the test makefile
used inherit-package.)
Change-Id: I8feb616ea28cb5cae5b4fba57e363771014ac599
Merge commit '7a358316ae1c52fadf7ce8470fc5d257d1a71eaa' into gingerbread
* commit '7a358316ae1c52fadf7ce8470fc5d257d1a71eaa':
Work around problem w/ large CalendarProvider2 transactions
* We're seeing binder transaction failures when we try to send more than around
1500 CPO's to CalendarProvider2 in a batch (the limit is related to memory
usage in binder transactions)
* When an event has A attendees and E exceptions in an event, we currently must
create A*E CPO's; this number can become very large and cause a binder failure
* The result of a failure is looping behavior, resulting in failed sync and very
much reduced battery life
* The workaround here is to redact all non-organizer and non-user attendees from
exceptions once we reach half of the maximum number of CPO's. This has been
determined empirically and is set to 500 CPO's in this CL
* We also reduce our sync "window" to 4 calendar/contact items per sync command
to help limit the potential size of our batch
* For later releases, we should reconsider this and see if something that is more
of a "fix", rather than a workaround, can be implemented
Bug: 2760514
Change-Id: I06ca1a1ae88c772342a9e46b5997c41678e95144
* We're seeing binder transaction failures when we try to send more than around
1500 CPO's to CalendarProvider2 in a batch (the limit is related to memory
usage in binder transactions)
* When an event has A attendees and E exceptions in an event, we currently must
create A*E CPO's; this number can become very large and cause a binder failure
* The result of a failure is looping behavior, resulting in failed sync and very
much reduced battery life
* The workaround here is to redact all non-organizer and non-user attendees from
exceptions once we reach half of the maximum number of CPO's. This has been
determined empirically and is set to 500 CPO's in this CL
* We also reduce our sync "window" to 4 calendar/contact items per sync command
to help limit the potential size of our batch
* For later releases, we should reconsider this and see if something that is more
of a "fix", rather than a workaround, can be implemented
Bug: 2760514
Change-Id: I2941b392ae1058a9ead8a79f0ac73f4eb345917d
