Notices

What is AppLock?
AppLock is an application designed to lock your phone if any one of a predetermined set of applications is launched. In layman's terms, if a locked application is started your phone will enter a lock state and wait for you to enter your password before continuing.

What does AppLock do?
AppLock runs in the form of a background daemon which listens to DBus messages. These messages are used to determine when an application is started on your phone, and if the application is on AppLock's blacklist it will promptly lock your phone. This allows you to prevent people from accessing certain applications on your phone without your permission.

Usage
NOTE - For more information on testing AppLock and for a comprehensive list of the commands and DBus methods and signals available please consult the README file. You can download the latest README file here.

AppLock can be used from either a CLI or using the user interface introduced in version 0.3.0
The user interface is by far the easiest way to go about using AppLock and can be accessed from your menu.

User Interface
v0.3.0+

As of version 0.3.0 a user interface is included with AppLock. This user interface is designed to simplify the process of adding applications to your lock list however please note that it is still in development and as such has a few bugs. I hope to address these bugs in my next release however for the time being here are the workarounds.

What still needs to be done?
Milestone 1: Pre-Release

• DONE - Add .desktop files from the command line
• DONE - Remove .desktop files from the command line
• DONE - Show a list of locked applications from the command line
• DONE - Run the daemon automatically upon boot
• DONE - Run the daemon automatically upon completing installation
• DONE - Setup symlinks in /usr/bin after installation
• DONE - Reliably detect when an application is launched
• DONE - Don't lock on an application that has been "unlocked" temporarily
• DONE - Fix an issue where lock instance records overwrite each other when loading...

Milestone 2: OSSO Service Support

• DONE - Add support for DBus launched applications
• DONE - Monitor top_application method calls
• DONE - Load service information from .service files and use it to match launched applications

RELEASED - Extras-Devel (v0.2.2)

Pre-Milestone 3: Stable monitoring

• TESTING - Reliably monitor DBus application launches
• TESTING - Reliably monitor non-DBus application launches
• DONE - Allow monitoring of any DBus method
• DONE - Finalise DB structure

Milestone 3: GUI & Compatibility
This milestone will be reached when a functional, and usable, GUI has been written and tested.

• DONE - Write a usable GUI
• DONE - Convert localised string names to their full counterparts
• DONE - Support adding apps that require multiple monitors to be secured
• DONE - Load .service files based on service names rather than file names

RELEASED - Extras-Devel (v0.3.3)

Milestone 4: Beta Release

• Have the ability to detect application launches based on their command lines (scripts will not launch their own executable)
• Determine feasibility of monitoring script launches (e.g. Conky)

This release will be pushed to Extras-testing until deemed stable enough for a full release. Any bugs found in earlier versions should have been fixed here.

Milestone 5: Final Release
This release will be pushed to extras as soon as all bugs have been rectified and the package is deemed stable enough for day to day use.

Source Code
Source code for AppLock is available on Gitorious, you can view, download and contribute to it by visiting
http://gitorious.org/applock-n900/applock
All development is done in Qt using the Nokia Qt SDK

Download
AppLock is available in the Extras-Devel repository or alternatively you can download the deb file from my website here:
http://sierrasoftworks.com/AppLock

Does it drains battry??( Since chacking apps in every 5 sec.)

The idea is that while your phone's screen is off or locked it will pause checking. But from what I can see it isn't too bad. Will run a proper test when I have a release-ready version to use for benchmarking.

Wow, that was fast.
From what I see, you've just announced the concept and provided a source of the work you've done till now. Am I right? And I see that its not a public release yet.
Great start. I'm awaiting the first public release from you.

Haha, I actually have only really got around to doing some testing of the code today and so I figured I might as well start a thread since people would want to hear about the progress on it.

Yeah, that is kind of the gist of it. I'll pop the source onto Gitorious pretty soon but at the moment I don't feel like doing so, it is kind of a mission to do all the initial setup stuff and with the dev work mainly including creating new classes etc it will probably be easier to leave it for when I have made a public release. That being said, if you want to look at the code it should only take a few minutes to put it on git.

At the moment I am being stubborn and still trying to get DBus method calls to be monitored, looks like I am going to have to make use of the core libdbus classes in order to get that low level stuff done which is a bit of a pain... (Looks up the dbus-monitor source code). With any luck though, if I do manage to get that right, that will drop the battery usage and complexity (as well as the risk factor) by a large margin which is always nice.

What it boils down to is that if I can stop being silly and actually follow my dev milestones I should have a pre-release built (Milestone 1) up by tomorrow sometime. Will keep you all posted.

You want the NameOwnerChanged signal

Hi jstokes, would I just connect that on the system bus? (Since that's where the top_application method is called) or is there something else I need to do instead?

Hi there,

I only did this for a widget that used DBus-GLib (the source is in the only thread I've made, but it probably won't help...) so I can't give any code samples that would be directly useful to you, but it generally goes like this:

1. Connect to the Session bus (programs register themselves here - note that service files for most programs go in /usr/share/dbus-1 and not /etc)
2. Create a org.freedesktop.DBus proxy
3. "Connect" (DBus-GLib terminology, sorry) to the NameOwnerChanged signal
4. When a program starts/stops, your program should pick it up. In the handler for NameOwnerChanged, you get (in the following order, as strings) the program's service name, the name of the "old owner" and the name of the "new owner". If there is no old owner (the string is null/empty etc. etc.) *but* there is a new owner (the string is *not* empty etc. etc.), the program is running. Else if old owner has a string but new owner does not, then the program has closed

However, and I just remembered sorry, this may not work great for you with many of the programs that come with the N900: they preload themselves so they will have already registered their names... You can call the method NameHasOwner with a D-Bus service name, though, to see if a program has already registered itself

http://wiki.openmoko.org/wiki/Org_freedesktop_DBus. and http://dbus.freedesktop.org/doc/dbus-specification.html may also prove helpful

Ah, yeah in Qt they have a signal that gets emitted by the QDBusConnection::interface() object called serviceOwnerChanged which does the same thing. Unfortunately it doesn't give me quite what I want as like you said, is just shows when an app launches.
What the libdbus classes give me (if you look at what dbus-monitor can do) is the ability to "eavesdrop" on which method calls are made across the bus. So all I really need to do is check to see if a call is made to the top_application function, if it is I grab the dbus path and compare it to the ones I have stored in memory (from the .service files) and if it matches any of my "locked" ones I just lock the phone.

All sounds great in theory but unfortunately the dbus bindings are having a field day with my Qt install (156 errors and counting... :P) because Qt doesn't use many of the headers that it depends on.
Overall, a royal PITA

Thanks anyway, am sure that those calls will come in useful at some point. I wonder, do you know if A) those signals are triggered on an app that doesn't make use of DBus and B) you can determine the source of origin?

If !B then I could always use them as a trigger for the check routine rather than having a continuous check (would just have to implement some kind of anti-spam protection), but if B it would be really, really useful

Sorry

AFAIA, none of the bindings support spying on method calls - signals only. But I could be wrong. I think dbus_bus_add_match can be used, but I don't know if you would be required to do any mainloop integration as you would with DBus-GLib when using the GLib mainloop and DBusConnection to listen to stuff.

Ouch :P

Regarding A: No, I believe, because the program hasn't registered itself with the bus

B: If you have an owner's name (something like ":1.56"), you can use GetConnectionUnixProcessID (part of org.freedesktop.DBus) to get the PID of the application asking.
I'm not entirely sure if this is what you want but run dbus-monitor, look for "method call sender=<some number here>" and try to see if that is what you want