summaryrefslogtreecommitdiff
path: root/rs/java/android/renderscript/ProgramFragmentFixedFunction.java
diff options
context:
space:
mode:
authorFelipe Ramos <felipe.wolff@gmail.com>2012-09-18 18:26:27 -0300
committerFelipe Ramos <felipe.wolff@gmail.com>2012-09-18 18:26:27 -0300
commitf35df5b509469fc7e71cdd70f4caec670bc5156f (patch)
treed6768fe4f7c479ac880559a7c79d83fdf11e6711 /rs/java/android/renderscript/ProgramFragmentFixedFunction.java
parent1e86994cd0e13f9084d3f4bd0060b9e34c935490 (diff)
Fixing services start order that impacts ICS - JB upgrade
JB has introduced LockSettingsService. When the phone is upgrading from ICS, that used another way to store lock settings, the LockSettingsService needs to import these settings to store in its database. This happens when the systemReady() method of this class is called by SystemServer. The problem resides in the fact that the DevicePolicyManagerService actually needs to access the LockSettingsService during its systemReady() initialization, causing invalid values to be read by it which propagates and ends up causing a invalid return in the method isActivePasswordSufficient. If user had a Google corporate account that enforces password related policies through Google Apps Device Policy (GADP) app in ICS, when he upgrades to JB, the GADP will throw a notification saying that the password doesn't meet the required policies and needs to be changed, incorrectly, since it wasn't touched during upgrade. This fix initializes the LockSettingsService before the DevicePolicyManagerService, which is the correct way since the latter uses the first in its initialization. This prevents this issue to happen, and probably future issues, depending on the way that LockSettingsService evolves. Change-Id: I3d4334a8b728f0ad9ae744cece430d15af25a0b7
Diffstat (limited to 'rs/java/android/renderscript/ProgramFragmentFixedFunction.java')
0 files changed, 0 insertions, 0 deletions