WebOS Internals - User contributions [en]

How To Recover

2010-05-21T23:48:28Z

Odontastic: /* Pre not booting? webOS Doctor How-To */

= Pre not booting? webOS Doctor How-To =
{{tux|Tux_with_Broken_Pre.png|float:right;}}
Fortunately, Palm has created a tool called webOS Doctor intended for users to easily restore their devices in the event that they cannot boot for one reason or another.

Note: Before Trying the following steps below. Try removing the battery first and reinsert the battery and turn on the device this will determine whether or not you need to perform the following steps.

Note 2: As of WebOS 1.3.1 your USB data (Pictures, Videos, etc.) is no longer deleted during the process. Older versions of WebOS Doctor WILL DELETE ALL YOUR PERSONAL DATA ON THE DEVICE.

'''Palm webOS Doctor:''' [http://www.palm.com/us/support/downloads/pre/recoverytool/deviceselector_en.html http://www.palm.com/us/support/downloads/pre/recoverytool/deviceselector_en.html]

'''All Palm WebOS Doctor Versions:''' [http://www.webos-internals.org/wiki/Webos_Doctor_Versions http://www.webos-internals.org/wiki/Webos_Doctor_Versions]

After the download is complete, launch webOS Doctor:

# Select you language
# Accept the license agreement
# Connect your Pre to you PC via USB and select "Next" when it becomes available
{{tux|Tux_with_Pre_and_Screwdriver.png|float:right;}}
After completion the device will reboot and present you with the activation set-up.

If your PC does not recognize your Pre and you cannot go past step 3 above, try the following steps:

# With the USB cable connected, completely power off the Pre (hold down the power button until the option to power off appears)
# Hold down the Up button on the volume rocker
# While holding the Up button, power on the Pre
# "Next" should now be enabled - proceed with the recovery
{{tux|Tux_with_Pre.png|float:right;}}
The above steps will put the Pre into bootloader recovery mode and should allow the PC to recognize your device and proceed with the restore. In this mode the screen will display a giant USB logo instead of the usual Palm startup logo.

The process usually proceeds as follows:

(If you're on a Mac, you can follow the progress in /var/log/system.log)

# WebOS Doctor begins
# At 3%, a ramdisk is transferred to the phone, and the phone is rebooted
# At 4%, the screen changes to the palm logo
# At 9%, the screen changes to a big arrow pointing down to an integrated circuit
# Novaterm access is available from 12% onwards
# The progress bar advances by 2% increments every 20 seconds or so
# If it gets stuck at 52% for more than 30 seconds, it's not going to progress further and you will need to try again.
# Around 54% the filesystems are being partitioned
# Around 64% the modem firmware is being reflashed
# Around 72% the carrier apps are being installed
# Around 82% the ROM is being verified

If the process fails at 84% or later, the flash and modem have actually been written, so if you reboot you will get what you were flashing.

== Modifications to the recovery process ==

Between about 18% and 54% complete, you can novaterm into the device while it is being flashed, and modify the filesystem that will be run after the phone reboots (e.g. to touch /var/luna/preferences/ran-first-use).

If you stay in a mounted directory, you can even cause the flashing to abort after the carrier apps are installed and just before the ROM is verified. This is another point where manual modifications can be made.

After you have made your modifications, unmount any filesystems you have mounted and "tellbootie reboot".

== Can't boot into recovery mode? ==

In the very unlikely event that your Pre will not boot into recovery mode (indicating that your boot loader on the flash disk may be damaged or corrupted) you can try booting bootie into recovery mode over USB instead: [[Last_Resort_Emergency_BootLoader_Recovery]] '''Note that there has not been a single reported incidence of this being required, we do not recommend that you attempt this unless you have tried all the steps above exactly as described at least 10 times.'''

Short of hardware damage, it should not be possible to "brick" a Pre.

How To Recover

2010-05-21T23:46:45Z

Odontastic: /* Pre not booting? webOS Doctor How-To */

= Pre not booting? webOS Doctor How-To =
{{tux|Tux_with_Broken_Pre.png|float:right;}}
Fortunately, Palm has created a tool called webOS Doctor intended for users to easily restore their devices in the event that they cannot boot for one reason or another.

Note: Before Trying the following steps below. Try removing the battery first and reinsert the battery and turn on the device this will determine whether or not you need to perform the following steps.

Note 2: As of WebOS 1.3.1 your USB data (Pictures, Videos, etc.) is no longer deleted during the process. Older versions of WebOS Doctor WILL DELETE ALL YOUR PERSONAL DATA ON THE DEVICE.

'''Palm webOS Doctor:''' [http://www.palm.com/us/support/downloads/pre/recoverytool/deviceselector_en.html http://www.palm.com/us/support/downloads/pre/recoverytool/deviceselector_en.html]

'''All Palm WebOS Doctor Versions:''' [http://www.webos-internals.org/wiki/Webos_Doctor_Versions http://www.webos-internals.org/wiki/Webos_Doctor_Versions]

After the download is complete, launch webOS Doctor:

# Select you language
# Accept the license agreement
# Connect your Pre to you PC via USB and select "Next" when it becomes available
{{tux|Tux_with_Pre_and_Screwdriver.png|float:right;}}
After completion the device will reboot and present you with the activation set-up.

If your PC does not recognize your Pre and you cannot go past step 3 above, try the following steps:

# With the USB cable connected, completely power off the Pre (hold down the power button until the option to power off appears)
# Hold down the Up button on the volume rocker
# While holding the Up button, power on the Pre
# "Next" should now be enabled - proceed with the recovery
{{tux|Tux_with_Pre.png|float:right;}}
The above steps will put the Pre into bootloader recovery mode and should allow the PC to recognize your device and proceed with the restore. In this mode the screen will display a giant USB logo instead of the usual Palm startup logo.

The process usually proceeds as follows:

(If you're on a Mac, you can follow the progress in /var/log/system.log)

# WebOS Doctor begins
# At 3%, a ramdisk is transferred to the phone, and the phone is rebooted
# At 4%, the screen changes to the palm logo
# At 9%, the screen changes to a big arrow pointing down to an integrated circuit
# Novaterm access is available from 12% onwards
# The progress bar advances by 2% increments every 20 seconds or so
# If it gets stuck at 52% for more than 30 seconds, it's not going to progress further and you will need to try again.
# Around 54% the filesystems are being partitioned
# Around 64% the modem firmware is being reflashed
# Around 72% the carrier apps are being installed
# Around 84% the ROM is being verified

If the process fails at 84% or later, the flash and modem have actually been written, so if you reboot you will get what you were flashing.

== Modifications to the recovery process ==

Between about 18% and 54% complete, you can novaterm into the device while it is being flashed, and modify the filesystem that will be run after the phone reboots (e.g. to touch /var/luna/preferences/ran-first-use).

If you stay in a mounted directory, you can even cause the flashing to abort after the carrier apps are installed and just before the ROM is verified. This is another point where manual modifications can be made.

After you have made your modifications, unmount any filesystems you have mounted and "tellbootie reboot".

== Can't boot into recovery mode? ==

In the very unlikely event that your Pre will not boot into recovery mode (indicating that your boot loader on the flash disk may be damaged or corrupted) you can try booting bootie into recovery mode over USB instead: [[Last_Resort_Emergency_BootLoader_Recovery]] '''Note that there has not been a single reported incidence of this being required, we do not recommend that you attempt this unless you have tried all the steps above exactly as described at least 10 times.'''

Short of hardware damage, it should not be possible to "brick" a Pre.

How To Recover

2010-05-21T23:43:42Z

Odontastic: /* Pre not booting? webOS Doctor How-To */

= Pre not booting? webOS Doctor How-To =
{{tux|Tux_with_Broken_Pre.png|float:right;}}
Fortunately, Palm has created a tool called webOS Doctor intended for users to easily restore their devices in the event that they cannot boot for one reason or another.

Note: Before Trying the following steps below. Try removing the battery first and reinsert the battery and turn on the device this will determine whether or not you need to perform the following steps.

Note 2: As of WebOS 1.3.1 your USB data (Pictures, Videos, etc.) is no longer deleted during the process. Older versions of WebOS Doctor WILL DELETE ALL YOUR PERSONAL DATA ON THE DEVICE.

'''Palm webOS Doctor:''' [http://www.palm.com/us/support/downloads/pre/recoverytool/deviceselector_en.html http://www.palm.com/us/support/downloads/pre/recoverytool/deviceselector_en.html]

'''All Palm WebOS Doctor Versions:''' [http://www.webos-internals.org/wiki/Webos_Doctor_Versions http://www.webos-internals.org/wiki/Webos_Doctor_Versions]

After the download is complete, launch webOS Doctor:

# Select you language
# Accept the license agreement
# Connect your Pre to you PC via USB and select "Next" when it becomes available
{{tux|Tux_with_Pre_and_Screwdriver.png|float:right;}}
After completion the device will reboot and present you with the activation set-up.

If your PC does not recognize your Pre and you cannot go past step 3 above, try the following steps:

# With the USB cable connected, completely power off the Pre (hold down the power button until the option to power off appears)
# Hold down the Up button on the volume rocker
# While holding the Up button, power on the Pre
# "Next" should now be enabled - proceed with the recovery
{{tux|Tux_with_Pre.png|float:right;}}
The above steps will put the Pre into bootloader recovery mode and should allow the PC to recognize your device and proceed with the restore. In this mode the screen will display a giant USB logo instead of the usual Palm startup logo.

The process usually proceeds as follows:

(If you're on a Mac, you can follow the progress in /var/log/system.log)

# WebOS Doctor begins
# At 3%, a ramdisk is transferred to the phone, and the phone is rebooted
# At 4%, the screen changes to the palm logo
# At 9%, the screen changes to a big arrow pointing down to an integrated circuit
# Novaterm access is available from 12% onwards
# The progress bar advances by 2% increments every 20 seconds or so
# If it gets stuck at 52% for more than 30 seconds, it's not going to progress further and you will need to try again.
# Around 54% the filesystems are being partitioned
# Around 64% the modem firmware is being reflashed
# Around 74% the carrier apps are being installed
# Around 84% the ROM is being verified

If the process fails at 84% or later, the flash and modem have actually been written, so if you reboot you will get what you were flashing.

== Modifications to the recovery process ==

Between about 18% and 54% complete, you can novaterm into the device while it is being flashed, and modify the filesystem that will be run after the phone reboots (e.g. to touch /var/luna/preferences/ran-first-use).

If you stay in a mounted directory, you can even cause the flashing to abort after the carrier apps are installed and just before the ROM is verified. This is another point where manual modifications can be made.

After you have made your modifications, unmount any filesystems you have mounted and "tellbootie reboot".

== Can't boot into recovery mode? ==

In the very unlikely event that your Pre will not boot into recovery mode (indicating that your boot loader on the flash disk may be damaged or corrupted) you can try booting bootie into recovery mode over USB instead: [[Last_Resort_Emergency_BootLoader_Recovery]] '''Note that there has not been a single reported incidence of this being required, we do not recommend that you attempt this unless you have tried all the steps above exactly as described at least 10 times.'''

Short of hardware damage, it should not be possible to "brick" a Pre.

How To Recover

2010-05-21T23:38:11Z

Odontastic: /* Pre not booting? webOS Doctor How-To */

= Pre not booting? webOS Doctor How-To =
{{tux|Tux_with_Broken_Pre.png|float:right;}}
Fortunately, Palm has created a tool called webOS Doctor intended for users to easily restore their devices in the event that they cannot boot for one reason or another.

Note: Before Trying the following steps below. Try removing the battery first and reinsert the battery and turn on the device this will determine whether or not you need to perform the following steps.

Note 2: As of WebOS 1.3.1 your USB data (Pictures, Videos, etc.) is no longer deleted during the process. Older versions of WebOS Doctor WILL DELETE ALL YOUR PERSONAL DATA ON THE DEVICE.

'''Palm webOS Doctor:''' [http://www.palm.com/us/support/downloads/pre/recoverytool/deviceselector_en.html http://www.palm.com/us/support/downloads/pre/recoverytool/deviceselector_en.html]

'''All Palm WebOS Doctor Versions:''' [http://www.webos-internals.org/wiki/Webos_Doctor_Versions http://www.webos-internals.org/wiki/Webos_Doctor_Versions]

After the download is complete, launch webOS Doctor:

# Select you language
# Accept the license agreement
# Connect your Pre to you PC via USB and select "Next" when it becomes available
{{tux|Tux_with_Pre_and_Screwdriver.png|float:right;}}
After completion the device will reboot and present you with the activation set-up.

If your PC does not recognize your Pre and you cannot go past step 3 above, try the following steps:

# With the USB cable connected, completely power off the Pre (hold down the power button until the option to power off appears)
# Hold down the Up button on the volume rocker
# While holding the Up button, power on the Pre
# "Next" should now be enabled - proceed with the recovery
{{tux|Tux_with_Pre.png|float:right;}}
The above steps will put the Pre into bootloader recovery mode and should allow the PC to recognize your device and proceed with the restore. In this mode the screen will display a giant USB logo instead of the usual Palm startup logo.

The process usually proceeds as follows:

(If you're on a Mac, you can follow the progress in /var/log/system.log)

# WebOS Doctor begins
# At 3%, a ramdisk is transferred to the phone, and the phone is rebooted
# At 4%, the screen changes to the palm logo
# At 9%, the screen changes to a big arrow pointing down to an integrated circuit
# Novaterm access is available from 12% onwards
# The progress bar advances by 2% increments every 20 seconds or so
# If it gets stuck at 52% for more than 30 seconds, it's not going to progress further and you will need to try again.
# Around 54% the filesystems are being partitioned
# Around 66% the modem firmware is being reflashed
# Around 74% the carrier apps are being installed
# Around 84% the ROM is being verified

If the process fails at 84% or later, the flash and modem have actually been written, so if you reboot you will get what you were flashing.

== Modifications to the recovery process ==

Between about 18% and 54% complete, you can novaterm into the device while it is being flashed, and modify the filesystem that will be run after the phone reboots (e.g. to touch /var/luna/preferences/ran-first-use).

If you stay in a mounted directory, you can even cause the flashing to abort after the carrier apps are installed and just before the ROM is verified. This is another point where manual modifications can be made.

After you have made your modifications, unmount any filesystems you have mounted and "tellbootie reboot".

== Can't boot into recovery mode? ==

In the very unlikely event that your Pre will not boot into recovery mode (indicating that your boot loader on the flash disk may be damaged or corrupted) you can try booting bootie into recovery mode over USB instead: [[Last_Resort_Emergency_BootLoader_Recovery]] '''Note that there has not been a single reported incidence of this being required, we do not recommend that you attempt this unless you have tried all the steps above exactly as described at least 10 times.'''

Short of hardware damage, it should not be possible to "brick" a Pre.

External Battery Pack

2010-04-09T23:30:32Z

Odontastic:

[[image:Charger-pack.png|thumb|left|150px|Finished device by Ryan]]

Pre owners have been cursed with the problem of insufficient battery life since the day the phone was released. With the rise of 3d gaming, battery life has again taken a hit as the GPU sucks your power down. Additionally, the Verizon battery features the "mifi like" wifi router tethering feature, and the european 1.3.5.2 features bluetooth tethering that both result in batteries draining in 3 to 4 hours.

So, an external battery pack becomes a useful addition to the webOS owner's toolkit.

WebOS devices can accept up to a 1 amp charge from an external USB supply.

The USB spec says that voltage supplied to a USB port must be in the range 4.75 to 5.25 volts. [http://www.hardwarebook.info/Universal_Serial_Bus_(USB)]

New NiMH (Nickle Metal Hydride) rechargable batteries have a nominal voltage of 1.2 volts, so four of them in series have a nominal voltage of 4.8 volts. A freshly charged NiMH battery in good condition has a starting voltage of 1.4 volts, so four of them have a potential voltage of 5.6 volts, but this is unlikely in real life. In any event, this voltage falls rapidly to about 1.25 volts at 10% Depth of Discharge (DOD) and then remains almost constant until the cell is over 80% discharged. The voltage then falls rapidly from about 1.2 volts down to 0.8-1.0 volts at which the cell is considered "flat" in most devices. Mid-discharge at a load of 1 amp, the output is about 1.2 volts; at 2 amps, about 1.15 volts; the total effective differential internal resistance is about 0.05 ohms. Nickel metal hydride batteries provide a relatively constant voltage for most of the discharge cycle, unlike a standard alkaline where the voltage falls steadily during discharge. [http://en.wikipedia.org/wiki/Nickel-metal_hydride_battery]

High capacity rechargable NiMH AA batteries have a capacity of 2900 mAH.

Consider the power comparison then. The battery in the Pre has a capacity of 1150 mAH at 3.2 volts, or a total energy capacity of 3.68 watt-hours. 4 NiMH AA batteries provide 2900 mAH of power at 4.8V or 13.92 watt-hours of energy. This amounts to 3.78 full charges of the Pre or Pixi internal battery.

Clearly, the project is worth doing.

Four NiMH batteries will (just) fit sideways in a standard Altoids mint tin with a USB female plug placed through the end. Radio shack sells a 4xAA battery holder which can be glued into the tin with a little trimming for $1.79 [http://www.radioshack.com/product/index.jsp?productId=2062244] Keystone electronics sells a USB female socket that can be run through the end of the tin for $1.41 [http://www.alliedelec.com/search/productdetail.aspx?SKU=8396501]

The resulting power pack merely needs the addition of a usb to micro usb cable as came with the pre.

Connect the positive end of the batteries to pin 1 of the USB socket, and the negative end to pin 4.

The Pre or Pixi will notice that a high current (1 amp) charge can be obtained from the device if you short the data pins (2 and 3) of the socket.

The resulting package is simple, effective, and "neato".

[[image:AltoidsTin battery pack.png|thumb|left|150px|Finished device]] [[image:radioshack_battpack.png|thumb|right|150px|Radio Shack enclosed pack]]

If you don't want to mess with an altoids tin, Radio shack makes an enclosed 4 AA battery pack with a switch which can be directly soldered to a sacrificed micro USB cable for $1.99. [http://www.radioshack.com/product/index.jsp?productId=2062253]

If you want to skip all this there is a [http://www.amazon.com/Tekkeon-TekCharge-Mobile-Battery-Charger/dp/B0014KLX9C/ref=pd_sim_e_2 Commercial version built by Tekkon available from Amazon which includes a battery charger for approximately $22.]
[[image:tekkon1.png|thumb|left|150px|Tekkon pack with cover on]] [[image:tekkon2.png|thumb|right|150px|Tekkon pack with cover off]]

Luna Send

2010-03-08T04:52:48Z

Odontastic:

NOTE: You have to run with root perms.

Using luna-send to refresh the Launcher panel.
<pre><nowiki>
luna-send -n 1 palm://com.palm.applicationManager/rescan {}
</nowiki></pre>

Get a list of all installed apps:
<pre><nowiki>
luna-send -n 1 "palm://com.palm.applicationManager/listLaunchPoints" "{}"
</nowiki></pre>

Using luna-send to launch an application:
<pre><nowiki>
luna-send -n 1 palm://com.palm.applicationManager/launch {\"id\":\"com.palm.app.browser\"}
luna-send -n 1 palm://com.palm.applicationManager/launch {\"id\":\"com.palm.app.browser\",\"params\":{\"scene\":\"page\",\"target\":\"http://www.google.com\"}}
</nowiki></pre>

The second command shows how to open www.google.com when the browser is launched.

Using luna-send to download a file to /media/internal/downloads/:
<pre><nowiki>
luna-send -n 1 palm://com.palm.downloadmanager/download {\"target\":\"http://www.google.com/index.html\"}
</nowiki></pre>

Replace www.google.com/index.html with whatever file you want downloaded.

Using luna-send to first import and then set the wallpaper image:

<pre><nowiki>
luna-send -n 1 palm://com.palm.systemservice/wallpaper/importWallpaper {"target": "/media/internal/wallpapers/your_file.jpg" }
luna-send -n 1 palm://com.palm.systemservice/setPreferences {"wallpaper": {"wallpaperName": "your_file.jpg", "wallpaperFile": "/media/internal/wallpapers/your_file.jpg"}}
</nowiki></pre>

Replace your_file.jpg with whatever file in the wallpapers folder you want for your next wallpaper.

Using luna-send to control the palm progress animation (The pulsing "palm" logo seen at boot):

<pre><nowiki>
luna-send -n 1 palm://com.palm.systemmanager/runProgressAnimation {\"state\":\"start\"}
luna-send -n 1 palm://com.palm.systemmanager/runProgressAnimation {\"state\":\"stop\"}
</nowiki></pre>

TODO: These should probably be plugged into the Tracker app.

<pre><nowiki>
luna-send -n 1 palm://com.palm.location/setUseGps {\"useGps\":\"true\"}
luna-send -n 1 palm://com.palm.location/setAutoLocate {\"autoLocate\":\"true\"}
luna-send -n 1 palm://com.palm.location/getCurrentPosition {}
</nowiki></pre>

List all of the processes which are running:
<pre><nowiki>
sudo luna-send -n 1 palm://com.palm.applicationManager/running {}
** Message: serviceResponse Handling: 2, { "running": [ { "id": "com.palm.launcher", "processid": "1006" }, { "id": "com.palm.systemui", "processid": "1007" }, { "id": "com.palm.app.email", "processid": "1000" }, { "id": "com.palm.app.phone", "processid": "1001" }, { "id": "com.palm.app.contacts", "processid": "1002" }, { "id": "com.palm.app.camera", "processid": "1003" }, { "id": "com.palm.app.messaging", "processid": "1004" }, { "id": "com.palm.app.calendar", "processid": "1005" }, { "id": "com.palm.app.phone", "processid": "1008" }, { "id": "com.palm.app.camera", "processid": "1014" } ] }
</nowiki></pre>
Interesting note:
Seems everything with a processid below 1008 are static. As seen above, open camera app has pid 1014 and startup app is pid 1003

Close a process:

<pre><nowiki>
luna-send -n 1 "palm://com.palm.applicationManager/close" "{\"processId\":\"1058\"}"
</nowiki></pre>

Activate the vibrator:

<pre><nowiki>
luna-send -n 1 palm://com.palm.vibrate/vibrate {\"period\":1,\"duration\":1000\}
</nowiki></pre>
The duration value is in milliseconds and can be adjusted as desired.

Photos Info - list album and image from mediadb.db3:

<pre><nowiki>
luna-send -n 1 luna://com.palm.mediadb/image/listalbums {}
</nowiki></pre>

<pre><nowiki>
luna-send -n 1 luna://com.palm.mediadb/image/listimages {}
</nowiki></pre>

Set system volume - "volume" range is 0-100

<pre><nowiki>
luna-send -n 1 palm://com.palm.audio/system/setVolume '{"volume":80}'
</nowiki></pre>

Set ringtone volume - "volume" range is 0-100

<pre><nowiki>
luna-send -n 1 palm://com.palm.audio/ringtone/setVolume '{"volume":100}'
</nowiki></pre>

Dial a number - this actually calls the number, not just setup

<pre><nowiki>
luna-send -n 1 palm://com.palm.telephony/dial '{"number":"8001234567"}'
</nowiki></pre>

Hang up a phone call :-) There are ways to end specific types of calls but I think this is good enough for now. Let me know if you want the other methods.

<pre><nowiki>
luna-send -n 1 palm://com.palm.telephony/hangupAll {}
</nowiki></pre>

Send a text message - only need to change phone "value" and "messageText"

<pre><nowiki>
luna-send -n 1 palm://com.palm.messaging/sendMessageFromCompose '{"recipientJSONArray": [{"lastName": "", "pictureLoc": "", "contactCount": 1, "displayText": "", "firstName": "", "pictureLocBig": "", "imAvailability": 6, "pictureLocSquare": "", "contactDisplay": "", "Person_id": "", "personId": "", "type": "phone", "value": "8165551234", "alreadyValidated": true, "prefix": "to$A", "identifier": ""}], "messageText": "Content of message here"}'
</nowiki></pre>

set phone to no roam (home network only)
<pre><nowiki>
luna-send -n 1 palm://com.palm.telephony//roamModeSet '{"mode":"homeonly"}'
</nowiki></pre>

set phone to auto roam
<pre><nowiki>
luna-send -n 1 palm://com.palm.telephony//roamModeSet '{"mode":"any"}'
</nowiki></pre>

set phone to roam only
<pre><nowiki>
luna-send -n 1 palm://com.palm.telephony//roamModeSet '{"mode":"roamonly"}'
</nowiki></pre>

==Applications==

Notes (view notes):
<pre><nowiki>
luna-send -n 1 palm://com.palm.notes/getNotes {}
</nowiki></pre>

==Storage==

Enter usb storage mode:
<pre><nowiki>
luna-send -n 1 palm://com.palm.storage/diskmode/enterMSM {\"user-confirmed\":true,\"enterIMasq\":false}
</nowiki></pre>

Exit usb storage mode (toggle):
<pre><nowiki>
luna-send -n 1 palm://com.palm.storage/diskmode/enterMSM {\"user-confirmed\":true,\"enterIMasq\":false}
</nowiki></pre>

--WOOT--

==Airplane Mode==

Enable Airplane Mode:
<pre><nowiki>
luna-send -n 1 palm://com.palm.systemservice/setPreferences '{"airplaneMode":true}'
</nowiki></pre>

Disable Airplane Mode:
<pre><nowiki>
luna-send -n 1 palm://com.palm.systemservice/setPreferences '{"airplaneMode":false}'
</nowiki></pre>

==Finding luna-send Command==

These commands come from inside given applications. The best way to find luna-send commands is to do a search for the term "method:" in the Applications code. Once you find method: you might see parameters: which is also used by luna-send here is an example.

searched for "method:" in the com.app.palm.AppYouAreTesting

found

"method: test"

luna-send command based on example:
<pre><nowiki>
luna-send -n 1 palm://com.palm.AppYouAreTesting/test {}
</nowiki></pre>

General luna-send command:
<pre><nowiki>
luna-send -n 1 palm://ApplicationName/MethodValue {ParameterValues}
</nowiki></pre>

==Searching for services with dbus==
<pre>
Run dbus-util capture and search for services/methods/parameters. - xorg

# dbus-util --capture 2>&1 |tee /tmp/dbus.dump

Perform functions on device that you want to trap, such as setting phone to automatic roaming.
Ctrl-c from dbus.

Searches to try...
# grep // /tmp/dbus.dump
# grep com.palm /tmp/dbus.dump
# grep palm:// tmp/dbus.dump
# grep roam /tmp/dbus.dump

This is found in the dump...
com.palm.luna2 com.palm.telephony //roamModeSet Â«string=â{"mode": "homeonly"}

com.palm.telophony is the service
//roamModeSet is the method
"mode":"homeonly" is the parameter

Translate to luna-send...

luna-send -n 1 palm://com.palm.telephony/roamModeSet '{"mode":"homeonly"}'
</pre>

Application:Luna Manager

2009-11-17T02:59:11Z

Odontastic:

{{application
|name=Luna Manager
|type=webOS
|version=Version: 0.0.3
|tag=Utilities
|screenshot=LunaManager.png
|description=

== Summary ==
{{icon|Icon_WebOSInternals_StopLight.png|float:right;}}
Luna Manager is one of the handiest apps for homebrewers allowing you to control multiple aspects of Luna with a simple GUI

=== Info ===
Luna Manager can be installed via [http://www.webos-internals.org/wiki/Preware Preware] or [http://forums.precentral.net/canuck-software/206905-webos-quick-install-v2-9-a.html WebOS Quick Install]

Luna Manager requires the package manager service (that preware uses) to be installed to work.

== Buttons ==
=== Rescan ===
Rescan Option allows you to rescan your launcher. So when you install a new app and icon doesn't show up this will generally fix that.

=== Restart Luna ===
Restarting Luna is a good solution when you install patches, themes and some advanced homebrew apps to apply the changes without the need of a full reboot of the phone. It is a lot faster then an entire reboot and comes in quite handy. Keep in mind that it will close all your currently open applications.

=== Restart Java ===
Restarting Java is used for advanced home brew applications and installations for new services to take effect. Much easier then an entire reboot of the phone. Keep in mind This will cause your phone to lose network connection and be pretty sluggish until it is done restarting.
}}

Avahi

2009-10-19T01:28:45Z

Odontastic: /* Avahi Installation */

=Avahi=
[http://avahi.org Avahi] is a Linux service for providing multicast-DNS/DNS-SD (also known as [http://en.wikipedia.org/wiki/Bonjour_%28software%29 Bonjour] or mDNS/DNS-SD). Avahi allows for simple service discovery and advertisement on a local network and provides name resolution for all hosts running a mDNS/DNS-SD service.

Using Avahi allows for easy SSH access over a local wireless network. Once installed and started, users can ssh to their device using their mDNS assigned hostname.

==Avahi Installation==

First, mount the root filesystem as writable and install the Avahi ipkg.

$> sudo mount -o remount,rw /
$> sudo /opt/bin/ipkg-opt install avahi

Avahi currently attempts to access a different dbus system socket than the one provided by the Pre's dbus, so we need to turn off dbus access for the time being. Edit <tt>/opt/etc/avahi/avahi-daemon.conf</tt> and make the following change:

Replace this line:
#enable-dbus=yes

With this line:
enable-dbus=no

Avahi seems to want to run as a user named "avahi". To create the user, run the following command:

$> adduser -h /opt/var/run/avahi avahi

At this point, the Avahi daemon can be started with the following command:

$> sudo /opt/sbin/avahi-daemon -D

If you would like Avahi to start up at boot, create the following two files:

'''/opt/etc/init.d/S60avahi'''
#!/bin/sh

[ -e /opt/etc/default/avahi ] && . /opt/etc/default/avahi

if [ "$AVAHI_ENABLE" = "no" ]; then
exit
fi

if [ -n "`pidof /opt/sbin/avahi-daemon`" ]; then
killall /opt/sbin/avahi 2>/dev/null
fi

/opt/sbin/avahi-daemon -D

'''/opt/etc/default/avahi'''
AVAHI_ENABLE=yes

Make sure you set the startup script to executable:

$> sudo chmod 755 /opt/etc/init.d/S60avahi

Alternatively, you can create an upstart script at '''/etc/event.d/avahi''':

start on started PmConnectionManager

console output

exec /opt/sbin/avahi-daemon -D
respawn

NOTE: This script is not being stored in the /opt directory. You may have to replace it after an update, and it may cause problems with your Pre.

==Connecting via SSH using mDNS==

mDNS uses the system's hostname and appends it to the <tt>local.</tt> domain. Using the Pre's default <tt>castle</tt> hostname, the following command would be used to SSH to your Pre on port 222:

$> ssh -P 222 castle.local.

'''Note: The system that you are connecting from MUST have a mDNS service also running, else the hostname will not resolve'''

==Current Issues==

* The ipkg binary of Avahi attempts to find the dbus socket at <tt>/opt/var/run/dbus/system_bus_socket</tt>, but the Pre's dbus socket is at <tt>/var/run/dbus/system_bus_socket</tt>. I haven't investigated tying these two together too much, but the expanded functionality of accessing mDNS via dbus is preferred.
* The avahi-daemon seems to have issues keeping the mDNS name resolution running for more than a few minutes. I don't know if this is a power management issue or something else at this point.

Patch webOS Random Wallpaper Switching

2009-10-18T02:04:03Z

Odontastic: /* The Wallpaper Switcher Script */

{{template:patch}}
===Homebrew App for Random Wallpaper Switching===

There is now a homebrew application (no rooting required) that allows this same function without performing the patch below. It can be found at http://forums.precentral.net/homebrew-apps/195990-switcharoo-random-wallpaper-switching-v0-9-0-7-30-a.html

=== Goal===

On my desktop I have installed desktop drapes and my wallpaper switches every few hours to a random image in a wallpapers folder. I wanted to have the same functionality on my pre.

=== Requirements===

* [[Portal:Accessing_Linux | Access to Linux]] on your Pre.
* [[Next_steps | Installed backdoor with sudo]]
* The PATH variable should be set up in your .profile in your backdoor account, for example mine is set as follows:
<pre><nowiki>export PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin/:/usr/local/bin:/opt/bin:/opt/sbin</nowiki></pre>

=== Procedure===

Note: I prefer doing everything with sudo and not logging in as root via the backdoor. I would recommend getting into the same habit.

==== Transfering Wallpapers====

* Connect your Pre to your computer as a USB drive.
* Create a folder named 'wallpapers' on the Pre (if its not already there).
* Put all your wallpapers there.
* Disconnect the Pre from your PC. You might want to make sure to disconnect it safely so everything writes to storage okay.

Make sure to remove any wallpapers which you don't want to show up, though, since the switcher will pick a random one.

==== Enable Write Access====

<pre><nowiki>sudo mount -o remount,rw /</nowiki></pre>

==== Enabling Cron====

Go [[Crond | here ]] to enable crond.

==== The Wallpaper Switcher Script====

First lets make a place for the script:

<pre><nowiki>sudo mkdir /opt/share/wallswitcher</nowiki></pre>

Edit wallswitcher.sh inside /opt/share/wallswitcher directory and place the following code there:

<pre><nowiki>
#!/bin/sh

main()
{
DIR='/media/internal/wallpapers/'
IFS="
"
NUM_FILES=0
for cur in `ls -1 $DIR`; do
if [ -f "$DIR$cur" ]
then
NUM_FILES=$((NUM_FILES+1))
eval "FILE_$NUM_FILES=$cur"
fi
done

RANDOM_NUMBER=`awk "BEGIN{srand();print int($NUM_FILES * rand()) + 1;}"`
eval "RANDOM_FILE=\$FILE_$((RANDOM_NUMBER))"
IMPORT_STRING="{ \"target\": \"$DIR$RANDOM_FILE\" }"
SET_STRING="{ \"wallpaper\": { \"wallpaperName\": \"$RANDOM_FILE\", \"wallpaperFile\": \"$DIR$RANDOM_FILE\" } }"

echo "Found $NUM_FILES in $DIR"
echo "Using random file: $RANDOM_FILE"
echo "JSON Import String: $IMPORT_STRING"
echo "JSON Set String: $SET_STRING"

eval "luna-send -n 1 palm://com.palm.systemservice/wallpaper/importWallpaper '$IMPORT_STRING'"

eval "luna-send -n 1 palm://com.palm.systemservice/setPreferences '$SET_STRING'"
}

main
</nowiki></pre>

Save the file and make sure it has execute permissions. The following command will insure that:

<pre><nowiki>sudo chmod 755 /opt/share/wallswitcher/wallswitcher.sh</nowiki></pre>

Some notes on the script:
* I am a Java/Groovy developer mostly and am not as good at shell scripting as I would like. Any improvements on the script itself are welcome
* The main piece of code that performs the switch are the two luna-send commands. T he first command is required if a wallpaper has never been used before and will generate some thumbnails and copy the main image into /media/internal/.wallpapers. The second luna-send command actually performs the switch.
* This method currently only supports wallpapers sized to exactly 320 x 480 px. The import luna-send call can take more parameters in its JSON string, such as scaling and x/y offsets from center. I have not used these yet since all my wallpapers are correctly sized.
* Again, being a not-so-good shell developer, the way I obtain random numbers and use them is a bit wrong. Awk is used to get a random number. Instead of arrays (as in bash), dynamic variable naming is used.
* The DIR variable controls where the script looks for wallpapers—you can change it to where your pictures are instead. Currently the scan is not recursive.

==== Testing the Script====

If you have more then one wallpaper in /media/internal/wallpapers, you can test the switcher with the following command:

<pre><nowiki>sudo /opt/share/wallswitcher/wallswitcher.sh</nowiki></pre>

The response should look something like this:

<pre><nowiki>
Found 24 in /media/internal/wallpapers/
Using random file: wall_409.jpg
JSON Import String: { "target": "/media/internal/wallpapers/wall_409.jpg" }
JSON Set String: { "wallpaper": { "wallpaperName": "wall_409.jpg", "wallpaperFile": "/media/internal/wallpapers/wall_409.jpg" } }
** Message: serviceResponse Handling: 2, { "returnValue": true, "wallpaper": { "wallpaperName": "wall_409.jpg", "wallpaperFile": "\/media\/internal\/.wallpapers\/wall_409.jpg", "wallpaperThumbFile": "\/media\/internal\/.wallpapers\/thumbs\/wall_409.jpg" } }
** Message: serviceResponse Handling: 2, { "returnValue": true }
</nowiki></pre>

If the two service calls are not returning correctly, something is wrong. Contact me (fxdemolisher[at]gmail[dawt]com) if you are stuck debugging it.

==== Schedule the Script====

This step is pretty easy. Since you have an empty root crontab set up all that needs to be done is a scheduling command. Edit /etc/cron/crontabs/root and place the following scheduling test line:
<pre><nowiki>*/1 * * * * /opt/share/wallswitcher/wallswitcher.sh > /opt/share/wallswitcher/wallswitcher.log 2>&1</nowiki></pre>

This will execute the switcher every minute and log to the /opt/share/wallswitcher/wallswitcher.log log. After you have it switching correctly every minute you can edit the cron definition to run as often as you like. Mine is set to run at the top of the hour using this line:

<pre><nowiki>0 * * * * /opt/share/wallswitcher/wallswitcher.sh > /opt/share/wallswitcher/wallswitcher.log 2>&1</nowiki></pre>

NOTE: Do not use crontab -e as this does not really write to /etc/cron/crontabs/root and will be overriden when the device restarts.

==== Restore Read-Only Filesystem====

<pre><nowiki>sudo mount -o remount,ro /</nowiki></pre>

Tested and verified as written by optik678.

=== Alternate Uses===
Modifications to original script for other uses
==== "Missing Pre" Wallpaper ====
This is a simple alternate use to create a wallpaper indicating the Pre is "missing" ("stolen" sounds rather harsh...)

'''1.''' Create a PNG file and put in a directory of your choosing ( <YOUR-DIRECTORY> ) naming it "missingpre.png"

'''2.''' Create a script file in a location of your choosing, naming it missingpre.sh (I use "/home/scripts") using the following script (be sure to change <YOUR-DIRECTORY> to the actual directory where you stored your missingpre.png file):
<pre><nowiki>
#!/bin/sh

main()
{
MYFILE='<YOUR-DIRECTORY>/missingpre.png'

IMPORT_STRING="{ \"target\": \"$MYFILE\" }"
SET_STRING="{ \"wallpaper\": { \"wallpaperName\": \"mypre.png\", \"wallpaperFile\": \"$MYFILE\" } }"

echo "JSON Import String: $IMPORT_STRING"
echo "JSON Set String: $SET_STRING"

eval "luna-send -n 1 palm://com.palm.systemservice/wallpaper/importWallpaper '$IMPORT_STRING'"
eval "luna-send -n 1 palm://com.palm.systemservice/setPreferences '$SET_STRING'"
}

main
</nowiki></pre>

'''3.''' Add the following to /etc/cron/crontabs/root file (using the directory you chose for your script):
<pre><nowiki>*/1 * * * * /home/scripts/missingpre.sh</nowiki></pre>

'''4.''' Restart crond
<pre><nowiki>/sbin/stop crond && /sbin/start crond</nowiki></pre>

'''Result.''' Every minute this will over-ride whatever wallpaper was set.
Obviously, this won't force anyone to return your device, nor will it work if someone knows what they're doing with the Pre, but if your wallpaper is obnoxious enough, you might get lucky and have them call you back.

[[image:Missingpre.png]]

=== Acknowledgements===

I would like to thank this site and the wonderful hackers on it. I would not be able to do this without various examples from other pages.

Solution to App Catalog Installation Limit

2009-10-09T22:26:04Z

Odontastic: /* Solution (symbolic link method) */

Based on rwhitby's findings that temporarily moving /var/usr/palm/applications will allow installing apps from the App Catalog, here's a permanent way to keep the apps on (much larger) /media/internal by using links. This will permanently save space on /var.

It's unfortunate that Palm has not resolved the issue in the 1.2 update. This is a tactical workaround that could potentially work long term, also saving space on /var, but this needs support by the homebrew community to add in the homebrew installer apps.

== Overview ==
This solution involves creating a (hidden) directory in the /media/internal area, moving selected applications to the newly created directory, and then creating a symbolic link in the /var/usr/palm/applications directory pointing to the new location. This frees up the disk space from the relatively limited /var volume to the larger /media/internal. The included script (which must be created) will move the files and create the appropriate link. It will also provide information on the size of the applications stored in the /var/usr/palm/applications directory.

== Solution (symbolic link method) ==

Create a script to move apps to new home and create link. You can use an editor or use the following cat command to paste the code, for those not familiar with editors.

Here's how to do it for those comfortable with accessing Linux...

- Enter Linux mode on Pre through a computer (linux commands are in bold)

- Set read/write to allow creating script 
<code>'''mount -o remount,rw / '''</code>

- create a script using cat command, paste the code below and then do 'ctrl c' on the keyboard to break out. 
<code>'''cat >/usr/bin/mvapp''' </code>

- paste the code below here, press ctrl-c on keyboard to exit after pasting the code.

- when you see a linux prompt, set command to be executable 
<code> '''chmod 755 /usr/bin/mvapp''' </code>

----
code:
<pre>
#!/bin/sh

# This code is open for re-use with no restrictions. xorg
# This is a working proof of concept script still in development.
# Intent is for someone to port to a webOS app.
# Use at your own risk.

#-------------------------------------------------------------------------#
# versions:
# 0.1.0 - original (xorg)
# 0.1.1 - added unlink and clean functions (daventx)
# 0.1.2 - added bulkmv function, allows moving many apps (xorg)
# 0.1.3 - added option for tar backups (xorg)
# 0.1.4 - added listmoved function to show apps already moved (xorg)
# 0.1.5 - added restoreall function, couple cleanup items (xorg)
# 0.1.6 - fixed to show usage if no appname supplied to link/unlink (xorg)
# 0.1.7 - added cleanexit (w/mount ro /)
# - added exit code documentation for javascripts calling this (xorg)
# 0.2.0 - will not move apps that would have permission issues (xorg)
# - will not move apps that have no json file
# - improved error handling, improved listing shows actual app names
#-------------------------------------------------------------------------#

#-------------------------------------------------------------------------#
# variables: these are globally available to all functions
#-------------------------------------------------------------------------#
COMMAND=$1
APP=$2
MEDIA=/media/internal/.apps
VAR=/var/usr/palm/applications

# Backup keeps file attributes but uses more /media space. Recommend doing backups.
BACKUP=1 # set to 1 for tar backups, 0 to disable
BACKUPDIR=/media/internal/.appbackups

# This should be turned on. Only turn off if javascript is calling this script.
PROMPTS=1

#-------------------------------------------------------------------------#
# exit codes for javascripts:
# function usage:
# 1 - normal usage error
#
# function cleanapp:
# 0 - normal exit
#
# function linkapp:
# 10 - app name not supplied
# 11 - link already exists
# 12 - app does not exit in VAR
# 13 - copy failed from VAR to MEDIA
# 14 - removing app from VAR failed
# 15 - APP needs permissions not supported on FAT, did not move to MEDIA
# 16 - APP has no json file, did not move to MEDIA
#
# function unlinkapp:
# 20 - app name not supplied
# 21 - app doesn't exit on MEDIA
# 22 - tar restore failed
# 23 - copy failed
# 24 - remove failed
#
#-------------------------------------------------------------------------#

#-------------------------------------------------------------------------#
# function: cleanexit - exit with cleanup items
#-------------------------------------------------------------------------#

cleanexit () {
code=$1

# put / back to read only
# mount -o remount,ro /

# Uncomment if you want verbose exit codes
# echo "exit code: $code"

exit $code
}
# end of cleanexit function

#-------------------------------------------------------------------------#
# function: usage - show command usage options
#-------------------------------------------------------------------------#
usage () {
exitcode=$1
if [ ! $exitcode ]
then
exitcode=1 # default exit code for usage, otherwise exit with incode
fi

echo "Usage: mvapp link domain.appname - move app to media and link"
echo "Usage: mvapp unlink domain.appname - restore app to var, remove link"
echo "Usage: mvapp clean domain.appname - remove app dir and links"
echo "Usage: mvapp list - list all apps sorted by size"
echo "Usage: mvapp bulkmv - move/link bulk apps"
echo "Usage: mvapp listmoved - list apps that have been moved"
echo "Usage: mvapp restoreall - restore all apps to original"

cleanexit $exitcode
}
# end of usage function

#-------------------------------------------------------------------------#
# function: cleanapp - removes symbolic links and folder in media and var
#-------------------------------------------------------------------------#

cleanapp () {

mount -o remount,rw /

# exit to usage if no app name supplied
if [ ! $APP ]
then
usage 1
fi

# Continue on if PROMPTS turned off (call from outside app)
if [ $PROMPTS ]
then
echo "This will remove $APP from both $VAR and $MEDIA."
echo "You should first attempt to remove the app using the official Pre methods."
echo "Are you sure you want to remove $APP? [y/N]: "
read answer
case $answer in
[Yy]*) continue;;
*) cleanexit 0;;
esac
fi

if [ -h $VAR/$APP ]
then
echo "Removing all traces of $APP."
else
echo "$APP does not exist..."
usage 10
fi

echo "Size of $VAR before cleanup... "
du -sh $VAR

if [ -d $MEDIA/$APP ]
then
rm -r $MEDIA/$APP
echo "Removed directory" $MEDIA/$APP
fi
if [ -d $VAR/$APP ]
then
rm -r $VAR/$APP
echo "Removed directory" $VAR/$APP
fi
if [ -L $VAR/$APP ]
then
rm -r $VAR/$APP
echo "Removed link" $VAR/$APP
fi
if [ -f $BACKUPDIR/$APP.tgz ]
then
rm -r $BACKUPDIR/$APP.tgz
echo "Removed tar backup" $BACKUPDIR/$APP.tgz
fi

# rescan luna in case it's needed
luna-send -n 1 palm://com.palm.applicationManager/rescan {} >/dev/null 2>&1
echo "$APP directories and links removed."
echo "Size of $VAR after cleanup... "
du -sh $VAR
cleanexit 0
}
# end of cleanup function

#-------------------------------------------------------------------------#
# function: listapps - list the size of each app, sort showing largest last
#-------------------------------------------------------------------------#
listapps () {
cd $VAR
for i in `du -s * | sort -n |cut -f 2`
do
APP=$i
SIZE=`du -s $VAR/$APP |cut -f1`
TITLE=""
if [ -f $VAR/$APP/appinfo.json ]
then
TITLE=`grep title $VAR/$APP/appinfo.json |cut -d: -f2 |cut -d\" -f2`
fi
echo "$SIZE - $APP - $TITLE"
done

cleanexit 0
}
# end of listapps function

#-------------------------------------------------------------------------#
# function: listmoved - list apps moved/linked, sort showing largest last
#-------------------------------------------------------------------------#
listmoved () {
#du -sk $MEDIA/* | sort -n #doesn't show proper size on FAT fs, removing
cd $MEDIA
for i in `du -s * | sort -n |cut -f 2`
do
APP=$i
# Not sure why du reports incorrectly on FAT fs
#SIZE=`du -s $MEDIA/$APP |cut -f1`
SIZE=""
TITLE=""
if [ -f $MEDIA/$APP/appinfo.json ]
then
TITLE=`grep title $MEDIA/$APP/appinfo.json |cut -d: -f2 |cut -d\" -f2`
fi
echo "$SIZE - $APP - $TITLE"
done
cleanexit 0
}
# end of listmoved function

#-------------------------------------------------------------------------#
# function: linkapp - move the app to media and create symbolic link
#-------------------------------------------------------------------------#
linkapp () {

if [ ! $APP ]
then
echo "No application supplied..."
usage 10
fi

if [ ! -f $VAR/$APP/appinfo.json ]
then
echo "$APP has no json file. Will not be moved."
code=16
return 16
fi

if [ ! -d $MEDIA ]
then
mkdir $MEDIA
fi

if [ -h $VAR/$APP ]
then
echo "Link already exists for... ${APP}"
cleanexit 11
fi

TITLE=`grep title $VAR/$APP/appinfo.json |cut -d: -f2 |cut -d\" -f2`

mount -o remount,rw /

if [ -d $VAR/$APP ]
then
echo "Moving $APP $TITLE to $MEDIA..."
else
echo "$APP does not exist..."
usage 12
fi

# Backup using tar if enabled
if [ $BACKUP ]
then
if [ ! -d $BACKUPDIR ]
then
mkdir $BACKUPDIR
fi
echo "Backing up $APP $TITLE to $BACKUPDIR..."
tar czf $BACKUPDIR/${APP}.tgz $VAR/$APP
fi

mount -o remount,rw /

echo "Size of $VAR before move... "
du -sh $VAR

# move over to USB drive
cp -rp $VAR/$APP $MEDIA >/tmp/cpresult.out 2>&1
if [ $? != 0 ]
then
grep "cannot preserve ownership" /tmp/cpresult.out >/dev/null 2>&1
if [ $? = 0 ]
then
echo
echo "$APP cannot be moved as it requires special permissions."
echo "Leaving app in $VAR."
code=15
return $code
else
echo "Copy failed. Leaving app in $VAR."
code=13
fi
rm -r $MEDIA/$APP
rm /tmp/cpresult.out
cleanexit $code
fi

rm -r $VAR/$APP
if [ $? != 0 ]
then
echo "Remove failed. Leaving app in $VAR."
rm -r $MEDIA/$APP
cleanexit 14
fi

# create the symbolic link
ln -s $MEDIA/$APP $VAR/$APP

# rescan luna in case it's needed
luna-send -n 1 palm://com.palm.applicationManager/rescan {} >/dev/null 2>&1

echo "$APP moved and linked."
echo "Size of $VAR after move... "
du -sh $VAR
}
# end of linkapp function

#-------------------------------------------------------------------------#
# function: unlinkapp - restore the app to var and remove symbolic link
#-------------------------------------------------------------------------#
unlinkapp () {

if [ ! $APP ]
then
echo "No application supplied..."
usage 20
fi

mount -o remount,rw /

if [ -d $MEDIA/$APP ]
then
echo "Restoring $APP..."
else
echo "$APP does not exist..."
usage 21
fi

echo "Size of $VAR before move... "
du -sh $VAR

# remove the old symbolic link
rm -r $VAR/$APP

# move to original location or restore from tar if it exists
if [ -f $BACKUPDIR/$APP.tgz ]
then
cd /
tar xzf $BACKUPDIR/$APP.tgz
if [ $? != 0 ]
then
echo "Tar restore failed. Remove and restore app using official webOS/Pre methods."
cleanexit 22
else
rm -r $BACKUPDIR/$APP.tgz
fi
else
cp -r $MEDIA/$APP $VAR
if [ $? != 0 ]
then
echo "Copy failed. Leaving app in $MEDIA."
cleanexit 23
fi
fi

rm -r $MEDIA/$APP
if [ $? != 0 ]
then
echo "Remove failed. Leaving app in $MEDIA."
rm -r $VAR/$APP
cleanexit 24
fi

# rescan luna in case it's needed
luna-send -n 1 palm://com.palm.applicationManager/rescan {} >/dev/null 2>&1

echo "$APP moved and unlinked."
echo "Size of $VAR after move... "
du -sh $VAR
}
# end of unlinkapp function

#-------------------------------------------------------------------------#
# function: bulkmv - move/link many apps
#-------------------------------------------------------------------------#
bulkmv() {
echo
echo
echo "This allows moving many apps, asking which you'd like to move."
echo "Starting with the largest apps."
echo

mount -o remount,rw /
cd $VAR

for i in `du -s * | sort -nr |cut -f 2`
do
export APP=$i
SIZE=`du -sh $APP |cut -f 1`
TITLE=`grep title $VAR/$APP/appinfo.json |cut -d: -f2 |cut -d\" -f2`
echo "Size of $APP - $TITLE is $SIZE."
echo "Would you like to move and link... $TITLE? [y/N/q]: "
read answer
case $answer in
[Yy]*) linkapp;;
[Qq]*) cleanexit 0;;
*) echo "$APP not moved."
continue;;
esac

echo
done
}
# end of bulkmv function

#-------------------------------------------------------------------------#
# function: restoreall - restore all apps, back to /var
#-------------------------------------------------------------------------#
restoreall() {

#Only confirm if PROMPT turned on. (allows outside app to call)
if [ $PROMPT ]
then
echo "This will restore all applications back to original location"
echo "and remove the links. Are you sure you want to continue? [y/N]:"
read answer
case $answer in
[Yy]*) continue;;
*) cleanexit 0;;
esac
fi

ls $MEDIA | while read APP
do
echo "Restoring $APP and unlinking..."
unlinkapp
done
}
# end of restoreall function

#-------------------------------------------------------------------------#
# main - begins here
#-------------------------------------------------------------------------#

case $COMMAND in
"clean")
cleanapp
;;
"list")
listapps
;;
"listmoved")
listmoved
;;
"link")
linkapp
;;
"unlink")
unlinkapp
;;
"bulkmv")
bulkmv
;;
"restoreall")
restoreall
;;
*)
usage 1
;;
esac

cleanexit $code

</pre>

----

- Be sure to set execute permissions if you missed the step above...
<code>chmod 755 /usr/bin/mvapp</code>

== Precautions ==

So far, no one has reported an app that has issues due to linking. These are best practices to avoid issues.

- Be selective about what you move. You may not want to move apps that store important information to you such as password lockers, memo apps, EverNote, Agenda, etc. Games, web content apps and information viewing apps should be safer to move as there is no data at risk.

- Close apps before moving them. Do not move an app while it is open and running. I actually tested this and figured some apps would break but none have yet. It is still not wise to move apps while they are open and running.

== Commands ==

'''To find the largest apps in /var/usr/palm/applications'''

<code>mvapp list</code>

It shows the largest apps last... IE.... 
<code>
8352 com.apnews.webos 
8512 com.fandango.app.fandango 
8672 com.palm.app.musicplayerremix 
10304 com.shortcovers.palm.pre 
10432 com.fusioncreativestudios.deadman 
10656 com.ulocate.app.where 
</code>

'''To move and link an app to /media'''

<code>mvapp link domain.appname</code>

Example: mvapp link com.ulocate.app.where

The app should now work in the new location thanks to the link. Test each app to make sure it works before doing another. Looping the script to do every app in the dir or to link the entire app dir is not recommended. File attributes are lost on the move, which some apps may need. You need to test each app after a move.

Continue moving apps until it reports that /var.../applications is about 25MB or less.

There is an option to turn on/off tar-based backups. See the BACKUP variable in the script. If set to 1, it will perform a tar backup. This takes up more space on /media but if you need to restore, it puts it back with full file attributes. Recommend keeping this on.

'''To move and link many apps'''

<code>mvapp bulkmv</code>

This will show largest app first, ask if you want to move/link and then moves on to the next largest app. If you answer no to an app, it will skip to the next. Answer 'q' to quit. Is easiest to use this method directly on a device using the Terminal app.

'''To revert the move and delete the link'''

<code>mvapp unlink domain.appname</code>

The application will be moved back to the original directory. File attributes are lost on the move if tar backup is turned off, which some apps may need. You need to test each app after a move. If tar backup is turned on (default - see BACKUP variable in script), file attributes will be restored.

'''To list apps that have been moved and linked...'''

<code>mvapp listmoved</code>

This shows a list of apps that have been moved and linked to /media.

'''To restore all moved apps back to original location'''

<code>mvapp restoreall</code>

If backup was turned on, this will restore ALL applications that have been moved/linked, back to the original location in /var with original attributes (using tar). If backup was not turned on, it will still attempt to move the applications back to /var using the files in /media, but without original file attributes. This may take several minutes to complete. It will show each application progress.

'''To cleanup and remove directories and symlinks'''

<code>mvapp clean domain.appname</code>

If you have any issues, first attempt to remove the app from the App Catalog or Homebrew app installer. Then issue the 'clean' command to remove the applications directories at both locations and also the symlink. You can then reinstall the app from the App Catalog or any Homebrew App installer.

== Contingency Plan==

If you have problems with an application, follow these steps... 
-- Close the application if open 
-- mvapp unlink domain.appname 
-- Try using the App 

If the application still does now work correctly... 
-- Remove the App using official methods 
-- mvapp clean domain.appname 
-- Reinstall through the App Catalog or Homebrew installer app 

== Proposal to Dev Community ==

This is a formal proposal to the Dev Community suggesting that PreWare, WebOS Quick Install and other Pre installer apps provide an option to move any app in /var to the /media fs and create a link similar to the code above.

The Homebrew Community somewhat created part of the storage problem so needs to come up with their own solution. The symbolic link proponents propose that Homebrew apps be moved with a link to /media/internal by default and physically use /var only if needed (per conditions stated below). The developer would put a flag in the package (or some other method during submission) to state their app is able to run linked to /media or if it specifically needs to physically be on /var. Will propose additions to Packing Standards to support /media links. The homebrew installer apps could then automatically do the move/link if the package is flagged for it.

Candidate apps for moving to /media 
- apps that do not depend on file attributes (such as executable bit) 
- apps that do not perform data operations to home app directory when device is USB mounted 

Exceptions for maintaining apps on /var 
- apps that depend on file attributes 
- apps that won't work well when device is USB mounted, such as performing data or DB operations in home app directory 

(Please update with other known candidates/exceptions)

== Benefits over other methods ==

''Resizing /var'' 
One challenge with resizing /var is that it will still have a fixed static limit - how do you decide how much to increase it? Many will still probably hit the limit or waste space if setting too high. There is also the warning from Palm that resizing var may interfere with future updates. The link method allows to dynamically use the /media partition, so there is no need to set a specific size dedicated to apps. If the USB drive is filled, users can decide if they use the space for media or apps on the fly.

''AppPath in /etc/luna.conf'' 
I proposed a while back adding an AppPath to luna.conf to include apps stored on /media. Some apps would not work because some apparently reference /var. IE, the vampire/mafia/quest series could not access graphics. The symbolic link fixed this because apps think they are in /var.

''Link/mount [[all]] of /var/usr/palm/applications/ to /media/internal'' 
If some apps rely on file attributes this won't work since file attributes are lost when moved to FAT fs. While this is rare, it probably isn't wise to force all /var apps to /media. Selectively moving apps one at a time is less risky. Update: Have found that "PDF View" app does not allow to be linked, so it appears that selectively moving apps is necessary.

''Creating a loopback filesystem to a virtual file located on /media/internal'' 
This has been worked on [http://www.webos-internals.org/wiki/Tutorials_Linux_opt_on_loopback here] and still has potential. Unfortunately it locks out USB mount and media sync altogether. If a workaround can be found with low risk, this may be the most ideal solution.

== Risks, Issues, Dependencies ==

- File attributes of linux fs are not copied over to fat fs. May not work with apps that rely on file attributes. In general, javascript apps will likely work fine located on /media. No one has reported an app (yet) that does not work.

- Some apps may not behave well if USB drive is mounted to computer, though I've tested several that behaved fine. Linux type background services probably would not work well so probably should not be moved. Apps that do IO to the home directory of the app while USB mounted may have issues when located on /media.

- Jason Robitaille has indicated that a future version of WebOS Quick Install will include a routine to resize the /var partition. He has also indicated that doing so will wipe the /media/internal area, so any applications stored there would need to be backed up first. It might be good to be able to reverse the process of this solution. This could be done either by adding to this <code>mvapp</code> script, or creating a new one.

== Future Versions ==

Plans for future versions...

- The script will soon be modified to be friendly for javascript calls... no prompting and no output, just result codes. Will still maintain user interaction capability as well.

== Confirmed Apps ==
=== Apps Confirmed ''Not'' to Work ===
com.palm.app.pdfviewer (script properly handles this, won't allow it to move)

== Discuss ==
Discuss in the Discussion tab or PreCentral...

http://forums.precentral.net/web-os-development/205649-resolution-app-catalog-install-limit-proposal.html

'''Your Experiences'''

Please post your experiences, good or bad. I'd like to get any kinks worked out before attempting to turn this into a webOS app.

- How many apps did you move? 
- Did you find an app that won't work linked? 
- Did you move any back? (please test) 
- How far down did you have to get /var.../applications down in MB before you could start adding apps from the App Catalog? 

== Credits ==
xorg - initially developed script and proposal. maintainer of this page. 
daventx - added unlink and clean functions.