i have a question in android documentation it is mentioned that android process can communicate using local sockets. does it mean that two applications with different user id can communicate using local sockets and by that "bypass" the sandbox?
It is indeed possible to do IPC using local sockets on Android, see LocalSocketServer and LocalSocket classes. These translate to UNIX sockets in the abstract namespace.
A word of warning though: Samsung has started restricting local socket use in certain cases through SELinux in their latest firmwares (unfortunately they do not use the same policies as AOSP). I'm not completely clear on the details, but I have seen instances where SELinux blocked the local socket from connecting on these firmwares. Probably depends on the SELinux context of the different processes trying to use the local socket not matching. Be sure to test that if you end up going this route.
Related
Android SDK provides LocalSocket objects for IPC over Unix Domain Sockets, but does so using Linux abstract namespaces. As such, any process can bind to the server socket, where standard Unix sockets generally require read/write permission to access the sockets file descriptor. I can see many vulnerabilities that can arise from this and was wondering what strategies are used to prevent access from unintended sources as well as means of securing data over the sockets.
Please note that the question is specifically about LocalSockets. Using other Android IPC mechanisms might solve the problem of unwanted access but sadly are not an option in my case. However, passing some form of credentials over such mechanisms can be possible if it would secure the LocalSocket.
I need idea to create a POS solution for multiple counters on a shop in android which will be accessing a single database that can be in any of APK installed on the network or the stand alone SQLite Database.
My Idea is to have a application which holds db and the other application should access that DB.
Is it possible in Android? Please suggest the best possible solution.
Thanks.
SQLite is not intended to be used as a client-server database. It is simply not built for highly concurrent operations. SQLite works well in simpler scenarios as stated here. So, you would probably need a dedicated database server such as MySQL or Oracle that is hosted separately in the network.
If you really wanted to do this, you're going to have to handle any concurrency behaviours yourself.
However, your best bet is to do exactly what you've said:
One (master) device holds the database. It accepts signals from the other devices, and allows them to (potentially) query (or alter) the database's contents.
In order to do so, you'll need to handle:
Some means by which the devices will discover the master device. In Android 4.1 there is a Network Service Discovery API for this: http://developer.android.com/training/connect-devices-wirelessly/nsd.html The master device would advertise the service to the others.
The devices might be able to use this Peer-to-Peer API to communicate: http://developer.android.com/training/connect-devices-wirelessly/wifi-direct.html
Once you've established a connection, you'll also need to create a vocabulary of commands which the clients can send to the master device, and a means of dispatching those requests.
This specific case does seem like it might be better suited to having a "real PC" acting as the hub with a more robust application stack (e.g. Postgres or even MySQL, more options for network server tools and administration, faster/more storage options, et al.)
I have a development board for Android. I want to send data serially through the available com port through an app. Is this possible? If so can anyone show how it is done? Am searching for a week but couldn't find anything proper. Thanks in advance.
First you must make sure the serial port hardware is functional and an appropriate linux kernel driver is linked or loaded as a module - this would be the same as for any other embedded linux, and you probably want to test it at this point with a command line tool or test program.
Then you need to make it accessable to applications. There are, broadly, three ways of doing this.
You could make the serial port's device file available to all users. This is simple, but it's up to you to decide if it could be a problem for arbitrary apps to have full access to the serial port.
You could create a new unix group and a corresponding Android permission, set the package manager to assign membership in the group based on the permission, and assign the device file to that group. That's how things like writing to the sdcard are handled.
You could leave access to the serial port restricted and create a privileged daemon which will manage the serial port and perform communications on behalf of android applications which contact it through some means of supported IPC, such as Binder, unix sockets, etc. Likely (at least if using Binder) you will have this require the client application to hold an Android permission which you create for serial port access. This would vaguely resemble how things like sending SMS messages work.
The first two methods would let (at least ndk code in) client applications use the normal posix serial APIs linux programmers would be familiar with. The third method would present the serial port as an Android style communication resource.
Before you write any code, do some web searching. I'd be very surprised if this problem hasn't already been solved several times.
The current version of android supports multiple APNs but does not support multiple active PDP contexts. Why had Android choose not to go down this route? And is it planned in future releases of the android platform?
The background to my question is that my application needs to communicate over a special APN. But when I do this I lose connectivity for all other running connected applications on my device.
Does anyone have a cleaner approach to solving this issue?
My suggestion, why Android does not support multiple active PDP contexts is that Android is based on *nix, and networking is based on classic sockets. If take looks sockets API, there's no PDP contexts.
Solving the issue.
At first one may ask himself: why do he need to send data through special APN. Special APN usually is used to connect to "Private Garden" networks, usually, corporate LAN. Other words, APN is kind of VPN, but in terms of GSM technology. Why one like to use VPN? In many cases, to protect data while transferring.
The APN or VPN is not the only solution for such purposes. You can use SSL: it will ensure that data is encrypted and remote host is not faked. And when using HTTP over SSL, ability to delivery data is much higher because access to the Internet from many networks is provided by proxy server.
Using multiple PDP-context cannot be compared simply to VPN. A PDP context can also be use to request better QoS from the network in the case of a voice application for example.
As far as I know, this is still not supported by Android nor by IOS, except when it comes to VoLTE and MMS where both those services run natively on distinct APNs.
Just a quick question as Google isn't throwing up much.
Is it possible to create a VPN connection using native code in
Android?
And if so does the VPN offer support for keep alives?
I believe it would be more of a permissions issue than of an exposed or not exposed issue. Most VPN connections would need you to modify and access the network filtering calls of your kernel. Since your app should really be operating in it's own sandbox this is something I would doubt is exposed by default (to apps at least) since you would essentially be modifying the way the entire OS routes network traffic. For the same reason that in order to modify iptables in the OS, it needs to be rooted so that your app can actually alter such things. At that point I would assume the connection would be made similar to any other vpn connection in any other linux os (via an ipsec daemon or some proxy dameon that you create), but the calling entity would need the actual access level necessary to complete the call to the kernel.
Rooting of the device is needed for creating a VPN connection. We need access to /data/misc/keystore and /data/misc/vpn/profiles in our programm.