2011-02-09 02:54:56 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2011 The Android Open Source Project
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
|
|
|
package com.android.email.service;
|
|
|
|
|
|
|
|
import android.app.Service;
|
|
|
|
import android.content.Context;
|
|
|
|
import android.content.Intent;
|
|
|
|
import android.os.IBinder;
|
|
|
|
|
Rewrite of security policy handling and service code
* Remove PolicyService APIs policiesRequired, policiesUpdated,
isSupported, clearUnsupportedPolicies, and isActiveAdmin
* Add PolicyService API setAccountPolicy, which is the sole
method by which security policies are promulgated
* Add protocolPoliciesEnabled and protocolPoliciesUnsupported
to the Policy class; these are packed, localized strings
indicating policies that the protocol itself have enabled
and/or cannot support (i.e. these are policies that are
unknown to the DPM, e.g. don't load attachments)
* Differentiate in security notifications between three kinds
of policy changes - changes that don't require user
intervention (e.g. reducing requirements), changes that
require user intervention (the legacy notification), and
changes that make the account unsyncable (e.g. the server
adding an unsupportable policy). Handle all possible policy
changes cleanly.
* Make security notifications per account (with multiple
accounts, notifications would get arbitrarily munged)
* Expose ALL enforced policies via the account settings
screen in two categories: policies enforced (including
both policies enforced by the DPM and policies enforced
by the protocol) and policies unsupported (note that these
can only be seen if policies are changed after an account
is created; we do not allow the creation of an account
when any required policies are unsupported). Add a
button that forces a sync attempt, for accounts that
are locked out, but whose policies have changed on
the server (this would otherwise require a reboot).
* Updated unit tests
Bug: 5398682
Bug: 5393724
Bug: 5379682
Change-Id: I4a3df823913a809874ed959d228177f0fc799281
2011-10-20 17:13:02 +00:00
|
|
|
import com.android.email.SecurityPolicy;
|
|
|
|
import com.android.emailcommon.provider.Policy;
|
|
|
|
import com.android.emailcommon.service.IPolicyService;
|
|
|
|
|
2011-02-09 02:54:56 +00:00
|
|
|
public class PolicyService extends Service {
|
|
|
|
|
|
|
|
private SecurityPolicy mSecurityPolicy;
|
|
|
|
private Context mContext;
|
|
|
|
|
|
|
|
private final IPolicyService.Stub mBinder = new IPolicyService.Stub() {
|
2011-04-28 00:12:06 +00:00
|
|
|
public boolean isActive(Policy policy) {
|
|
|
|
return mSecurityPolicy.isActive(policy);
|
2011-02-09 02:54:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
public void setAccountHoldFlag(long accountId, boolean newState) {
|
|
|
|
SecurityPolicy.setAccountHoldFlag(mContext, accountId, newState);
|
|
|
|
}
|
|
|
|
|
|
|
|
public void remoteWipe() {
|
|
|
|
mSecurityPolicy.remoteWipe();
|
|
|
|
}
|
|
|
|
|
Rewrite of security policy handling and service code
* Remove PolicyService APIs policiesRequired, policiesUpdated,
isSupported, clearUnsupportedPolicies, and isActiveAdmin
* Add PolicyService API setAccountPolicy, which is the sole
method by which security policies are promulgated
* Add protocolPoliciesEnabled and protocolPoliciesUnsupported
to the Policy class; these are packed, localized strings
indicating policies that the protocol itself have enabled
and/or cannot support (i.e. these are policies that are
unknown to the DPM, e.g. don't load attachments)
* Differentiate in security notifications between three kinds
of policy changes - changes that don't require user
intervention (e.g. reducing requirements), changes that
require user intervention (the legacy notification), and
changes that make the account unsyncable (e.g. the server
adding an unsupportable policy). Handle all possible policy
changes cleanly.
* Make security notifications per account (with multiple
accounts, notifications would get arbitrarily munged)
* Expose ALL enforced policies via the account settings
screen in two categories: policies enforced (including
both policies enforced by the DPM and policies enforced
by the protocol) and policies unsupported (note that these
can only be seen if policies are changed after an account
is created; we do not allow the creation of an account
when any required policies are unsupported). Add a
button that forces a sync attempt, for accounts that
are locked out, but whose policies have changed on
the server (this would otherwise require a reboot).
* Updated unit tests
Bug: 5398682
Bug: 5393724
Bug: 5379682
Change-Id: I4a3df823913a809874ed959d228177f0fc799281
2011-10-20 17:13:02 +00:00
|
|
|
public void setAccountPolicy(long accountId, Policy policy, String securityKey) {
|
|
|
|
mSecurityPolicy.setAccountPolicy(accountId, policy, securityKey);
|
2011-02-09 02:54:56 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public IBinder onBind(Intent intent) {
|
|
|
|
// When we bind this service, save the context and SecurityPolicy singleton
|
|
|
|
mContext = this;
|
|
|
|
mSecurityPolicy = SecurityPolicy.getInstance(this);
|
|
|
|
return mBinder;
|
|
|
|
}
|
|
|
|
}
|