I have made a service written in c that runs on the Android operating system as a core service. I have a few Android apps which communicate with this service via a socket connection (Java -> C).

My issue is that anyone can open a connection to my service if they know which port it is using. The applications have no credentials and just run in the Android sandbox.

What methods can I use to at least try and prevent bad app from accessing this service? as its on local host ssl does not seem relevant?

Both apps are compiled so I could share a secret key between them, but the Android apps could be decompiled.

How can you normally secure client/server connections on the same machine?

  • Normally you would only expose data required by your application to be output on the socket. I don't think you can protect against reverse-engineering further than that.
    – Cthulhu
    Aug 13, 2015 at 12:55
  • "Core service" isn't Android jargon (it seems to be iOS?); is it an application running as a Service (developer.android.com/guide/components/services.html) or did you root the device, and are running it below the application layer? (source.android.com/devices/tech/security/index.html)
    – mfsiega
    Aug 13, 2015 at 14:10
  • Yes it is running from system/bin, I am working with a custom version of AOSP.. so have full root etc. The service is running as it's own process outside of Android.
    – Lunar
    Aug 13, 2015 at 14:17
  • I don't know much about how Android apps work after they are installed. However on Windows I'd say: "Sign your apps (.exe), let the service check the signature and if the process launched from a valid app, let it access your service". This may help solving your problem.
    – SEJPM
    Aug 13, 2015 at 14:42

2 Answers 2


This feels like an instance of the XY Problem.

The short answer is:

In general, this is how you provide information from an app, and then control access to that information.

The longer answer:

You're using the socket to communicate information from your Service to other applications, but this isn't really the "Android-y" way of doing things. Android has a system for inter-process communication using something called Intents. That's getting a bit away from the security-specific question though, so if you're hung up on the Android docs, feel free to ask on StackOverflow!

The upshot is that this system of Intents and Permissions is Android's tool for limiting app access. Note that this differs from the traditional desktop model (which is based on users, rather than applications), because mobile development is aimed at a single-user use case.

  • While everything said here is true, I believe that the OP is not using a Service but they have written a C program that has been built for his device and installed. This program then interfaces with an Android Application.
    – RoraΖ
    Aug 13, 2015 at 14:59
  • It's true that OP has not written a service, but that's how the Android security model works. There's no reason the application can't implement the same interface; otherwise, it may as well throw out the whole "Android" component, and treat it as standard Linux.
    – mfsiega
    Aug 13, 2015 at 15:08
  • 1
    Yeah this is totally bypasses the Android security measures that are in place. This is a temporary solution and was just interested in how this could be handled.
    – Lunar
    Aug 13, 2015 at 15:18

From my reading of the book Embedded Android it sounds like local sockets are commonly used in Android internally to provide hardware services, so this architecture is not totally out of the ordinary for Android. Local sockets take the permission of their containing directory on Linux:

In the Linux implementation, sockets which are visible in the filesystem honor the permissions of the directory they are in. Their owner, group, and permissions can be changed. Creation of a new socket will fail if the process does not have write and search (execute) permission on the directory the socket is created in. Connecting to the socket object requires read/write permission.

This behavior differs from many BSD-derived systems which ignore permissions for UNIX domain sockets. Portable programs should not rely on this feature for security.

See http://man7.org/linux/man-pages/man7/unix.7.html

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .