The lockscreen.locked setting is used by the AdbController to determine if the phone is locked or not. On user/production builds this is used to control whether ADB is enabled or not. After flashing a full image, lockscreen.locked is reported to be true, even though the phone isn't actually locked (the FTU app is running). Once the phone is locked for the first time after the FTU app runs, then everything gets back into sync. This causes the ADB setting in the Settings app to be ignored, because the AdbController believes the phone to be locked. This is responsible for the behaviour reported in bug 1084955 comment 16 thru 20
Alive, I can go ahead and toggle this setting but the description makes me wonder if this is the right way to solve the problem. Inferring whether ADB is enabled from the value of this setting seems overloaded. In either case, the system app seems the right place to set this initial value (in FtuLauncher?) not the FTU app itself, so I would appreciate your input.
Adb uses lockscreen.locked as one (of many inputs) to determine whether adb should be enabled. It was considered to be a security issue to allow adb to be enabled when the phone is locked, which is why this is considered. It's been that way since 1.0 (for production builds)
This is a regression coming from lockscreenWindowManager refactoring. Set lockscreen.lock is the responsibility of LWM, And I think Greg had a fix.
Yes, I think the patch of Bug 1086175 has fixed this (10/26). I may verify this later.
We're tracking this for 2.1 in bug 1088157. The work for 2.2/master is in bug 1098997, I'm duping to that.