This is my first time developing an android game. I want to create a flow game in which specific nodes must be connected in a particular order only. for e.g. a computer will connect to a modem and then the modem will connect to a router (its a network based game). So far the algorithms that i have come across do not deal with specific order free flow.(Refer this or this.) Is there an existing algorithm for this?
P.S. I am making use of libGDX.
the game will be similar to this.
You won't be able to find an algorithm that is created just for this specific problem. What you are looking is a search algorithm, for example BFS and modify it to use in this game.
In BFS, you start with a cell and add valid neighbor cells into a queue and iterate through this queue until you reach to destination or queue is empty (you didn't reach the destination).
For this game, first you have to define which neighbors are valid. There are 7 types of cells
empty cells : never valid
destination : always valid, end algorithm here
source: never valid, you don't want to move source square back
vertical tunnel: only valid if previous cell is also a vertical tunnel or one of modem, router, source
horizontal tunnel: only valid if previous cell is also a horizontal tunnel or one of modem, router, source
modem and router cells will be a little trickier, while iterating through queue, you also need to push type of current path. Current path will be initially "source", if you pass through a modem it will be "modem" and if you pass through router it will be "router". With this in mind, rules for router and modem are
modem: only valid if current path is source or modem
router: only valid if current path is modem or router
You will need to implement a simple finite state machine.
For implementation details, you can have a look at How to implement a FSM - Finite State Machine in Java
This has to be integrated into any algorithm (referred by you) to check validity.
Hope this helps. Good luck.
I'm working on android kernel (jelly bean).
I've focused on the /net/mac80211/scan.c module and on the scan behavior, to understand how the PS_mode exactly works. Anyway I can't find any syscall calling the ieee80211_scan_work function (where the ieee80211_start_scan() func is called) of the kernel on a higher level.
I'm wondering if this function is even called by the API, does anyone know it, and if it does, which syscall is rised?
See my response here to get a general overview of mac80211:
How to learn the structure of Linux wireless drivers (mac80211)?
The interface from userspace isn't based on syscalls but uses the netlink API.
Scanning is done by sending a NL80211_CMD_TRIGGER_SCAN command. After you get a NL80211_CMD_NEW_SCAN_RESULTS event that scanning was finished, you issue a NL80211_CMD_GET_SCAN to get the scan results.
To see examples of this look at wpa_supplicant code.
You can't see anyone calling ieee80211_scan_work because it's a workqueue handler. If you're not familiar with workqueue you can pick up a kernel book which explain them.
This work gets initialized in ieee80211_alloc_hw() as the handler of local->scan_work.
The code which "gets this running" is in ieee80211_start_sw_scan() which actually queues scan_work. Note that scan_work is only used in SW scan which means that mac80211 manages the scan (i.e. it keeps a timer to switch channels and calls the lower HW driver to set the HW to the specific channel). This is used only depending on your HW capabilities. For some hardwares the scan is done completely by the HW driver or even in firmware.
If your HW driver implements a HW scan it will implement the hw_scan mac80211 callback.
I am fairly new to Android Development and i have recently been exploring Usb Host.
Would anyone be able to tell me how to use Bulk Transfer so that i can see what an external camera sees but instead show it on my tablet?
Camera : Canon Powershot A1300
Tablet : Iconia A200
I have looked around stack overflow and some other forums but have not yet been able to find a good explanation on how to use Bulk Transfer or what constants to use as parameters for retrieving certain data.
I am able to see the endpoints and set up a connection with the external camera but I do not know where to go from here.
Any help is deeply appreciated.
The USB Host APIs in Android are fairly thin, by which I mean once you have gone beyond enumerating the interfaces/endpoints and creating a connection it doesn't do much more to assist you. You are then in the realm of communicating with raw USB data transfers, the format of which depend on the device class your camera represents. Your request is somewhat a can of worms, so I will do my best to provide helpful resources.
Unfortunately, storage and media devices are not the simplest device classes to interpret, so it may be difficult if you are just getting your feet wet on USB in general. The best advice I can give is to take a look at the device class specs for the interface class your camera reports (most are either Mass Storage or MTP), which can be found here: http://www.usb.org/developers/devclass_docs
The spec document will enumerate the commands you need to use to communicate with the device. I would also recommend checking out USB In a Nutshell, which does a great job of pointing out how USB requests are constructed in general, which can help you map what you see in a the spec docs to the parameters found in the methods of UsbDeviceConnection: http://www.beyondlogic.org/usbnutshell/usb1.shtml
There will likely be a handful of control commands you need to send to "endpoint 0" initially to set up the camera, and then the remaining transfers will likely take place over the bulk endpoints.
In Android terms, control requests can only be sent synchronously using UsbDeviceConnection.controlTransfer(), meaning this method blocks until the transfer is complete. The parameters that fill in this method are found in the spec docs for your device class.
Requests on bulk endpoints can be sent synchronously via UsbDeviceConnection.bulkTransfer() OR asynchronously using a UsbRequest instance. With UsbRequest you can queue a transfer and then later check back (via UsbDeviceConnection.requestWait()) for the results.
I have some examples on my Github page in using the host APIs to do some basic interrupt and control transfers to get information like device descriptors. Perhaps some of that will be helpful to you as well: https://github.com/devunwired/accessory-samples
With regards to your question about the USB example code:
The request made in this code is just a generic "Get Configuration Descriptor" request that all USB devices must respond to (it's a core command, not class-specific). In fact, its the request where the Android APIs get the information you can query for interfaces and endpoints. The field values come from the Core USB Specification (this command specifically is defined at section 9.4.3 and 9.6.3 in the 3.0 spec): http://www.usb.org/developers/docs/ or a more helpful description you can find from USB in a Nutshell, which has a little more discussion: http://www.beyondlogic.org/usbnutshell/usb5.shtml#ConfigurationDescriptors
The length is somewhat arbitrary, this tells the driver how many bytes to read or write. Most USB host drivers will first query the device descriptor, which includes a field telling the host the Max Packet Size the device supports, and then will use that size as the length for future requests. A full-featured driver would probably make this command and then check the length bytes first (the wTotalLength field of the descriptor) to see if the buffer was large enough, and modify/resend if not. In the example, I just chose 64 for simplicity because that is the "maximum" Max Packet Size the protocol defines as supportable.
Again, then making requests of the specific data your device has to offer, those commands will be found in the specific class document, not the core specification.
I would like to know high level idea of how Android Modem code will call/pass message to Android application layer. Say we take SMS for example. If network sends SMS and Modem (say Qualcomm C code parses it) how is it transmitted to Android Application layer?
Is there always a JNI call happening? as interface between modem and Android? Can you please share the information with us. Thanks
In almost all android source base as found in the AOSP/CAF/CM source (Android Open Source Project, CodeAurora Forum, Cyanogenmod respectively), will have C code called the rild, (Radio Interface Layer Daemon). This is commonly found within the /hardware/ril of the source tree.
This daemon runs from the moment Android boots up, and creates a socket called /dev/socket/rild and /dev/socket/rild-debug. There will be a proprietary library coming from Qualcomm, HTC, that gets dynamically loaded at run time upon boot. It is that proprietary library that in turn, communicates to the radio firmware. And the rild's hooks for the call-backs into the proprietary library is established there and then.
At the rild layer, via the aforementioned socket, is how the Android layer (found in the source tree, frameworks/base/telephony/com/android/internal/telephony/RIL.java) communicates.
On the Java side, it opens the socket for reading/writing, along with establishing intents and setting up delegates for broadcasting/receiving events via this socket.
For example, an incoming call, the proprietary library, invokes a callback hook as set up by rild. The rild writes standard generic AT Hayes modem commands to the socket, on the Java side, it reads and interprets the modem commands, and from there, the PhoneManager broadcasts CALL_STATE_RINGING, in which Phone application (found in the source packages/apps/Phone) has registered a receiver and kickstarts the User interface, and that is how you get to answer the call.
Another example, making an outgoing call, you dial a number on Android, the intent gets created and which in turn the PhoneManager (This is the root of it all, here, cannot remember top of my head, think its in frameworks/base/core/java somewhere in the source tree) receives the intent, convert it into either a sequence of AT Hayes modem commands, write it out to the socket, the rild then invokes a callback to the proprietary library, the proprietary library in turn delegates to the radio firmware.
Final example, sending text messages, from the Messaging (found in packages/apps/Mms source tree) application, the text you type, gets shoved into an intent, the PhoneManager receives the intent, converts the text into GSM-encoded using 7-bit GSM letters (IIRC), gets written out to the socket, the rild in turn invokes a callback to the proprietary library, the proprietary library in turn delegates to the radio firmware and the text has now left the domain of the handset and is in the airwaves somewhere... :) Along with sending a broadcast message within Android itself, provided that READ_PHONE_STATE permission is used and specified in the AndroidManifest.xml.
Likewise conversely, when receiving a text message, it is in the reverse, radio firmware receives some bytes, the proprietary library invokes the callback to the rild, and thus writes out the bytes to the socket. On the Java side, it reads from it, and decodes the sequence of bytes, converts it to text as we know of, fires a broadcast with a message received notification. The Messaging application in turn, has registered receivers for the said broadcast, and sends an intent to the notification bar to say something like "New message received from +xxxxxx"
The intents are found in frameworks/base/telephony/java/com/android/internal/telephony/TelephonyIntents.java
That is the gist of how the telephony system works, the real beauty is, that it uses generic AT Hayes modem commands thusly simplifying and hiding the real proprietary mechanisms.
As for the likes of Qualcomm, HTC, forget about it in thinking they'd ever open source the library in question because the radio telephony layer is embedded within the S-o-C (System on a Chip) circuitry!
Which is also, as a side note, why its risky to flash radio firmware, some handsets provide the capability to do it, flash the wrong firmware (such as an incompatible or not suitable for handset), kiss the handset good-bye and use that as a door stopper or paper-weight! :)
It should be noted, that there is zero JNI mechanisms involved.
This is from my understanding of how it works, from what I can tell is this, the radio firmware is loaded into a memory address somewhere where the linux kernel has reserved the address space and does not touch it, something like back in the old PC days when DOS booted up, there was reserved addresses used by the BIOS, I think, its similar here, the addresses marked as reserved are occupied by the firmware, in which the proprietary radio library talks to it - and since the library is running in the address space owned by the kernel, a lá owned by root with root privileges, it can "talk" to it, if you think of using the old BASIC dialect of peek and poke, I'd guess you would not be far off the mark there, by writing a certain sequence of bytes to that address, the radio firmware acts on it, almost like having a interrupt vector table... this am guessing here how it works exactly. :)
Continuing from the explanation by t0mm13b, When we talk about a smartphone, think of 3 layer operations wrt to SMS/Calls.
RIL (User level) <-> AP <-> CP
AP : Application Processor(Where your Android OS runs. Think of games, songs, videos, camera etc running on this processor)
CP : Cellular Processor (Which actually deals with Air-interface for incoming/outgoing calls/sms, interacts with Network Tower etc ..)
Now let say some data is received at CP side (It could be internet data/sms/call). Now there are certain logical channels between AP and CP. So CP will push the data received to a corresponding channel based on type of data. This data will be received by AP. AP will send this data back to RIL/App. RIL will decode this data (specially call/sms data). Based on that gives notification to User about SMS/Call.
I would like to remotely reprogram my Arduino via Android over Bluetooth SPP. The first step is to reset the ATMEGA microcontroller. This is accomplished on the Arduino by toggling the DTR line. Is there any API to control the Bluetooth SPP control lines from the Android environment?
Also it is supported by SPP in general to send or receive the control signals (DTR, DSR, RTS, CTS) I do not know any API or library for android right know, but as you just want to reset your controller...
If it is o.k. for you to change your firmware you can also create your own reset-command that can be received on your UART (over SPP).
If you receive that command you could call something like
asm("jmp 0x3800");
where you have to modify the jmp-address to point to your bootloader.
You also might want to change your interrupt vector to point to your bootloader.
Or enable your watchdog and call
while(1);
This will also automatically change the interrupt vector to the bootloader's interrupt vector and reset all SFRs. - But it is a little bit slower and the bootloader's interrupt vector must be choosen in the Fuse Bits.
I realise that this is not what you wanted, but you could always flash a new bootloader with a longer timeout and manually press the reset button before starting programming.
The new Arduino bootloader (optiboot) fits in 512B (versus the 2K of the old one) so you have extra space available to your projects; has smart boot detection, so it only enters the bootloader when the reset button is pressed; and you can extend the timeout by editing the watchdog timeout value in the source (around line 267 in optiboot.c).
// Set up watchdog to trigger after 500ms (changed to 2s!)
watchdogConfig(WATCHDOG_2S);