Develop Reference

Is it possible to use OTG Host Negotiation Protocol to change modes while connecting two devices?

I have two android phones connected with an OTG cable. Obviously, the cable forces once phone into host mode and the other becomes the peripheral. I would like to be able to dynamically alternate the host/peripheral status of the devices without switching the cable around and the OTG HNP spec seems to indicate that is possible. I found some further information on it here but I'm not sure where to go with it - https://android.googlesource.com/kernel/msm/+/android-msm-bullhead-3.10-marshmallow-dr/Documentation/usb/msm_otg.txt

Yes, it is possible. Good find on the very technical documentation. However the Developer.android.com site and the USB.org has more information regarding implementation:
USB accessory and host modes are directly supported in Android 3.1 (API level 12) or newer platforms. USB accessory mode is also backported to Android 2.3.4 (API level 10) as an add-on library to support a broader range of devices. Device manufacturers can choose whether or not to include the add-on library on the device's system image.
Link
As far as I can tell Host negotiation always favors traditional Host controllers like computers. Android devices have traditionally been USB accessories. However a very complicated situation arises when you have a hub with a host (like a PC) and another accessory plugged in. It seems like there is no way to settle the dispute about which device should be a host the Android or the PC. For instance I plugged in a host PC to a Android device with a HUB attached and a gigabit ethernet dongle. I could never establish a connection with the dongle. In fact the HNP never seemed to take place.
Finally, the documentation seems to suggest that the Host is responsible for operating the USB Stream. What seems most promising is the documentation Here which establishes the direction of a USBEndpoint.

How can I make my Android application to act as a Beacon?

I want to develop two Android applications out of which one application should act as a Beacon. That is, one of my application installed in one device should listen certain events from the other app installed in other device and should broadcast some information on listening those events.
I read many articles and I found that the Android device must have Bluetooth LE hardware and it must have peripheral mode enabled by the device manufacturer. But most of the manufacturer as well as Google itself has disabled peripheral mode.
So my question is there a way (a Beacon library available?), so that I can make my application to act as Beacon.
Thanks in Advance.

You can use the Android Beacon Library to make a device both transmit as a beacon and detect/decode beacon transmissions.
It is true that devices must have BLE hardware for this to work, Android 4.3+ to detect beacons and Android 5.x+ to transmit as beacons. While not all devices with 5.x+ support peripheral mode needed to transmit, most popular devices do. Google has not disabled this, and their newer Nexus and Pixel devices support transmission as well.
The library linked above has a list of devices known to support transmission, and includes example code showing how to determine this at runtime on a specific device.
If a device does not support peripheral mode, there is nothing you can do short of rooting the device and trying to write a new Bluetooth driver yourself.

How to detect USB port on android?

I'm developing printer application based on Android phonegap.Now i hard coded the data and sent it to the printer.It's working fine.But my requirement is data will come on from the taxi meter via USB cable.How can i detect that data coming port?

What you're most likely looking for is the Android Open Accessory Development Kit. Keep in mind the following:
Note: Accessory mode is ultimately dependent on the device's hardware
and not all devices will support accessory mode. Devices that support
accessory mode can be filtered using a <uses-feature> element in
your corresponding application's Android manifest. For more
information, see the USB
Accessory
Developer Guide.
Another thing to be aware of is that if your other device does not support Accessory mode, you can either make it support accessory mode (you haven't mentioned if this a homebrew or commercial device), or root your Android device and then pretty much anything is possible.

Android USB host-to-serial connection?

Apparently with Android 2.3.4 and 3.1 one can now access USB accessories.
I have a Ardupilot Mega (based on Arduino) board with a USB cable connected to my laptop, and I can connect to it using a simple serial communications program over COM7 and 115,200 baud. This allows me into the command-line interface, and I can issue commands and get logs.
Is it possible to write an Android app that will communicate over USB to my Ardupilot Mega board?
I've seen many similar threads, but most of them were pre-USB host.

usb-serial-for-android is my open source library written for exactly this need. It supports FTDI and CDC-ACM usb serial devices using Android's USB host support; no root or ADK necessary. It can talk most Arduinos.
The project is still in its early days, but the basic support has worked well enough for several projects. There is also a discussion list where you can get help.

Unfortunately the library from mik3y's answer (see here: mik3y/usb-serial-for-android) seems to be long dead. It has many problems and waiting pull requests. Also the LGPL licence prevents anybody to fork it and maintain it.
But don't lose your hope, there's a working replacement and it's under the MIT licence. felHR85/UsbSerial.
EDIT: I found a maintained fork of mik3y's library. But the licence or readme is not updated, so I suppose the owner doesn't have a connection to mik3y and simply took it and improved it. I hope he won't get into any trouble because of the licence, because we need this library. See kai-morich/usb-serial-for-android
EDIT2: It seems that all of these libraries are maintained again, mik3y joined forces with kai-morich and they're working together now.
EDIT3: mik3y/usb-serial-for-android is under MIT license now. And still maintained in 2022.

Maybe. Check out the Android Open Accessories announcement on the Android Developers Blog. The Arduino Mega ADK is compatible. Not sure about the Ardupilot Mega.
From their page:
The Android 3.1 platform (also backported to Android 2.3.4) introduces
Android Open Accessory support, which allows external USB hardware (an
Android USB accessory) to interact with an Android-powered device in a
special "accessory" mode. When an Android-powered powered device is in
accessory mode, the connected accessory acts as the USB host (powers
the bus and enumerates devices) and the Android-powered device acts as
the USB device. Android USB accessories are specifically designed to
attach to Android-powered devices and adhere to a simple protocol
(Android accessory protocol) that allows them to detect
Android-powered devices that support accessory mode. Accessories must
also provide 500mA at 5V for charging power. Many previously released
Android-powered devices are only capable of acting as a USB device and
cannot initiate connections with external USB devices. Android Open
Accessory support overcomes this limitation and allows you to build
accessories that can interact with an assortment of Android-powered
devices by allowing the accessory to initiate the connection.
Note: Accessory mode is ultimately dependent on the device's hardware
and not all devices will support accessory mode. Devices that support
accessory mode can be filtered using a "uses-feature" element in your
corresponding application's Android manifest. For more information,
see the USB Accessory Developer Guide.
The following list of distributers are currently producing Android
Open Accessory compatible development boards:
The Arduino Store provides the Arduino Mega ADK (in EU nations or
non-EU nations) that is based on the ATmega2560 and supports the ADK
firmware. DIY Drones provides an Arduino-compatible board geared
towards RC (radio controlled) and UAV (unmanned aerial vehicle)
enthusiasts. Microchip provides a PIC based USB microcontroller board.
Modern Device provides an Arduino-compatible board that supports the
ADK firmware. RT Corp provides an Arduino-compatible board based on
the Android ADK board design. Seeed Studio provides an
Arduino-compatible board that supports the ADK firmware. SparkFun's
IOIO board now has beta support for the ADK firmware.

You can check out the library described in Slick USB 2 Serial Library.
It enables common USB-to-serial adapters to work with Android devices that have USB host mode without needing to root.

http://slickdevlabs.com/
I am currently using the library in my own app, however I think you can get away with just the app that slick has on the market. There are two free apps and one is the "pro" version of one of the free ones; search slick usb in Google Play.
It does use HOST mode and you can change the baud rate to whatever you need.

Android Emulator vs Real Device

What are the differences developers should be aware of?

I am aware of these limitations:
Pre-installed software. Real device can have preinstalled a lot more applications than emulator.
You cannot use "capture" photo/video functions in emulator.
According to emulator documentation, its limitations are:
The functional limitations of the emulator include:
No support for placing or receiving actual phone calls. You can
simulate phone calls (placed and received) through the emulator
console, however.
No support for USB connections
No support for device-attached headphones
No support for determining network connected state
No support for determining battery charge level and AC charging state
No support for determining SD card insert/eject
No support for Bluetooth
IMO you can use emulator to simplify UI development, to view UI on "device screen", to be sure that app layout is ok, app can be run, you can test some special cases by simulating gps position, network speed or messaging etc. But testing on real device is a must.

With the 1.5 SDK the following limitations exists (from the SDK website):
No support for placing or receiving actual phone calls. You can simulate phone calls placed and received) through the emulator console, however.
No support for USB connections
No support for camera/video capture (input).
No support for device-attached headphones
No support for determining connected state
No support for determining battery charge level and AC charging state
No support for determining SD card insertion/removal
No support for Bluetooth
No support for Multitouch
Based on experience I've noticed the following differences in actual developemnt:
There are bugs you'll be able to ignore in the emulator that will crash the device (not closing Cursors for example)
You interact with the device differently than the emulator. I use landscape mode a lot more with the real device than I do with the emulator.
There's a different CPU. Things that are fast on your emulator will be slower on the real device.
You can dogfood with the device. It is harder to dogfood with the emulator.
There is a google group here if you need real device testers.

One cannot test touch events with emulator which has to be tested only by means of mouse clicks on emulator which any developer going to develop an application based on touch screens should be aware of.

I'd say the main thing is that there are several "real devices" currently using Android, and there will be more, with different hardware endowments -- some will have GPS and some won't, ditto for touchscreen, real keyboard as opposed to virtual on-screen one, camera resolution, etc, etc.
While the OS will do a lot of the heavy lifting for you, you still want to make sure your design a user experience that makes sense on every Android device you intend to support, despite the variation in their HW features -- in this sense, designing applications for Android is more similar to designing them for, say, Linux, Windows, or the Web (cater for a wide variety of hardware-configuration details), rather than e.g. Macs or iPhone (where you need to consider a much narrower set of possible HW configurations).
The emulator is (or tries to be;-) "one" Android device -- but there will be others ("real" ones;-) with different screen resolutions, input peripheral devices, etc, etc...

One comment regarding google accounts: With version 8 of the google APIs for Android 2.2, you can add a google account on the device. However, it will only allow authentication for tests of the google APIs (e.g. google documents) but not syncing of contacts etc.

This is a bug, since camera and video support was attempted (incorrectly): the camera and video intents do not store their output in the MediaStore database after "capture."

In simple terms, an emulator is a device that runs on your computer (as software) whereas a real device is something you can hold. There will of course be a few differences between the two such as some device-specific features won't be available on the emulator.
Edit: Removed a link from the answer that had expired.