* 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
* Test for creation of a typical event
* Test for creation of an event with redacted attendees
* More to come
Change-Id: Ica117cd20a9e270ffe49efed75607e92b4d8ac90
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 '1e7009c89e7e9aa7b2434ea4dac9a998c03ac373'
* commit '1e7009c89e7e9aa7b2434ea4dac9a998c03ac373':
Work around problem w/ large CalendarProvider2 transactions
Merge commit 'b2422f28d0897f9795e698c2aaba68156e794cbd' into gingerbread-plus-aosp
* commit 'b2422f28d0897f9795e698c2aaba68156e794cbd':
Work around problem w/ large CalendarProvider2 transactions
Merge commit '7a358316ae1c52fadf7ce8470fc5d257d1a71eaa' into gingerbread
* commit '7a358316ae1c52fadf7ce8470fc5d257d1a71eaa':
Work around problem w/ large CalendarProvider2 transactions
Merge commit '7a358316ae1c52fadf7ce8470fc5d257d1a71eaa' into froyo-plus-aosp
* commit '7a358316ae1c52fadf7ce8470fc5d257d1a71eaa':
Work around problem w/ large CalendarProvider2 transactions
Merge commit 'a3b1814284a059f7728410eddb84986022d34685'
* commit 'a3b1814284a059f7728410eddb84986022d34685':
DO NOT MERGE - Revert workaround for KeyguardLock problem
Merge commit 'a3962dc7cf7df3ed7f135bdd4f6b934f75b51ee4' into gingerbread-plus-aosp
* commit 'a3962dc7cf7df3ed7f135bdd4f6b934f75b51ee4':
DO NOT MERGE - Revert workaround for KeyguardLock problem
Merge commit '572c06f91be8c809b8978d985259564f88c6f212' into froyo-plus-aosp
* commit '572c06f91be8c809b8978d985259564f88c6f212':
DO NOT MERGE - Revert workaround for KeyguardLock problem
Merge commit '572c06f91be8c809b8978d985259564f88c6f212' into gingerbread
* commit '572c06f91be8c809b8978d985259564f88c6f212':
DO NOT MERGE - Revert workaround for KeyguardLock problem
This reverts commit 3ee0cad5f5.
Because commit 284b62e1b8c3419bfd02c6fea5ba0a68146c06f8 fixes the underlying
conflict between DeviceAdmin policies and apps attempting to disable the
Keyguard Lock, this patch is no longer required.
Accounts with a server policy requiring a device PIN or Password will
now work properly.
Bug: 2737842
Change-Id: I533c27a01a8a331dc11a0cb84bcc78f48edf621c
* 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
Merge commit '3ee0cad5f5e21a24dbe43d21afaac1dd76a2059b' into froyo-plus-aosp
* commit '3ee0cad5f5e21a24dbe43d21afaac1dd76a2059b':
DO NOT MERGE Workaround for KeyguardLock problem
Merge commit '3ee0cad5f5e21a24dbe43d21afaac1dd76a2059b' into kraken
* commit '3ee0cad5f5e21a24dbe43d21afaac1dd76a2059b':
DO NOT MERGE Workaround for KeyguardLock problem
- Controller.Result is now a class rather than an interface,
so subclasses don't have to implement empty methods.
- Replaced Threads with AsyncTasks, which is more light weighted
because it uses pooled threads.
- Removed the Result argument from Controller's methods.
These argumetns weren't used, except in serviceCheckMail.
Regarding serviceCheckMail, the new code behave differenly from the old code.
If there's already listeners registered when it's colled, they wouldn't get
called in the old code, but they will in the new code.
But I think this difference is okay because that's how it works for
POP/IMAP accounts.
Change-Id: I37a857ce7c089c1a411cb7f1fcfcb72c9f5fd2a6
This fixes the following exception.
java.lang.UnsupportedOperationException
at android.test.mock.MockContext.getApplicationContext(MockContext.java:82)
Bug 2725552
Change-Id: Iaca177defe5f5e836211c58270379da056fa64e0
* Moves all list-related implementation to new MailboxListFragment
* One item that remains to be done is to remove the dependency on the
activity for handling context menu (longpress) in the list.
Change-Id: I7b5769d9d81fb685cf480de3d3e18b4e1c078f2d
