Android ipc LocalSocket vs Binder (AIDL) - android

I want every app to be able to send data to my service. Therefore I need inter process communication. Every page I can find proposes to use Messenger, AIDL or Intents (BroadcastReceiver). So far what I could figure out by building some test apps is that BroadcastReceiver is extremely slow and messages can get lost without notification if sending with multiple threads inside while(true) loop. AIDL and Messenger are not only complicated to implement (service is needed, binder,...) but can provide strange behavior for example when sending with multiple threads resulting in RemoteException (!!! FAILED BINDER TRANSACTION !!! ) with AIDL just when using oneway keyword. I want to ensure that delivery is guaranteed. Is there even a reason to use oneway when delivery should be guaranteed?
Nevertheless, LocalSocket seems to be extremely easy to use (no need for a service, works just like java socket). Client apps could just open a LocalSocket, connect to the provided address and then while(true) outputstream.writeObject();
Are there any downsides when using LocalSocket because the android developer page says "Some apps attempt to implement IPC using traditional Linux techniques such as network sockets and shared files. We strongly encourage you to instead use Android system functionality for IPC" but does not further comment on this

Are there any downsides when using LocalSocket
There is no security at the framework level for LocalSocket. While you may "want every app to be able to send data to my service", the user may not, which is why standard IPC can be protected by permissions.
startService() and bindService() will cause an instance of your service to be created, even starting a process for you, if needed to handle the request. Your service will not be running all of the time. So, you need startService() or bindService() anyway.

AIDL: Using AIDL is necessary only if you allow clients from different applications to access your service for IPC and want to handle multithreading in your service.
Binder: If you do not need to perform concurrent IPC across different applications, you should create your interface by implementing a Binder.
Messenger: If you want to perform IPC, but do not need to handle multithreading, implement your interface using a Messenger.

Related

Why Binders(used for IPC) even when activity and services are in the same process

Binders are used for Inter(not intra) Process Communication/Remote Method Invocation so why/how the communication between Activity and Service is possible via binders where there are no different processes involvement.
When the very first component of an app is initialized a request to the kernal is triggeres (I think via ActivityManagerService(Native)-AMS > AMN) (running in system_process) for a new process fork if no corresponding process exists. Once the process is created then any other component (say a Service) belongs to the same process unless specified. Now this service wants to communicate to an Activity of the same process. Then why IBinder is one of the option?
Doesn't that violate the underlying principle on which Binders are created?
Interprocess communication is done by writing data to some source such as a socket or pipe, and another process reading it. There's no reason that the same process can't read and write though- it's less efficient than other means of passing data within a process, but it still works.
As for why would you use it in the same process- the alternative would be for Android to have two ways of communicating with services, one way for if they're the same process, and one way for it they aren't. That would complicate things for the framework for minimal gain. It would greatly complicate things for Services where the client may or may not be in the same process (say a service that is used by both the client app and other apps by the same company). So they just use the same method for both.
Binders are intended to be a construct of an IPC - this is true but, if used in the same process to communicate between an Activity and a Service, there is no performance cost, i.e, it is converted into a direct call instead of an RPC.
Don't assume that Binders will only be used for IPC but it is a general purpose communication mechanism in Android.
You won't find this documented normally anywhere. I found it in one of the discussion between Commonsware and Dianne Hackborne(designer of the binder concept in the Android team).

What's the best way to implement TCP client in Android

I need to implement some async client in android app for communication with external device. I need this client to start connection with specified socket on different thread and then implement some methods which will be sending data to external device, all this methods need to be asynchronous. What is more I need to have guarentee that Android won't kill my process.
This client needs to be working w Dependency Injection. I would like to create single instance of this client being injected and used across many activities.
What I took into consideration is:
AsyncTask - heard that it is for only short tasks
Thread - I am struggling with implementing other methods despite run which will be asnychronous and able to be called
Service - I can't make it asynchronous
ServiceIntent - I am not sure if it is the best pick for implemeneting async methods.
I need your suggestions which way would be best with simple explanation why.

How to write Android service in C++

I have Google source code and want to write one Android Service in lower layer similar to how Android provides for App and Frameworks layer.
Is it possible?
If yes, I want to access this native service in my app though IMyService.Stub.asInterface.
Obviously my that service should be be running in different process and services to be provided by my native service should expose AIDL or something similar.
Of course you can.
First you must define you own protocol, like the message definitions.
Then you implement your server side, register it with service manager, and waiting for the binder calls.
Your client could get the service handle from the service manager and then send binder call to the server.
You can refer to the media_server and mediaplayer source code in AOSP.

Example of AIDL use

to understand the AIDL in android, i want one real life example, means the at what scenario of development we need to use AIDL.
by reading the Android Docs ... It puts me in confusion and so many question, so it is hard to read whole doc for me, can anyone help me
is it for communicating with outside the phone.
or to communicating with different apps, (why we need to communicate with other apps)
what kind of service they are talking in docs
AIDL is used for Binder. Binder is a mechanism to do RPC calls on/from an Android Service.
When to use AIDL? When you need a Service. When do you need a Service? If you want to share data and control something in another application, you need a service using AIDL as an interface. (A Content Provider is used when sharing data only).
Services can be used within your application as the model roll in the MVC-pattern.
AIDL is Android Interface Definition Language. This basically allows you to do IPC calls.
Use: There are situations where one process would need to talk to other to obtain certain information.
Example: Process A needs info of Call status to determine whether it needs to change Call Type (for example Audio to Video Call or Vice-versa). You may get call status from certain listeners but to change Call type from Audio to Video, Process A needs a hook to change. This "Hook" or way of changing calls is typically part of Telephony Classes which are part of Telephony Process. So in order to obtain such an information from Telephony process, One may write a telephony service (which runs as a part of android telephony process), which will allow you to query or change call type. Since Process A(Client) here is using this remote Service which communicates with Telephony process to alter call type, it needs to have an interface to talk to service. Since Telephony service is the provider, and Process A (client) is the user, they both need to agree on an interface (protocol) they can understand and adhere to. Such an interface is AIDL, which allows you to talk (via a remote service) to Telephony process and get some work done.
Simply put in laymen terms, AIDL is an "agreement" Client gets, which tells it about how to talk to service. Service itself will have a copy of that agreement(since it published for it's clients). Service will then implement details on how it handles once a request arrives or say when someone is talking to it
So process A requests to change call via Service, Service gets the request, it talks to telephony process(since it's part of it) and changes call to video.
An important point to note is, AIDL is only necessary for multithreading environment. You could do away with Binders if you don't need to deal with multithreaded arch.
Another real world example is Google Play License is using AIDL.
I have the same thinking about an example of AIDL, it's very difficult to find an idea to make an example app which uses AIDL. Then I have an idea about it create a LocalLogServerApp. Maybe it can not become a production app but it still shows some value in using AIDL
The main function of this app is
Receive the local log from other local apps (another app need to implement AIDL to send log)
Save the log to datastore
Display the logs
Maybe do something with the local log (eg: search, delete)
Maybe notify developer when error log happened
The benefit of this app
The local log can use when you have some very strange issues which sometimes happened in a few moments and in some specific device. In this case, common Log won't help, debug won't help, Firebase Log may help but Firebase receive log from multiple device.
Reusable, many apps can use it with less code
Hope you find this idea helpful to find another better AIDL example
https://github.com/PhanVanLinh/AndroidLocalLogServer
https://github.com/PhanVanLinh/AndroidLocalLogClientTest
1 - is it for communicating with outside the phone.
Its communicating with outside the app.
2 - or to communicating with different apps, (why we need to communicate with other apps)
As #GodOnScooter mentioned, when your app communicates with telephony service which is actually an other part.
3 - what kind of service they are talking in docs?
This is a service which runs in different process of a system, To bind to this service you need IPC(inter process communication), AIDL is used to implement this.

Service as an API in Android

I have a service which is is responsible to send requests and take responses over network. I am planning to use it also as an API . So other applications on device can bind to it, send requests and take responses.
1-Is this a proper way to provide an API to other apps?
2-Should I use a Messenger or AIDL ? Messenger seems simpler, but network operation can block a request, so using a single queue for requests can be problematic !
3-Is it a good idea to use same service for both network operations and as an API for other apps ? I can create a separate service for API which binds to network service, but this will bring extra message overhead and code complexity !
According to me you need to create a service separately that can be used by both of your applications. And you need to use BroadcastReceiver to start your service as and when android system boots. So that any of your application can use that service.
Creating a simple service is the best idea. You need AIDL for that so that you can transfer the data between service and application with ease.

Categories

Resources