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.
Related
I required to send custom object to server periodically via REST API.i know there are various way available like Bound service,Job scheduler can anyone any guide or example on how to make REST API call from Android's Service or from Job scheduler Periodically furthermore How to handle scenario when service get killed by android then how to restart it for sending data.Any help will be more helpful for Novices like me.
I strongly suggest you to take a look at :https://developer.android.com/topic/performance/scheduling.html Firebase job dispatcher you can schedule your task as your requirement and take a look at this example:https://github.com/firebase/firebase-jobdispatcher-android#user-content-firebase-jobdispatcher-
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.
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.
I'm a beginner in android development and I'm trying to implement an android udp client, which connects to a java server and sends/receives some packets from it.In this process it collects some data (like round-trip delay etc), which is used to measure the QoS of that particular network. I have tried implementing the connection and sending/receiving data using Java Threads, but the application crashes, and hangs if i try to use more than 2 threads. So I'm looking for alternatives. While going through this site as well as some other links I found that in android multiple threads can be implemented using AsyncTask, Handler etc. Also I found that the Service class also helps to run a background service in an app. Please suggest which approach among these would be the best to achieve my purpose.
Thanks in advance.
You can use AasyncTask to do this and as you mentioned service may be useful too, where u can let your application do whatever it wants in background , if user needs to use application by its interface then AsyncTask must be used to avoid Crashing
There is not one right answer that can be applied as a broad stroke to how to do Android multi-threading. There are a few different ways to approach it based on what your specific needs are.
Any long running, blocking call, in Android will result in the application crashing.
The most common solution is to use an AsyncTask though. For example, when I want to make a call out to a web API endpoint for some XML data within an Activity I would in this case use an AsyncTask and kick off the calls from within doInBackground.
This is not an appropriate solution though if the wait time is longer, or possibly an unknown wait time. Or in a situation where there will always be waiting such as a message queuing service. In this type of situation it may be best to write a separate app based on extending the Service class. Then you can send/receive notifications to/from the service from your primary application in a similar manner to how you would communicate with a web service.
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.