Friday, 18 April 2014

ADB Troubleshooting

Android Debugger Bridge (ADB) 

Detect your connected devices/emulator instances from command line console/terminal with 'adb devices' (of course without those single quotes).


That should list them. If you don't find any, it's troubleshoot time!

Troubleshooting


'adb' and 'android' are platform-tools or tools inside your SDK folder downloaded from Google. Update to the latest by launching the SDK manager 'android'.

Tip: It helps to have these tools folders listed in environment path variables. Otherwise, to invoke, you'll need to go in to that folder each time.


Use 'adb kill-server'
to recover broken adb sessions
At times, 'sudo adb kill-server' might help better on Linux. This followed by 'adb devices' will automatically run 'adb start-server'.

Sometimes explicit 'adb start-server' or 'sudo adb start-server' also helps.

If this isn't an emulator but a device over USB, check the USB cable.

Easily forgotten: Try with another cable.

Update USB drivers in Android SDK manager.
Update USB drivers for your OS if any. Disconnect the device. From control panel's device manager (on Windows) remove and add drivers manually. Android composite device will show up on pointing it to drivers downloaded as part of 'android' SDK update.

Enable USB debugging in device's Settings> Developer options> ...
If 'Developer options' don't show up, enable that by tapping Settings> About> Build version 6 times!

First time, unlock the device and accept the dialog asking for your permission for USB debugging.

Saturday, 5 April 2014

Culprit in MH370 Case Is Well Known

Throughout this month, the first tab on my mobile browser has been refreshing the same URL: News feed from Google News (Search Tool : Past 24 hours).

After reading hundreds of promising articles through the month, today's news about ping from some black-box just before its battery is about to die don't fill me with excitement but a bit of anguish

Some of my friends have questioned my sanity in this regard? Well, not that harsh, but they've stopped following this news item and would rather like it if I too could ignore as though this is a non issue. 

Why do I relentlessly refresh this page few times every day? Apparently I shouldn't have to unless am a close relative, news reporter, NTSB agent, government assigned search/rescue worker, a Chinese or a Malaysian or a pilot or ... someone affected in some immediate way. 

Am none of these. Am not even remotely related to any of those on board or the concerned agencies, professions, governments or even a frequent flyer! While not particularly insensitive, am not that sensitive. So short of empathy, it is perhaps just the right mix of associated mystery or the associated anger at those responsible. 

For a moment, lets forget the inadequacies in reporting and searching after the flight vanished. Lets think about the flight before it took off. Please let that moment last till you reach the end of this post. 

How in the heal could a huge flight carrying 239 people vanish in this age!?! What happened to all those technologies? Satellite phones have been used by crew and first class customers on some flights ever since 1989! Yes, I am aware that GPS is just passive receive stuff. But what stops one from pinging deduced GPS based location from two ends of a plane independently on modern passenger flights to some base through satellites? Okay encrypt it if you must. Why should the pilots even need a switch or have to turn this thing on? This doesn't cost battery. This must be a modular independent fitting on non-military aircrafts. There are so many humans you'd be carrying on daily basis. Isn't there associated responsibility? Then of course you could transmit black-box's content if bandwidth and battery/power allow. 
But what stops one from pinging deduced GPS based location from two ends of a plane independently on modern passenger flights to some base through satellites?
Image Courtesy edn.com 

Most relevant engineers (including myself) could build one such with a near zero budget and access to few kilo bits of low earth orbit (LEO) satellite bandwidth per annum. Boing and Airbus claim that some of these technologies are available now but haven't been back-ported to older aircrafts. How dare you charge hundreds of millions for a flight, and further few millions for annual maintenance but won't be bothered to retrofit a device that won't cost even tens of thousands in the first place and again couple of thousands to run and maintain per year?

There are several possible explanations now - equipment failure, terrorism, pilot lapse, sabotage, collision, … all the way to alien abduction. Choose what suits your whim but this mystery would've been lot simpler had we used this (relatively low-cost) multi-decade old technology properly.

Hence I blame it all on the lack of basic business ethics. On Airbus? On Boeing? No. 

I mean yes, those too but collectively on the entire system run by those without least level of respect, concern or empathy for human life, without a grain of business ethics once payment is made, once their cut is received, once their political or business needs are satisfied. I blame the companies, the respective agencies responsible for mandating rules and regulations, the concerned fake democracy funders, lobbyists and benefactors, the politicians and ourselves who'd love to ignore these. 


Yes, I blame you too, 'mister closest relative of the passenger', we let such things happen and collectively agree to ignore till we're the affected party. Thousands of such atrocities don't even reach the common man for we don't care and even if we did, complexity confuses the tired eyes, take the financial system for instance. Sorry, actually forget it, am not going to start on it today. We let many such events happen today too. MH370 was just one of those to reach our eye. But wasn't enough to be a wake up call. Lets sleep well tonight after bad mouthing the airlines, the urgently famous and immediately notorious Malaysian minister(s), the search/rescue agencies, the terrorists, the pilots and the aliens to our satisfaction. Amen.

Dedicated to all those on board and the dumb prick who spins alien conspiracies to lighten our heart in such times. Sorry and thanks respectively. 

Wednesday, 2 April 2014

USB Tethering Android Device with Mac OS X

USB Tethering has its advantages over Wi-Fi Hotspot. Most importantly it doesn't drain the battery juice of your phone compared to a Wi-Fi Hotspot. And when you need tethering, you're probably travelling (away from power sources, ...). 


Internet <----> Mobile Operator <----> Android Phone/Tablet <--USB--> Mac OS X



Enable USB Tethering on Android Device

Verify that your Android device has the capability exposed in Settings > Wireless & Networks > More ... > Tethering & portable hotspot > USB tethering. 

Tick it.

Background of RNDIS

Android devices utilize Microsoft's RNDIS (Remote Network Driver Interface Specification) protocol for USB tethering. With Windows it works out of the box and Linux drivers too exist. Now a driver maintained by Joshua, brings RNDIS support for to OS X. 

Download and Install 

Download latest driver's binary package for Mac OS X from local mirror (rel 5) or JoshuaWise or compile from sources if you must from git

Quoting from Joshua's page:

HoRNDIS (pronounce: “horrendous”) is a driver for Mac OS X that allows you to use your Android phone's native USB tethering mode to get Internet access. It is known to work with Mac OS X versions 10.6.8 (Snow Leopard) through 10.9 (Mavericks – see notes below), and has been tested on a wide variety of phones. Although you should be careful with all drivers that you install on your computer, HoRNDIS has been tested at least well enough for the author (and many others) to run full time on their own personal computers.

HoRNDIS is implemented as a kext, rather than as a user-space program that opens a TAP or TUN device; this means that it does not conflict with other TAP/TUN kexts that you might have installed (like OpenVPN, Tunnelblick, or Cisco VPN). The driver implements Microsoft's proprietary RNDIS protocol, which is the only protocol supported natively by Android devices; although Linux and Windows users have enjoyed native RNDIS drivers for years, Mac OS X supports only CDC Ethernet devices out of the box.

The chief advantage of HoRNDIS over other tethering solutions is that it uses the a first-class supported feature in the phone's firmware. Other solutions either take over the phone's Wi-Fi stack without the Android operating system's knowledge, or create an emulation IP stack in userspace on the phone; in many cases, the built-in USB tethering support can be more stable, more reliable, and faster.



Assuming you start with the binary package, double click to start installing and accept defaults. 
Once you reach the "completed successfully" screen, connect your Android phone or tablet over USB and you're good to go. OS X will show a popup about new network interface. If you don't see one, you can always go to the same through System Preferences > Internet & Wireless > Network
Defaults shown on OS X when Nexus 4 with USB Tethering is connected
Here again accept the defaults and click "Apply".




Now the same screen will display IP addresses fetched from the Android device as shown in the screenshot and your laptop will be connected to the Internet. 

Enjoy browsing on Mac OS X with Internet from your phone.