[ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

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+
http://talk.maemo.org/attachment.php...1&d=1310074830
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

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

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

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

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.

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

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.

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

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.

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

You want the NameOwnerChanged signal

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

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?

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

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

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

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 :)

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

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

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

Not a problem, as it turns out it may yet be of use to me. As far as I can see as well there aren't any eavesdropping methods in any of the bindings, but I am also going along with the dbus_bus_add_match method and dbus_connection_add_filter to process what it spits out. Like I said though, Qt doesn't seem to like it all that much :)

For A, darn well I guess it was worth a try :) I'll do a bit of snooping myself to see if anything but from the 1 other app I tried launching (one of my own which doesn't have any DBus services) it appears that it does get triggered... If that is the case then it could come in handy for reducing drain on the battery

As for B, excellent that will be extremely helpful :D


Okay, I have some exceptional news, I have managed to get libdbus working in Qt and have subsequently managed to get it to properly snoop the top_application method calls. So now all that is required is for me to write the parsing code for those (or more correctly, the verification code) and then we are in business.

Have also updated the first page to take this into account as it means we will no longer have to modify .service or .desktop files for the application to work.

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

Wow..its great to know the project is progressing quite fast. Its hardly 4 days since I requested for an app like this and its already coming up. You're one of the better developers out here and its developers like you who give me and the others here one more reason to stick to our N900s!

Wish I could help, but I'm not so good in coding. :( I used to code in C & C++ once but since I'm caught up my Management course now, I hardly get a chance to come back to programming. Have to brush up my skiils some day.

Patiently awaiting a release. :)
Cheers!

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

Hmm, doesn't seem all that fast from this side, involves a lot of research and reading without all that much coding going into it to get stuff working. Maybe that's just me :)
As for "one of the better developers", I started C++ less that 2 months ago... Am still busy learning the ropes but this gives me a whole bunch of cool projects to do which all teach me useful stuff RE C++ development. I must admit though, there is something about the N900 that makes me wish I could keep it forever <3

I wouldn't worry too much about that, besides since I assume you're gonna be helping me bug test it you'll be doing more than enough :)

Now, for an update:
I can now monitor the top_application calls, lock the phone when they get picked up AND load the correct DBus service paths from the service files (despite the fact that they aren't all named correctly :)). I have also started work on using DBus to monitor ALL application launches which should make it considerably softer on battery usage.
However, there will now be a limitation on what the app can lock, most prominently that it will ONLY lock applications which have a .desktop file. I figure this isn't such a big deal since most console apps are capable of executing in under 2.5 seconds (50% of the original scan interval) which could make them undetectable, and xterm already has a desktop file.
Next, I am not sure if an application that has absolutely NO dbus calls in it will trigger this check (will do a bit of testing to confirm that) but I think it is safe to assume that most developers will have made use of at least the notification dbus calls, so that shouldn't be a massive problem.

And once that is all done, public alpha :D (with any luck, by this afternoon)


UPDATE:
Well, still spending my time trying to figure out why the hell adding a new instance of my ApplicationDescription class to a QList causes all the previous entries in the list to become equal to the new item... Even when all the pointers are different *bashes head into desk*.
As such, I may end up rewriting all the settings handling code to work purely off of SQLite rather than loading anything into memory (may work better anyway in some cases).

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

Okay, first public release (v0.2.0) which meets requirements for Milestone 2 is now available in extras-devel.

Here is a rundown of the available features in this release as well as some of the known bugs and missing features:

• Allows you to add .desktop files to the database by calling "applock --add <file>" from the command line
• Allows you to remove .desktop files from the database by calling "applock --remove <file>" from the command line
• Allows you to view a list of all your monitored applications by entering "applock --show-apps" from the command line
• Will automatically lock the phone if it detects an application being launched which has been blacklisted*
• Runs as a daemon on startup which can be stopped by running "initctl emit AppLockStopDaemon" from the command line.
• Provides some basic DBus methods on the com.sierrasoftworks.AppLock.Daemon interface
• Automatically detects whether a .desktop file should be monitored as a service or as an executable

* Currently there are two ways that AppLock uses to monitor application launches. The first occurs when an application registers itself on the DBus for any reason whatsoever (this doesn't require the application to provide a service, just use a DBus service like org.freedesktop.Notifications). The second hooks into Maemo's single instance launch code. This is what is usually used for apps like Contacts and MicroB and so as soon as this code is called AppLock will lock the Phone. Unfortunately, this means that apps which are run as scripts, or apps which DO NOT use any DBus methods will not be detected. There is the possibility of enabling a continuous check system to monitor these applications however this will drain battery and (if implemented) will be optional.

Known Bugs

• Just entering a desktop file's name (say "mebook.desktop") will NOT add it to the list of locked applications. You need to enter the full path ("/usr/share/applications/hildon/mebook.desktop") for it to work. This will be fixed in Milestone 3 releases.
• The first time the application attempts to lock the phone takes a bit of time, I am not sure what is causing this but hopefully I'll be able to figure it out and fix it. Otherwise, it isn't really a big deal since most apps take longer than the delay to finish loading anyway.

You can check this page for information on the current build status.

I look forward to getting page loads of bug reports :D

Re: [WIP] AppLock - An application locking daemon for Maemo handsets
 

Wow! Just saw the update now! Thanks a lot! Will check it out and report back as soon as possible. :)


Will we be seeing a GUI soon?

Cheers! :)

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

:) Just pushed v0.2.1 to the build que, fixes a few small issues (looks like the daemon wasn't starting up properly). Also, added some new commands which should prove useful and added a README file which has a whole ton of useful material in it for debugging.

As for a GUI, that is the plan. Though I haven't used a ListView in Qt before so that will be interesting ;)
Also, with any luck the lack of a GUI for the moment will keep away those who don't know how to use a terminal (and hence, those who don't know how to fix stuff if it breaks).

A quick list of some useful commands you may want for testing it:

Disabling the current daemon:
Re-enabling the daemon
Listen to events triggered by AppLock
Get the current status of AppLock
Just a note, the last DBus call will ONLY work with v0.2.1 so rather don't try it on v0.2.0 :)

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

I suggest you update the frontpage with the usage instructions and the important commands till we see a GUI. It would make it easier for people who would want to test it.

Cheers! :)

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

Ok, adding an application with the whole filename including the location of the desktop files would be a bit hectic at times but well, atleast it does the job. So no probs. :)
Hows your GUI work goin? ;)
I guess this thread would grab a lot more attention once the process of adding or removing applications is simplified and an apt GUI would replace the CLI.
Its great work! Keep it going.
Cheers! :)

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

Hi i installed applock but after installing wen i try to open it frm menu it is jus getting selected but not opening and later on wen i touch the screen its getting disselected and wen i try to lock the app frm x terminal it hows the folling lines

aap --add fring
Adding fring to the list of locked applications
Failed to open Desktop file

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

yehey! now my n900 is gonna be bullet proof! LOL!

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

add the whole path of the filename.
See usage details on the frontpage.

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

Yeah, the .desktop file for AppLock runs it with the "-ui" command. That command has not yet been implemented so the menu icon doesn't actually do anything yet. As soon as the GUI is done that will work though.

As for not adding when you only enter the file name, I will recode that part of it shortly to improve the file recognition. May even add the ability to select an app based on its name from the CLI. That being said, right now I am focusing on writing a GUI for the app that is usable, that should at least make it easier to control it all without having to use the CLI.

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

Hi i installed applock but after installing wen i try to open it frm menu it is jus getting selected but not opening and later on wen i touch the screen its getting disselected and wen i try to lock the app frm x terminal it hows the folling lines

aap --add fring
Adding fring to the list of locked applications
Failed to open Desktop file

add the whole path of the filename.
See usage details on the frontpage.

i tried to find the file frm file manager but i dint get . how to find the path of the file by easy method . suppose i am trying to lock conversation and also filebox .


thanking u

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

Hi I tried to find the file frm file manager but i dint get . how to find the path of the file by easy method . suppose i am trying to lock conversation and also filebox .

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

The .desktop files are stored in /usr/share/applications/hildon
The easiest way to view a list of them is to open up a terminal, type:
and choose the ones from there.

That being said, this app is still in a pre-beta state and really shouldn't be considered stable enough for popular use yet so be prepared for it to break. If it does, you best know how to recover from that (something which I suspect you don't. Then again, there is only one way to learn so let me know if you do find a problem and don't know how to fix it, I'll do my best to help).

I would however recommend that you wait at least until v0.3.0 comes out (it will have a GUI which will make this all a lot easier). I am busy working on the GUI and with any luck will have a usable version finished within the next 1-3 days.

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

Hi there.

sorry for possibly dumb question, but I'm little confused about result of methods currently used to determine applaunch.

At first page, you confirmed that i check for apps every 5 seconds. I'm not expert on this topic, but Your further investigation make me thought that You're working on/already did better method of getting applaunch info.

So, how does it looks now? Does this app impact CPU/RAM usage, and drain battery? i'm, out of curiosity, interested even if that isn't any problem in real-life situations, but theoretically should affect CPu/RAM/Battery by way that it works.

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

applock --add /usr/share/applications/hildon/conversations.desktop

applock --add /usr/share/applications/hildon/filebox.desktop

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

@Estel,
I will update the front page accordingly, the original pre-release/dev version of this app did check every 5 seconds to see what applications were running. However I have subsequently moved over to a DBus based approach which, while reducing reliability on certain apps, means it shouldn't drain your battery anywhere near as much as it would have.

To answer your question, the application does use RAM (all apps do), does use CPU whenever it detects an application being launched, and will drain your battery if you sit there opening and closing apps repeatedly. Unfortunately, due to the information that DBus transmits, AppLock has to check each and every app that is launched, so if you are in the habbit of launching LOTS of apps you may notice a small hit on battery life. Shouldn't be anything significant though.

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

Okay, excellent news. I have spent the better part of this morning working on v0.2.2 which aims to fix a whole lot of problems and make the daemon a lot more powerful.
This was after I discovered that typing a name on the keyboard opened the contacts list without locking the phone (even though it was blacklisted).

The changes aren't really all that noticeable unless you look at the DBus methods now available on the Daemon. There are now 2 new methods, the first is AddApp(string Name, string Path) and the second AddSearch(string Name, string DBus, string Search).

The AddSearch method adds a search filter to the specified DBus, currently only the Session bus is available, which is structured the same way as a watch expression in dbus-monitor. This allows you to listen for any method calls (signal and method_return support will be added soon) to any interface and any method.

To demonstrate how this works you can try entering this into a terminal when running v0.2.2:
This will then cause the phone to lock whenever you start searching through your addressbook from your desktop.

There is also the com.nokia.CallUI.ShowDialpad method which shows the phone when you enter a number, it can be watched in a similar fashion.

Additionally, adding a program to the application while the daemon is running will now take effect almost immediately (there is a 5 second delay) and now all the commands that are processed by the command line are handled on the daemon using DBus. This means I am one step closed to having a usable UI to work with.

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

And on a side note, when you upgrade to v0.2.2 (which is currently in the build que) remember to delete your /opt/applock/settings.db file. Due to the changes in how apps are monitored they are not compatible.

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

Thanks alot its working now but i want to lock conversations, contacts, phone and media player its saying the same error. the location which u hav send for conversations its not working again its giving the same error
applock --add /usr/share/applications/hildon/conversations.desktop
Adding /usr/share/applications/hildon/conversations.desktop to the list of locked applications
You have not specified a valid file

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

Doesnt work now.
I can add app to locked list successfully but the applock fails to lock the phone when locked app is opened.

BusyBox v1.10.2 (Debian 3:1.10.2.legal-1osso30+0m5) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/home/user # applock --add /usr/share/applications/hildon/dorian.desktop
Maemo applications must be run with the run-standalone.sh script!
QGtkStyle was unable to detect the current GTK+ theme.
Adding /usr/share/applications/hildon/dorian.desktop to the list of locked applications
Application Monitor Loaded:
Name: "Dorian"
Path: "/opt/maemo/usr/bin/dorian"
Name: "Dorian"
Executable: "/opt/maemo/usr/bin/dorian"
Added to list of locked apps
QSqlDatabasePrivate::removeDatabase: connection 'qt_sql_default_connection' is still in use, all queries will cease to work.

This is he output when I try locking Dorian.

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

ok lets see wen it works becoz those applications r only needed security more than other apps

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

one more important app i wanna lock i.e Evernote

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

how to find the path of an app by easy method

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

@warhark
That is weird, did you remove your old settings.db file? The new version uses a different format which is incompatible. You may also need to restart the daemon or launch an app that does lock the phone. I will look into rectifying that issue but it appears that the monitor's listen function blocks the update...

@brokensmile
As I said earlier, this app is really not ready for everyone. I'd recommend waiting for v0.3.0 with a GUI before you use it.
Answering your question, Conversations doesn't exist as a desktop file. If you want to add the conversations app to the monitor list then add:
/usr/share/applications/hildon/rtcom-messaging-ui.desktop

Just keep in mind that clicking in a notification will open it without locking the phone. That will be fixed with the GUI where I will have a list of special apps that have their own monitor details.

Some other apps that have multiple monitors:
Phone
Desktop File
Keyboard Launch Monitor - Pressing a number key on your desktop
Contacts
Desktop File
Keypress Monitor - Entering text while on the desktop

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

Yea I had cleaned old files and did a clean install again. I tried disabling and re-enabling the daemon, restarting the phone, etc but no solution. The same error keeps popping up. I had added the log of the output in my previous post. Did you see it? It has something to do with qgtkstyles. Is that a missing dependency?

Edit: Running applock -d in the terminal, somehow fixed the problems today morning and the device locks as it should. Will keep you posted. How is your GUI work going on by the way? :)

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

Not working again.

This is the most common error shown


Session Bus Monitors:
"addr_me_cs_addtocontacts"
QSqlDatabasePrivate::removeDatabase: connection 'qt_sql_default_connection' is still in use, all queries will cease to work.

Adding an application shows this error

QGTKStlyle was unable to detect the current GTK+ theme.

So well, it locks dorian successfully now. I dont know how that worked out. But it did.
All the other applications like contacts shows as added along with the error and fails to lock application.

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

Hmm, that is very weird. The qsql error appears to always pop up. That is an issue with Qt's SQL driver which for some reason doesn't close the DB connection when I call the close method... I wouldn't worry about that.

As for the GTK styles problem, I will look into it but it probably isn't an issue at the moment (UI stuff).

If you could try running applock --add as root and let me know if that works I would appreciate it. From what I can see it appears that because the daemon runs as a root user the created db file is created with root privileges.

In future if you start the daemon by running "sudo initctl emit AppLockStartDaemon" it should fix the problem (then the daemon will handle adding all the stuff to the database) though I am not sure why the daemon isn't starting with your phone. Mine seems to work here...

UI work is coming along, but I spent yesterday getting the new monitoring code working. Ideally I want the daemon to be working perfectly before I release any semblance of a GUI just to keep some of the less experienced users at bay.

Re: [ANNOUNCE] AppLock - An application locking daemon for Maemo handsets
 

Thankz alot now contacts r working.... and i hav a problem .... how to start applock again after i restart my fone ... wen i restart my fone again my apps r opening widout security code .. wen i try to run app its giving all help,n all ..... and wen i enter dis sudo initctl emit AppLockStartDaemon ... its showing password .... m not able to to enter any text or number