I want to filter the packet data based on the type of data they carry. I mean is it possible to recognize whether the packet carries text/audio/video/other type of information by analyzing the packet header or the payload?
Also, I want to be able to do this in real time; so that I can keep track of How much of data has been used up in text/audio/video etc.. Can these things be done using tcpdump? I want to run in a tizen/android phone..
A few things might be needed to achieve this.
In Tizen, you need su access to the device and install tcpdump and a host of other libraries like libpcap for example.
For HTTP you could rely on MIME headers.
You could use pre-defined standard ports in certain cases.
For Audio and Video you could examine the payload and see if the header matches and then classify.
But to generalize it across all data formats is going to take some work beyond simply reusing existing tools like tcpdump.
I am transplanting android to my stb, and I want stb could support touchscreen.
the touchscreen connecte to stb with a serial cable
I am trying to support it in native layer, but I don't know how to do.
I have tryed the following method: using "process" function in inputread.h, but inputreader is not singleton, I can't get it's pointer or refrence.
what should I do?
This is a tough task.
First, you must well know the details of how a touch event is processed. To understand a standard touch event format typically in /dev/input/xxx.
Second, you need to figure out how your current serial touch panel works, what is the out put format of this device.
If your tty device output the same format of a standard touch event, you can simply configure the HAL to open the specific device and all will be settled.
Else, if it is not a standard touch event format, two options for you:
1. Adapt to this format in event hub layer
2. Transform this format in driver layer
Both are not very easy.
TL;DR
android, board-like game.
latency unimportant.
client-server via LAN/Global, potential high score => no trust.
potential bluetooth layer in future => full trust.
mobile means expensive traffic, upstream more expensive than downstream.
PRNG used a lot, must be deterministic.
kryonet for serialization + transmission
Me & a couple of pals are building our "port"/"flavor" of a board-game (with a lot of different event-types and permutations of all sorts) to Android and adding a networked multi player aspect to it. We are no encryption or networking experts =)
The game:s default multi player layer will be client-server based (server is either dedicated host or run on an android device [in case you're out in the woods with your friends and you've no network] ). This might be a global server, or LAN - it doesn't matter much.
But there might be a potential high-score which needs some anti-cheating mechanisms
As it is a turn-based board-like game, latency is neither an issue.
In the future, if we've time - we might add a bluetooth based layer, but in this case cheating is not an issue as the assumption is that the people know each other well.
Since we're dealing with a (most likely) mobile network where upstream is more expensive than downstream, downloading from server is cheaper than sending the models from client.
We'll probably be using kryonet for the serialization and transmission of data.
The game will use PRNGs quite frequently, and as such it needs to have some good anti-cheat and verification logic, so after a lot of searching and reading at gamedev & stack overflow, I've devised the following logic. I need some input on how sound the plan is. All tips and recommendations are greatly appreciated.
Assumptions / Considerations:
PRNG behaves deterministically ( thinking of using Mersenne Twister ).
Normal game play shouldn't be penalized due to anti-cheat measures.
Scheme / Plan:
On "handshake" / first connection since "onResume()" - acquire PRNG seed from server and store it. Each player has its own seed in server.
Also send hash of game state to server in same request and if out of sync,
sync game state.
On action / user input, get next random number -> save to "bucket of randoms" (hence known as bucket - the bucket is a "trapped list" to which you may add but never remove). Also save input ID/Type/Enum to a list.
Accumulate changes until other players have to know (i.e next players turn) / PNR (Point of No Return)
PNR reached
Send change ID/Type/Enum ( ca. 64 bits ) + bucket + hash (post change) of model. Should bucket + hash be encrypted, maybe AES 256 (other encryption tech that's more suitable?).
Check bucket against N consecutive random numbers where N = size( bucket ). If no match, goto 6, then 7.
Make changes to model temporarily (without committing to full game model).
Compute hash and check against client provided hash. If invalid goto 6.
Valid: commit to game model on server.
Invalid: ask client to revert to state sent back by server.
Cheat: Ban ( not IP [dynamic IPs...], rather MAC addr or UID ) / Remove from game on several cheats.
EDIT: Also - another question regarding anti-cheat... Any good ideas for antimeasures for bot teams of 2 farming highscores for a board-like game?
EDIT2: Here's the links to the pre-question research I did:
https://gamedev.stackexchange.com/questions/4181/how-can-i-prevent-cheating-on-global-highscore-tables
Good link (for de-centralized, client-client protocol): https://gamedev.stackexchange.com/questions/47145/peer-to-peer-hostless-competitive-games-of-chance
http://en.wikipedia.org/wiki/Commitment_scheme
iphone puzzle game: Code examples for simple game servers
Look into:
5) Use some lightweight polymorphic encoding on your game connections.
6) Use some anti-debugging techniques to prevent debuggers from attaching to your processes. Google anti-debugging and you should be able to find lots of stuff.
7) Use a custom proprietary PE packer to prevent useful disassembly of your game.
8) Using hashes as a promise, and then reveal the meaning of the hashed promise once conditions on the behavior of other players are met.
It's complicated, and it has performance impact, but some of the ideas may be useful, particularly to peer to peer games.
9) I think a good way to make harder the problem to the crackers is to have the only authoritative copies of the game state in your servers,
only sending to and receiving updates from the clients,
that way you can embed in the communication protocol itself client validation (that it hasn't been cracked and thus the detection rules are still in place).
That, and actively monitoring for new weird behavior found might get you close to where you want to be.
Realtime FPS related, less relevance to us:
Client-Server: How to prevent cheating in our (multiplayer) games?
linked: How to secure client-side anti-cheat
Automation: Protection against automation
Trusting clients, Howto take latency differences into consideration when verifying location differences with timestamps (anti-cheating)?
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Do good multiplayer/mmo client<>server games use latency within movement calculations?
Howto take latency differences into consideration when verifying location differences with timestamps (anti-cheating)?
That's about it, hope you've got some tips!
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.