Recently, BlackBerry Cool wrote about a product called NetworkAcc, which claims to speed up your mobile network. A lot of BlackBerry sites have published their skepticism about the product, and rightly so.
NetworkAcc seems like a very cool concept that would certainly be of use to many. Unfortunately, none of what they claim to do is currently possible to the publicly exposed APIs.
The limitations of 3rd party access to API’s
Third party applications are fairly limited in what they can achieve in terms of network manipulation. For the most part, much of this is handled by the underlying framework, and most of it is handled at the OS layer. It is important to understand the overall architecture of the software on the device. At a high level, it looks something like this:
Operating System: Written in C++, this layer handles hardware interaction networking, process management and memory. Code written at this layer is compiled into machine code and run directly off the processor.
Virtual Machine: Also written in C++, the virtual machine is what runs all of the Java software on the phone. It sits just above the OS, and handles all Java related tasks, like interpreting byte code, managing program memory and all the other fun tasks that programmers would much rather ignore.
Java Apps: This layer is what people mistakenly call the OS. In reality, it is what makes up the front end interface to much of the native (C++) level software. Internally at RIM, programmers have much flexibility through the Java Apps APIs to plug into various native system functions, such as the GPRS packet framework.
In the public space, which is what 3rd party developers have access to, the Java Apps APIs are very limited in terms of how much you can manipulate the core system functionality. You cannot, for example, plug into the underlying network system and globally affect how the data is buffered and the speed at which it is sent.
The following is an example of what 3rd party apps can affect on the device in terms of network:
// Initiate a connection to blackberrycool
HttpConnection c = (HttpConnection)Connector.open( “http://www.blackberrycool.com;deviceside=false” );
This little snippet describes the interface that 3rd party developers have to create connections. The API Connection.open() is the only interface to the native level, and all of the actual network code was written into the OS. The parameter on the end, deviceside=false, indicates the connection type (in this case, route traffic through a corporate BES). There are a few other parameters you can manipulate, and they do not affect speed or throughput. After this call, the programmer has no control over how the connection is set up, how the packets are formed, what header data is placed into the packets at the tcp/ip layer etc.
Using hidden APIs to offer more features
There are a few hidden APIs that are exposed publicly, but not documented. Fortunately, it is easy to find out what those are. A developer only needs to extract the .class files from net_rim_api.jar, the library that describes the BlackBerry framework, and run javap on them.
javap is an application that will look into the .class files for the method symbols and pull them out for all to see. In other words, it will un-hide the hidden APIs. In addition to the hidden APIs, there are also magical strings, like the App World application property strings, that can be used to do all sorts of fun stuff. But the point of explaining all this is not to show what you can do, but what you can’t. Even in the hidden APIs, there is no way to manipulate how the device connects to the network.
Side note: traffic counters
There is another app (or 2) out there that purports to be able to count how much traffic in kilobytes is flowing through the device. Third party applications only have the capability to ask for the total number of packets sent and received by the device, via this call:
RadioInfo.getNumberOfPacketsReceived() and RadioInfo.getNumberOfPacketsSent()
The data you get out of those two methods is misleading. It is important to note that a packet can be of variable size. In fact, packet size can vary by hundreds of bytes. The MTU (maximum transmission unit) of a packet on the device is somewhere in the range of 600-1200 bytes.
Packets can be chunked up into smaller pieces when required, much smaller in fact. You can have packets that are only 8 bytes long! This means that the number of packets really has no direct correlation to the total amount of data. In fact, these applications are probably off by a significant order of magnitude. Still, the capability to see the number of packets going across the network is good information to have, and can give users a rough estimate when shown on a graph what their data usage looks like over time. Unfortunately these apps are not fairly presenting the data.
Access to RIM internal APIs
No 3rd party organization has or ever will have access to RIMs internal APIs. The only way to gain access to internal APIs is to be acquired by RIM and work at RIM. You will notice that applications like MSN messenger, Yahoo messenger, Google Quicksearch, Facebook, and all other applications that look like they have access to some special device functionality were in fact written by RIM.
What 3rd party apps CAN do
Third party applications can affect a number of network settings for themselves, but not others. Note that again, these settings do not include speed and throughput. Tird party apps can specify whether to connect via BES, BIS-B, WiFi, Direct TCP, WAP2, WAP. They can also specify WAP and tcp gateway parameters like apn, username and password. There are a few other parameters that effect security and network timeout but again, those aren’t relevant.
Hacking the native layer
This is very very difficult. Actually, gaining access to the native layer via a Java level 3rd party application is completely impossible.
The buyer must be beware of what applications such as NetworkAcc claim to offer. By knowing what levels of access 3rd party developers have to the device, you can be a better judge of what claims are valid.
