Closed Bug 755357 Opened 12 years ago Closed 12 years ago

Add a LockScreen API

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: dhylands, Unassigned)

References

Details

We need an API which allows the state of the lockscreen to be queried.

For example, determine if the phone is currently locked (lockscreen visible), pin required, or unlocked.

One example of where this would be used would be for the USB host mounting service (aka AutoMounter). When you plug the phone into a PC, the AutoMounter should only allow the phone to be mounted if its unlocked.
> We need an API which allows the state of the lockscreen to be queried.

And we need to send an event when the lockscreen changes state.
Having the API been able to unlock the lockscreen if there is no password for it would be good to. (Thinking of the NoLock app on Android)
Blocks: 751048
A "lock screen" is 100% a UI feature.  It's not part of the web platform.

What are we really trying to do here?  Is there a use case that can't be solved by the visibility API?
If the phone is "locked" then they don't want the phone to be automounted if you plug it into the PC.

If by "visibility API" you're referring to backlight on/off, then I don't see how that really helps.

Perhaps "lockscreen API" is actually a misnomer. Calling it a USB-locked API might be more appropriate. The lockscreen code would just call that API to lock and unlock (or enable/disable) USB connectivity.
Can't gaia set the automount setting to |false| just before showing the lock screen, and set it back to true after the screen is unlocked?
> Can't gaia set the automount setting to |false| just before showing the lock screen, and set it back 
> to true after the screen is unlocked?

Sure we can; it's just a question of whether you like the observer pattern or you prefer an explicit list of Things To Call at every logical "notify observers" point.  In general, the loose coupling one gets from observers is good, I think.

Specifically, if we want Gaia to disable automount just before showing the lock screen, then Gaia needs to know whether the lock screen will lock with PIN or not.  Which involves even more tight coupling.

Alternatively, the lock screen itself could disable automount, but then you're giving the lock screen app privileges to touch USB stuff.

Anyway, I'm happy if, as a first step, we have the Gaia figure out if the screen is locked-with-pin and disable automount.  We can see whether this ends up biting us.
The lock screen is a gaia concept.  The gaia "system" app shows the lock screen, and it "only" needs write access to Settings to do that.  It needs the same access to implement things like "airplane mode", so this doesn't elevate its privileges any more.

I'm strongly against promoting a transient UI concept to a first-class web citizen unless there's no other sane way to implement a feature.
So, then one way to solve this purely from the UI side would be to have 2 settings.
The first would be the user setting (does the user want automounting enabled) and the second would be an internal setting with no UI that would determine whether the automounter is actually enabled or not.

The lockscreen would then set the internal setting gated by the user setting.
The "internal" setting already exists in the Settings API, right?

I think the other "setting" you're referring to is something that would purely be part of the app controlling the Real Setting.

Setting.
The "user" setting needs to be persisted, and visible in the UI Settings (ala dnt.enabled)

The "real" setting, which actually controls the automounter, is also a setting ala dnt.enabled (at least that's how I've coded it so far)

We could make the real setting just not be visible on a UI, or we could add something new. I'm not quite sure what you're proposing.
Replacing the work real with internal.

The "user" setting needs to be persisted, and visible in the UI Settings (ala dnt.enabled)

The "internal" setting, which actually controls the automounter, is also a setting ala dnt.enabled (at least that's how I've coded it so far)

We could make the internal setting just not be visible on a UI, or we could add something new. I'm not quite sure what you're proposing.
I'm actually not 100% sure what problem we're trying to solve now :).  Was this bug filed based on a UX mockup?
This bug was filed in response to bug 751048
Thanks.

I'm not sure I understood the spec 100%, but it sounds like the requirement was for the phone to be unlocked before allowing *mounting* the phone.  (Not unlocked <=> host-can-be-connected.)  So if we did the following
 - change the automount.enabled setting so that a transition from true->false does *not* disconnect hosts
 - when locking the screen, save the value of the automount.enabled pref.  Set to false.
 - when unlocking, restore the previous saved value

I think we would comply with spec without needing any additional UI changes or new platform features.

Does that sound right?
The issue I have with that logic, is that we're changing the user preference. If this change is persisted and then the phone resets/power cycles/crashes, etc, then it will appear that the users preference will have become undone.

That's why I was proposing that we create 2 preferences. One which is only controlled by the user, and one which is only controlled by the lock-screen code.
Agreed.  My point is that the lockscreen code can persist its own preference.

An alternative is something like
 ums.enabled
 ums.activated

I don't have a particularly strong preference for either.
OK - so what I decided to do was to create ums.enabled as the user preference. And I created ums.mode to control the AutoMounter.

ums.mode can have 3 values, 0=disabled, 1=enabled, 2=disable when unplugged.

I submitted https://github.com/andreasgal/gaia/pull/1467 which implements the gaia side of things for review (no new API required).
Is this bug closed now that https://github.com/mozilla-b2g/gaia/pull/1467 is closed? Just wondering whether I can close the security review bug which depends on this.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.