PirateBox for Android - Modding

Here are the workshop slides I prepared for the PirateBox Camp #2 in Lille. Because they were not used at the camp I'll post them here, so they are not lost.
The slides show the range of possible modifications to the PirateBox for Android, ranging form simple preference changes to the more advanced use of the Android API.

Here are the slides, more details and download links are available below the presentation.
 
The first slide shows the Basic Settings that can be changed inside the preferences of the PirateBox app.
These basic settings allow to change things like the SSID name, storage directory etc. without deeper knowledge of the PirateBox.

The next slide Content Modifications shows the settings needed to make basic changes to the HTML, CSS and JavaScript files. After ticking the Content to SD option, the app has to be restarted for the change to take effect. After the restart you should find a folder named piratebox on your SD card (or wherever your external storage file system is located).

Inside the piratebox folder you'll find a directory named html which contains all the HTML, CSS and JavaScript files. If you are making changes to files located inside the html directory, make sure that the option Enable Updates is not ticked to prevent the next update of the app to overwrite your changes.
You will also notice that the html directory contains files with the extension xhtml. These files are html files that, in addition to standard HTML, include dynamic content. Dynamic content is covered in the slides that follow.

The next five slide (Dynamic Pages, Using BeanShell, XHTML Example, XHTML Errors and BeanShell DIY) cover the use of dynamic pages by using BeanShell. The slide named BeanShell DIY contains a download link (available below) that offers you the possibility to execute BeanShell code directly on your device.

The last two slides (Using the Android API and Android API DIY) are targeted at developers that already know the Android API. The Adroid API DIY links to a ZIP file (download below) that contains an example that shows the use of the Android API to access the music stored on the Android device. After unzipping the files to the html directory you should have an additional menu entry named Media inside the menu of your PirateBox start page.

If you are interested in how that works you can inspect the xhtml files included inside the ZIP file. But event if you are not into development the sample might be a nice addition to your PirateBox.

Downloads

The files referred to inside the presentation are available on Google Drive:
camp#2/beanshell.zip
camp#2/android_media.zip

PirateShare

PirateShare is an app that tries to simplify file upload to a PirateBox by using Android's share functionality.
On the PirateBox Camp #2 we tried the app and it seems to work quite well.

Android Share Dialog (image by #BiblioBox)

PirateShare was inspired by the PirateFox a PirateBox file sharing app for FireFox OS:

http://ruk.ca/content/piratebox-firefox-os-piratefox
https://github.com/reinvented/piratefox

The  PirateShare app is available for download on Google Drive:
http://t.co/j7oiLJdZuT


The app works like this:

1. Select one or multiple photos from the Gallery or select file(s) inside a file management app
2. Select PirateShare from share menu
3. PirateShare checks if connected to a PirateBox by requesting the ncsi.txt file
4. If connected PirateShare will upload the file(s)

Upload Dialog

PirateBox at Google Play

After quite some testing PirateBox for Android is now available at Google Play.
Thanks a lot to all of you for testing. Special thanks goes to Skyworth S8 for testing and sending in lots of screen shots (see gallery below).

The APKs will also be published to Google Drive, so installation will be possible for devices without Goggle Apps.

In case of errors or if you would like to provide feedback, please send a mail to piratebox[at]fun2code.de or leave a comment below.

Links

PirateBox at Google Play
APKs on Google Drive

PirateBox Reloaded - Episode III

Version 0.4.4 of PirateBox for Android is now available. This post is about the new and noteworthy features of that version.

If tests go well and I have enough feedback I will make PirateBox for Android available at Google Play. So please fill out the questionnaire ... feedback has been very sparse lately.

Droopy Support

The original PirateBox uses Droopy for file upload. PirateBox for Android uses his own mechanism for file uploads. To be compatible Droopy emulation has been introduced. If the Emulate Droopy option is enabled (which it is by default) files can be uploaded by using port 8080.

PirateBox and PirateFox

This makes it possible to use existing file upload tools. For testing the FireFox OS app PirateFox has been used (see image).

In addition to the file upload feature, a number is added to the uploaded file name if the file already exists. In earlier versions files with the same name were silently overwritten.

Info Widget

Info Widget

To make it easier to see if files were uploaded or new messages are available the new version contains a new widget which displays this information.

The counters should update automatically. If that does not work, you can force an update by tapping the widget.

Tasker/Locale Plugin

To make automation easier the latest version contains a Tasker/Locale plugin.
With this plugin it is possible to define tasks to switch the PirateBox on/off automatically.

Tasker

It has to be noted, that there are problems when using WiFi on/off as trigger. This is likely to not work as expected. I hope I'll be able to fix that in upcoming versions.

Status Broadcasts

This might only be interesting for developers but it is now possible to request the status of the PirateBox externally via broadcast. The new Info Widget uses this functionality and might serve as example.

The broadcast action used for the status request is de.fun2code.android.piratebox.broadcast.intent.STATUS_REQUEST and the PirateBox app will respond with a de.fun2code.android.piratebox.broadcast.intent.STATUS_RESULT broadcast which contains the following extras:

SERVER_STATE
  boolean value: true if the server is running, otherwise false

UPLOAD_NUMBER
  int value: number of uploaded files

SHOUT_NUMBER
  int value: number of shout/chat messages

UPLOAD_DIR
  String value: upload directory location

SHOUT_DIR
  String value: shout/chat directory location


That's it for the new version ... looking forward to receiving more feedback :)

PirateBox Reloaded - Episode II

First of all thanks to all of you who gave feedback regarding the PirateBox for Android. The feedback was very useful and showed that there are problems when running the app on Android 4.x.
Meanwhile I've rooted my Galaxy Nexus (still on stock ROM) running 4.3, so I had the change for in depth testing. The result is version 0.4.0 of the app which includes a different handling of the dnsmasq process. I'll go a little into detail to describe the changes that have been made.

Those of  you not interested can jump directly to the end of this post where the download link is located. I've also added the questionnaire again. It would be really nice if you could provide feedback, it's  really useful.

Wrapping Dnsmasq

In previous version of the app the dnsmasq process was killed and restarted with the --address=/#/. This worked fine on Android 2.x devices but lead to a continuous restart of the AP (Access Point) on Android 4.x devices.
The new approach is different in the way that it does not kill the dnsmasq process but installs a wrapper script that is created before the AP stars and removed afterwards.
For this to work the app saves a copy of the file /system/bin/dnsmasq to /system/bin/dansmasq.pb.real. On start of the PirateBox service the wrapper script is created which overwrites the /system/bin/dnsmasq command. After the AP is started the original dnsmasq binary is restored.
The wrapper script looks like this:

#!/system/bin/sh
exec /system/bin/dnsmasq.pb.real --address=/#/192.168.43.1 $*

The wrapper calls the original dnsmasq binary which is now located at /system/bin/dnsmasq.pb.real with the --address and all other other parameters ($*) the system used to start dnsmasq.

If you look at the process list after starting the AP you should see that the backed up dnsmasq.pb.real is running instead of the real one (dnsmasq).
Here is the result of the ps | grep dnsmasq command:

shell@maguro:/ $ ps | grep dnsmasq
nobody    5088  121   928    496   ffffffff 00000000 S /system/bin/dnsmasq.pb.backup

New Preferences

The preference screen has two new additions. One is the IP address of the AP and the other is the option to restore the original dnsmasq binary.

New Preference Options

In previous versions the IP of the AP could determined after the AP was started and used to restart dnsmasq. This is no longer possible, because the wrapper script has to be created before the AP starts.

On Android most of the devices have the IP address 192.168.43.1 hard coded and I don't believe that there are a lot ROMs with different addresses. Should your AP start with a different IP address, you can still change this by using the new preference setting AP IP Number.

The second new preferences option is called Restore "dnsmasq" Binary. This will, as the name implies, try to restore the original dnsmasq binary. This should not be necessary to used, because the wrapper is removed and replaced by the original binary after the AP has been started. But in case thing do not work as desired when the device is used for standard tethering, this is the option to restore the binary.

Simple Widget

The new version also comes with a simple widget. It is not pretty ... but hey, I'm a developer not an artist ;)
Meanwhile I've updated the widget images in version 0.4.1, hope the widget is looking a bit better.

Below are the links to the app, the questionnaire and to the source code located at GitHub.

So I hope the new version is working better as the previous version and I'm looking forward for your feedback.

---

Source Code

The source code is now available on GitHub.

Download Links

Google Drive: PirateBox APKs

Questionnaire

The results can be viewed here, so you know on which configurations PirateBox is running.

A Look at Android Wear

Google released Android Wear a version of the Android OS specifically designed for wearable device like smart watches and the like.
Actual devices should follow shortly by the middle of this year starting with smart watches from Motorola and LG.

Along with the announcement of Android Wear Google released a preview version of the Android Wear SDK for developers to test and try the new OS.
Looking at the SDKs emulator and docs thing might look a little bit disappointing at first glance, if the expectation is that reals apps can be installed on an Android Wear device.
The Wear API is designed that the wearable device is showing notifications from an Android phone by using the since Android 4.3 Jelly Bean available Notification Access service. This service allows apps to receive information about notifications displayed on device notification bar. In earlier versions of Android this was only available by using the Accessibility feature of Android.

To connect a device to an Android Wear emulator, Google has provided an Android Wear Preview app for registered developers. Because using the above mentioned “Notification Access” service, this app only runs on devices with Android 4.3 or higher.
When the app is enabled all (non ongoing) notifications will be displayed on the Android Wear device with the ability to use rich notifications which allow to use action buttons for sending Intents back to the smart phone.
This design has the advantage that without any change current apps will work with Android Wear out of box.

The possibilities currently available with that notification approach are quite limited and can be viewed on the Android Wear developer page.

In summary developers can use the following notification types:

• Rich notifications including images and action buttons
• Grouped notifications
• Notifications with multiple pages
• Receive voice input from a notification

That seems to be it as far as the official API concerned. But the question arises (at least from a hacker’s perspective) … Can the Android Wear OS run regular apps?

If we have a look at the above linked developer page, it states:

“Caution: Do not install apps on the Android Wear emulator. The system does not support traditional Android apps and the result of running such apps is unpredictable.”

It is indeed possible to run apps with some exceptions. Network access is not possible and in the case of most apps will lead to a crash of the app. Web Views are also not supported. Apart from that, apps seem to work fine, but the small display size might be a problem.
Because this is a block for developers and hackers, let’s have a look how to run apps on the Android Device emulator.

First of all an APK of an app is needed that does not require network access. An example of such an app is the StopWatch & Timer app from Google Play.
The APK can be extracted from another Android device with a backup app. Using APK Backup of the PAW web interface is also an option.
The APK can be simply installed onto an emulator running Android Wear with the following command:

adb install

When the APK has been installed, the app StopWatch & Timer app can be started like this:

adb shell am start -n com.sportstracklive.stopwatch/com.sportstracklive.stopwatch.BigStopWatchActivity

After startup the app will show up on the emulator’s screen. Apart from the  small screen estate, the app seems to be working fine. Event the preference screen is working.

All in all Android Wear seems to be a nice addition to the Android family and summer seems to be getting interesting with new devices popping up.

Writing/Deleting Data with KitKat

Unfortunately Android 4.4 KitKat does restrict file access to the secondary SD card when it comes to writing and deleting files.

This restriction was actually introduced in Android 3.2 HoneyComb but was not enforced by device manufacturers.

With KitKat this seems to have changed (e.g. for Samsung devices) and so File-Managers including DavDrive can not write or delete files on the secondary SD card on some devices.

There is nothing that can be done from a software perspective, the only chance to change this is to root the device.

A detailed description can be found here:

External Blues: Google Has Brought Big Changes To SD Cards In KitKat, And Even Samsung Is Implementing Them

Thanks to Stefan for letting me know about this issue!