This fix is for the bug that some people have when installing applications from the store in an Open Mode device.
After the install process completes all open applications are forcefully closed.

NOTE! This fix is only for Open Mode devices, do not try to do this on a Closed Mode device or you will end up in MALF state!

How the fix works: After an install applauncher reloads it's state from /var/run/applauncherd/saved-state file. If the system is in Open Mode and aegis keys have a conflict with Closed Mode keys then /var/run/ is not mounted as aegisfs. Applauncher notices this and forces a shutdown on all applications it handles. (Thanks for Eztran for figuring this out)

The fix is to compile libapplauncherd.so with debug flags so that it only notes the need to relaunch apps without actually doing so.

• Download the replacement libapplauncherd.so
• verify the md5sum of the downloaded file (should be 238b47681749eb2bf78a819ac6bb42f7)
• rename your existing lib to backup
• copy the new library on it's place
• reboot and you're done

~ $
~ $ devel-su
Password:

BusyBox v1.20.0.git (MeeGo 3:1.20-0.2+0m8) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ #
~ # wget http://www.swagman.org/juice/libapplauncherd.so
--08:33:55-- http://www.swagman.org/juice/libapplauncherd.so
=> `libapplauncherd.so'
Resolving www.swagman.org... 77.86.213.15
Connecting to www.swagman.org|77.86.213.15|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 788,345 (770K) [application/octet-stream]

100%[================================================== =================>] 788,345 1.79M/s

08:33:55 (1.79 MB/s) - `libapplauncherd.so' saved [788345/788345]

~ #
~ #
~ # md5sum libapplauncherd.so
238b47681749eb2bf78a819ac6bb42f7 libapplauncherd.so
~ #
~ #
~ # cp /usr/lib/applauncherd/libapplauncherd.so /usr/lib/applauncherd/libapplauncherd.so.backup
~ # cp libapplauncherd.so /usr/lib/applauncherd/libapplauncherd.so
~ #

Fixed, thanks!

BIG hint from my side:
do not rename the file as original.so.something, but change the part before the '.so' ending.
Not sure if Harmattan acts the same way, but I had big troubles under Fremantle having two versions of a lib with name 'original.so' and 'original.so.bkp' or 'original.so_bkp'. After naming it to 'original_so.bkp' everything was okay.
Again: maybe above is okay, but I will not forget this anymore (happened twice to me ).

Wow, nice work, now OpenMode is ideal.

@Ancelad no. last problem is devicelock

True. What I'd say is ideal if it was possible to sign our kernels correctly or if there was a relatively easy way to bypass the signature verification in NOLO.

Now there's a worthy project to start hacking on

It isn't problem for me I didn't use it even with stock-kernel.

well, Jonni suggesting remake devicelock to use other memory region, not CAL

Be my guest :P
http://harmattan-dev.nokia.com/docs/...celock_8h.html

Now that's a paper moon :P

I was thinking more on the lines of inserting self-verifying routines into the Ubiboot kernel and userland - after building, portions of the binary are hashed and the hashes stored statically in the kernel (/proc/config.gz or early_param style?)

The entire mmcblk0 could be encrypted with dm-crypt, storing a signed ramdisk (the new /sbin/preinit) that asks for password with sillykbd - a 4-8 digit code can be salted and used as a key

The OMAP AES hardware should help with the speed impact this would entail. It also wouldn't provide device lock security, but a userland daemon with kernel helper could ask for a password every, 24h (user-configurable) or so, and shut down the device if the proper key isn't entered.

This would have the benefit of remaining mostly-transparent to Harmattan, actually even Nemo and other OSes.