- Fix misnomered fields. (e.g. static mMember -> static sMember)
- Reduce visibility. (e.g. mark as private)
- Mark final / static if possible.
Note it's on master.
There's a lot more cleanup oppotunities in the activities, but they're going
to go through a major overhaul, so I didn't bother.
Backport of b3f7dd0169
Change-Id: Ic33f9518f23805716e2aec0ab42edb92107e066c
* Existing code reloads long POP/IMAP messages at every sync
* If the server is POP3, or the IMAP message is unread, this
will lead to redundant notifications of new message arrival
* The fix avoids repeated message reload
* Backport of I8dc22966282655c8645362d672a083a1c37f554c (master)
Bug: 2892705
Change-Id: I1ce7de0dc25abc8ace544849dc3d437fcd1459f0
Merge commit '126c9216b13d915b24a057b5b50bb8ea9826ba7e' into gingerbread
* commit '126c9216b13d915b24a057b5b50bb8ea9826ba7e':
Block oversize attachments from being sent
* Attachments that come in with a file:// URI do not support the complete
set of OpenableColumns columns. To handle this better:
1. Obtain the openable values in two separate queries, in case one or
the other is supported (but not both).
2. If the size is not reported but it is a file:// URI, attempt to
measure it directly.
3. If the size cannot be obtained, do not upload the attachment
Bug: 2948965
Change-Id: Ic5160d39efd65eaca40ceba0dd93c3b035d2871e
* When a sync fails due to a provisioning error (on initial sync
or after policies are refreshed on the server), sync mailboxes go
into a "hold" state until the security error is resolved. Meanwhile,
the account mailbox handles provisioning. If this is NOT successful,
we put a hold on the account and go through the UI steps of setting
up security on the device. When this is done, we release the hold on
the account, which releases the hold on the mailboxes.
* If provisioning IS successful, however, a refresh of the existing
settings would be an example, we do NOT release the adapters, and
this is the bug we're seeing.
* This CL simply causes any held mailboxes in a successfully provisioned
to be released from the hold
Bug: 2865623
Change-Id: I59e780e9bd4ea908182b786dfd0e5851f5bf5f3b
* In a recent change, we mistakenly removed the logic for handling
too-long inactivity timeouts; we should just fall back to the maximum
since this is stricter than what we're being asked to enforce
* Restore this logic and update the unit test
* The regression was caused by change Ida5663a9, to wit:
Backport: Handle "Allow non-provisionable devices" properly
Bug: 2886746
Change-Id: I99cf9a37441b80477cc1c2c7ec2a78f8a14a83da
Merge commit 'a30631da1cae25be3f75137133297e30cef2db9c' into gingerbread
* commit 'a30631da1cae25be3f75137133297e30cef2db9c':
Clear password related policies in PolicySet when p/w not required
* In a recent change, we mistakenly removed the logic for handling
too-long inactivity timeouts; we should just fall back to the maximum
since this is stricter than what we're being asked to enforce
* Restore this logic and update the unit test
* The regression was caused by change Ida5663a9, to wit:
Backport: Handle "Allow non-provisionable devices" properly
Bug: 2886746
Change-Id: I99cf9a37441b80477cc1c2c7ec2a78f8a14a83da
Merge commit '05b0bb56254d9ed924dff4c09ad227eec611a695' into gingerbread
* commit '05b0bb56254d9ed924dff4c09ad227eec611a695':
Release held mailboxes after policy refresh
* When a sync fails due to a provisioning error (on initial sync
or after policies are refreshed on the server), sync mailboxes go
into a "hold" state until the security error is resolved. Meanwhile,
the account mailbox handles provisioning. If this is NOT successful,
we put a hold on the account and go through the UI steps of setting
up security on the device. When this is done, we release the hold on
the account, which releases the hold on the mailboxes.
* If provisioning IS successful, however, a refresh of the existing
settings would be an example, we do NOT release the adapters, and
this is the bug we're seeing.
* This CL simply causes any held mailboxes in a successfully provisioned
to be released from the hold
Bug: 2865623
Change-Id: I59e780e9bd4ea908182b786dfd0e5851f5bf5f3b
* Backport from master branch
* 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: Ida5663a9b35c75ecc61a5f442be0bd60b433cb73
* Handle status 5 for Ping command (heartbeat of out range)
* Write unit test for heartbeat reset
Bug: 2834195
Change-Id: Ic7952a4b296cf15c6ba895d6579fe7956b171e5b
* Backport from master branch
* 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: Ida5663a9b35c75ecc61a5f442be0bd60b433cb73
* Handle status 5 for Ping command (heartbeat of out range)
* Write unit test for heartbeat reset
Bug: 2834195
Change-Id: Ic7952a4b296cf15c6ba895d6579fe7956b171e5b
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
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
avoid applying emma processing on local static libraries so that code
coverage result is not diluted.
Change-Id: I6090fc82498fff2e7da8ce22348f56dbc3d3ee60
Merge commit '7a358316ae1c52fadf7ce8470fc5d257d1a71eaa' into gingerbread
* commit '7a358316ae1c52fadf7ce8470fc5d257d1a71eaa':
Work around problem w/ large CalendarProvider2 transactions
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
Merge commit '3ee0cad5f5e21a24dbe43d21afaac1dd76a2059b' into kraken
* commit '3ee0cad5f5e21a24dbe43d21afaac1dd76a2059b':
DO NOT MERGE Workaround for KeyguardLock problem
* The device policies that enforce the use of a device PIN or password
can be sidestepped by apps that implement KeyguardManager.KeyguardLock
* This renders the policies unuseable
* To prevent this, the email app now scans for any packages holding the
DISABLE_KEYGUARD permission. The existence of any non-system app
with this permission will put all security-enabled EAS accounts into
a security hold, and post a dialog describing the problem.
* The user must uninstall any such app(s) in order to sync their EAS data.
Bug: 2737842
Change-Id: I4c96d76b12d9242b5c755dd60d7578a825fae597
