RIM Should Make an Android Phone with Amazon

The clock is ticking for RIM, and although they still have money in the bank, the postponed release of Blackberry OS 10 into 2013 does not bode well for the platform. The Blackberry Playbook provides a development platform for applications that could run on Blackberry v10 phones, but with Microsoft contending in the phone and tablet market with Windows 8, it will be difficult for developers to justify work on another proprietary platform.

The Android App Player that runs on the Blackberry Playbook OS 2 is a good option for users looking to RIM for a secure enterprise platform but wanting access to a more diverse application catalog that Android provides. The jailed approach also ensures that the Dalvik engine, the foundation of Android, remains a truly isolated process from core functions of the Blackberry OS, which is beneficial from both security and reliability standpoints.

Being the only remaining player relying on a closed source RTOS at the core of RIM's phones, a significant effort is required to develop and support the Blackberry OS. Bringing in the QNX core and team is not sufficient to meet the demands of the phone market for rapid iteration of high-end hardware. The case can be made to continue developing QNX for Blackberry phones, but user-level applications do not need to be so closely tied to the Blackberry OS.

Given that the QNX team has demonstrated the ability for the Blackberry Playbook OS to run Android's Dalvik engine, what prevents RIM from running Android on their phones? With dual-core being the defacto minimum specs for a modern smartphone, RIM can run both the Blackberry and Android OS's with minimal to no impact to performance. This would allow RIM to focus on what they do best, which is providing a secure and reliable platform for users, while also providing access to the Android ecosystem.

In order to deliver the experience necessary to compete with core Android phones, RIM will also have to create a reverse skin for Android. There is no need for Android to run in a separate, single app container; instead, each app should be displayed as native as possible. This would accomplish one major feat that all other Android OEMs cannot: fork and present running Android apps as separate windows, providing a user-friendly approach to Android multitasking without taking away from the Android experience. The Dalvik engine can still suspend applications when the system is running low on RAM or an app hasn't been accessed in some time, but the user can have more control over how an app runs. Additionally, the core primarily running Android apps can be put to sleep when the device is not in use, and the Blackberry core can maintain system state and provide the secure and reliable phone and data services that users expect, without compromising battery life.

Where Amazon comes in has much to do with their ecosystem, comprising of vast content and an Android application store that can provide compatible apps to Blackberry devices. Jeff Bezos has famously remarked that "he loved his BlackBerry and the ease with which he could find e-mails and respond to people"; even the Kindle Fire is based on the BlackBerry Playbook hardware (likely due to cost and ease of design re-use).

The advantage that both RIM and Palm had with physical keyboards was their ability to develop a UI around the keyboard, not the other way around. Having features such as Just Type in WebOS provides the user the option to type a search query or email response without having to wait for the UI to respond. A Google or Apple search on touchscreen devices require time for a tap on a button or search bar and a soft keyboard to appear before the query can be entered, and a physical keyboard is far more efficient for this action.

By having RIM focus on developing the hardware and core software, Amazon can focus on delivering the content on Android phones through a major phone vendor, and this RIM + Amazon partnership can truly produce a real alternative to Apple, Google, and Microsoft. This could be the phone to replace BlackBerry as we know it today while continuing to provide many of the features many of us long for in a phone. What better way to keep pace with Android development than to fully integrate the engine in a RIM device.

Koss Striva Pro on WebOS Linux

Bluetooth is ubiquitous and works well with WebOS, so why would I want to stream using WiFi headphones? That is the question I might expect a common reader to have, and my response is simple: WiFi is everywhere. The Internet is the modern delivery mechanism for music; this has been established with iTunes, Amazon, Pandora, and Spotify at the forefront. If music is arriving from the Internet, why not connect directly to the source using your headphones?

Koss recently launched a WiFi music platform called Striva, the portal of which is found at myKoss.com. The website allows for the definition of music channels and the configuration of hardware. The Striva Pro, Koss's first WiFi headphone to hit the market, can connect to any predefined WiFi APs (such as a home network, a mobile hotspot, and a work network), and it will also connect to any truly open WiFi AP (like those sometimes found at your local coffee shop). When connected to a WiFi AP, the music playing on the headphones is displayed and can be controlled via myKoss. A custom channel and stream can also be added as long as it is an Icecast or Shoutcast stream (pls and IP:PORT both accepted). This is how I am able to listen to my music at home, since I am using mpd (Music Player Daemon) and icecast2 for streaming.

Since WebOS is based on Linux, only a few steps are required to properly configure your HP TouchPad or Palm Pre to stream music, audiobooks, and podcasts directly without using a Koss CAP (Content Access Point). I decided to use a chrooted Ubuntu filesystem for ease of setup and access to a UI for music control. I have a 2GB img file in /media/internal that I mount to /media/ext3fs, but for the basic set of instructions refer to this WebOS-Internals page.

Once you have XTerm and the UbuntuChroot installed and configured, you can use Xecutah to launch a terminal in both workspaces. Note: the following Linux configuration may also work on Android or jailbroken iOS with minor tweaks.

WebOS IP Configuration
Before we can setup mpd and icecast2 to play and stream music, respectively, it is advantageous to have a dynamic DNS, and port forwarding must be setup for the music to flow via WiFi. I am using a free account from Dynamic DNS and the utility ez-ipupdate, available via Preware/Optware.

In order to update the dynamic DNS with the WiFi IP, the interface parameter found in /opt/etc/ez-ipupdate.conf must be set to 'eth0'. The script '09update-ddns' should be placed in /etc/network/if-up.d/ to ensure that it is executed when a new WiFi connection is established. Note: I have seen this work on WebOS 3.x, but I have to manually execute the script to update on 2.x.

Finally, IP port forwarding must be enabled for the icecast2 (default: 8000) and mpd (default: 6600) ports. I created the following script in /etc/init.d/mpd_server.sh to configure iptables:

#!/bin/sh
/usr/sbin/iptables -I INPUT -p tcp --dport 8000 -j ACCEPT
/usr/sbin/iptables -I INPUT -p tcp --sport 6600 -j ACCEPT

MPD/Icecast Configuration
Within the Ubuntu chroot, as user 'root', execute the following commands:

'apt get mpd'
'apt get icecast2'
'apt get lame'

To configure mpd to output to icecast2 by default, open /etc/mpd.conf comment out the default 'audio_output' and uncomment the default "shout output". I set my 'mount' to '/mpd.mp3', commented out 'bitrate' and added a line for 'quality' set to '5.0'. The 'password', 'name', and 'description' can also be set to preference. Also, you will need to comment out 'bind_to_address' to allow control from an external network.

To configure icecast2, open /etc/icecast2/icecast.xml and modify the passwords to match that set in mpd.conf.

Add Music and Start Streaming
The default music location is /var/lib/mpd. In order to gain access to your mp3s, the chroot bind needs to be defined for /media/internal.

Start by creating the mount point in the ext3 partition.

'mkdir -p /media/ext3fs/ubuntu-natty-chroot/internal'

Modify /media/cryptofs/apps/usr/palm/applications/org.webosinternals.ubuntu-natty-chroot/bin/chroot-wrapper.sh and add the following:

'mount --bind /media/internal ${CHROOT}/internal'
'umount ${CHROOT}/internal'

This will automatically bind the /media/internal partition to /internal within the Ubuntu chroot. Add the music directories you would like to index as a soft link within /var/lib/mpd/music/:

'ln -s /internal/HPMusic /var/lib/mpd/music/HPMusic'

Within the Ubuntu chroot terminal, start the icecast2 process followed by the mpd process.

'/etc/init.d/icecast2 start'
'/etc/init.d/mpd start'

To update the Dynamic DNS IP and enable port forwarding, execute the following from within XTerm:

'/etc/init.d/mpd_server.sh'
'/etc/network/if-up.d/09update-ddns'

Finally, to setup and control music through mpd, install one or both of the following clients within the Ubuntu chroot:

'apt-get install mpc'
'apt-get install sonata'

Music Control
To update the music database, execute the following command within the Ubuntu chroot:

'mpc update'

To add your entire music collection to the current playlist:

'mpc listall | mpc add'

And finally, to start playing music:

'mpc play'

Custom Stream
Add a custom stream using the dynamic DNS and port number to your myKoss account.

e.g. 'http://icecast.dyndns.org:8000/mpd.mp3'

Select this stream, ensure that the chroot card is focused on WebOS, and power-up the Koss Striva Pro. If everything is configured properly, the headphones will start streaming from your TouchPad or Pre.

Pulse Audio
I was not able to make use of the icecast plugin for pulse audio on the TouchPad. If anyone is able to make any progress on this, please feel free to comment or message me and I will add the details in a future post.

Conclusion
The Koss Striva WiFi platform enables high quality audio streaming directly from your home server and mobile device. While Bluetooth is quick and easy to setup, it does not provide a high quality audio streaming experience (A2DP is equivalent to a 96kbps stream, while the Lame encoder is capable of CD quality at VBR or 320kbps settings). This demonstrates that it is possible for a Linux configuration to stream directly to the headphones. While apps on the PC and mobile devices will provide this capability to the common user with no command-line configuration, this demonstrates how powerful of a platform Striva is. The revolution is truly in the air!

iPad 3 Conspiracy Theory Glenn Beck Style