* This first implementation integrates with early CLs for
Email app integration with device security
* Check for policies added to validation process
* If the server has no policy requirements, there is no change
to the existing process
* We automatically declare a set of policies to be unsupported
if any are known to the sync adapter to be unsupported
(e.g. no attachments or password history)
* We call isSupported (PolicySet) to determine whether other
policies use values that the OS can support (e.g. password length,
inactivity time, etc.)
* Depending on whether the server's policies are unsupported or
supported, we throw the proper exception back to the caller
Change-Id: I704cb2151dd87f54c83c2aa23976a8ac8e2c501a
* Exception is due to the presence of values in ContentValues that
are null (would normally expect those fields to be absent)
* Fix all relevant cases that might produce an NPE in this case
Bug: 2422815
Change-Id: I637a21307c2d518912edce093de90a06d94614e5
* Create notification to display when syncs fail due to security
* Create psuedo-activity (no UI) to manage device admin state transitions
* Clean up and flesh out SecurityPolicy APIs'
* Add placeholders in EasSyncService showing how to react when policies
are not met and sync cannot continue.
Note: There are some STOPSHIP todo's at the top of SecurityPolicy.java.
These should explain any code that you might think is "missing".
* Exchange calendar sync created Event records for exceptions
that didn't have a _sync_id
* This caused google calendar sync to try to upload these
Events as new, which caused an Exception to be thrown
* Fixed EAS calendar sync adapter to generate a _sync_id for
exceptions in the form <parentId>_<exception start time>
Bug: 2420732
Change-Id: I46769175ca89ffa4cec4fe8b0c35ef2242536185
* Rename SECURITY_POLICIES_REQUIRED to SECURITY_POLICIES_UNSUPPORTED
* Create new pathway for SECURITY_POLICIES_REQUIRED, making it advisory
* Cleaned up strings for account setup error dialogs
* Refactored AccountSetupExchange.onActivityResult() to split up the
three primary use cases, making them more readable.
* Always finish() in AcccountSetupAccountScreen, because it's usually
cleaner to return to the previous screen (enter username & password).
* Exchange account validation tests security policies by sending a
FolderSync command and determining whether this generates an
error
* Unfortunately, we use the real deviceId when sending the command
and this causes the next real sync to fail such that all data is
wiped and reloaded (the bug)
* The fix is to use a false device id while doing validation
Bug: 2415185
Change-Id: Ibe577e36f770d737ba5952b347aa0d73bda3568a
* Create full TZI strings for upload of events (previously, we
omitted DST information)
* Add documentation to some unit tests
* Put in correct logic for determining if upload needed
* Fix problem w/ parsing empty tags
Change-Id: I268ce8a2db30b3cfdf0e44f6a78befd6bd933243
remove-exchange-support.sh makes it possible to build the email app without
exchange support.
This script:
- removes all packages under com.android.exchange.
- removes all lines surrounded by EXCHANGE-REMOVE-SECTION-START and
EXCHANGE-REMOVE-SECTION-END
And the resulting source should still build and run fine.
Bug: 2369784
New behavior:
* There are two primary paths through this activity:
* Edit existing:
* Load existing values from account into fields
* When user clicks 'next':
* Confirm not a duplicate account
* Try new values (check settings)
* If new values are OK:
* Write new values (save to provider)
* finish() (pop to previous)
*
* Creating New:
* Try Auto-discover to get details from server
* If Auto-discover reports an authentication failure:
* finish() (pop to previous, to re-enter username & password)
* If Auto-discover succeeds:
* write server's account details into account
* Load values from account into fields
* Confirm not a duplicate account
* Try new values (check settings)
* If new values are OK:
* Write new values (save to provider)
* Proceed to options screen
* finish() (removes self from back stack)
* Added unit test for new loadFields method
Bug: 2412300
Our original plan was to disable both authenticators by default, and enable
one of then on boot. However, it turned out existing exchange accounts will
be removed if there's no enabled authenticators for the account type.
So, instead, in this patch we initially enable only the default one, and switch
to the other one on boot if the vendor policy indicates so.
(If a device has a vendor policy apk, it should also have the email app
preloaded, so changing the label at boot time isn't too late.)
Bug: 2382710
Per code review suggestions, clean up exception handling, and add
commentary to make intended behavior more explicit.
Followup to: 0434fef1f6
Bug: 2413388
* Create unit test to reproduce crash
* Fix handling of empty bundle (the default return value)
* Clean up some exception handling in the policy module loader, which
reduces some unneeded logging.
Bug: 2413388
* Begin wiring into system DevicePolicyManager requirements
* Semi-real implementations of isSupported() & isActive()
* Added new API (placeholder) updatePolicies()
* Updated existing unit tests as needed
Bug: 2387961
* scrub all external strings to keep them compliant for IMAP protocol
* move Build.MODEL to x-android-device-model
* send x-android-mobile-net-operator
* send AGUID
* unit tests for above
* retrieve providers from VendorPolicyLoader
Bug: 2332183
Moved Eas.ACCOUNT_MANAGER_TYPE to Email.EXCHANGE_ACCOUNT_MANAGER_TYPE.
This constant is not related to the exchange protocol, and referred in
a lot of different places. Moving it out of the package will make it a lot
simpler when removing exchange dependency.
* Add code to upsync exceptions; debug same
* Use AccountManager to handle sync keys (as w/ Contacts)
* Add unit tests in next CL
Change-Id: Ib8526d70de33ed7e551b9713a3bbf1ad80612948
* Added support for reminders and recurrences
* Note that Duration class is copied from CalendarProvider with only
formatting changes
Change-Id: Icf399df422f813ba8e7880646bfbc96a2156a204
* Turns out that DURATION is required by CalendarProvider, and
DTEND has a different meaning than it does to EAS
* Fix downsync to create proper recurring events
Change-Id: Ibf85422de73579a93de89b2c27c13f96994bedc8
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