Database Users

uitilizing power of root

Hello all i have a questio?
Does anyone know how do i get a service to accuire root and prevent any taskmanager apps from killing it i dev andriod app but dont know about root and all
I dont want to start another service to monitor each other and start the other in case one is killed

sak-venom1997 said:
Hello all i have a questio?
Does anyone know how do i get a service to accuire root and prevent any taskmanager apps from killing it i dev andriod app but dont know about root and all
I dont want to start another service to monitor each other and start the other in case one is killed
Click to expand...
Click to collapse
If I want to use root i simply do something like that
Code:
Runtime.getRuntime().exec(new String []{"su","-c",yourcommand});
As for unkillable service maybe you can set it foreground, but I am not sure it works though:
Code:
Notification notification=new Notification(0,null,System.currentTimeMillis());
notification.flags |= Notification.FLAG_NO_CLEAR;
startForeground(2, notification);

DoR2 said:
If I want to use root i simply do something like that
Code:
Runtime.getRuntime().exec(new String []{"su","-c",yourcommand});
As for unkillable service maybe you can set it foreground, but I am not sure it works though:
Code:
Notification notification=new Notification(0,null,System.currentTimeMillis());
notification.flags |= Notification.FLAG_NO_CLEAR;
startForeground(2, notification);
Click to expand...
Click to collapse
Ya I've tried this android system won't kill but taskmanager can easily kill it and for my application it is essential that this service is not stopped as it monitors information from sensors
The root part
This much I also know what command would I give
Sent from my GT-S5302 using Tapatalk 2
Hit Thanx Button if i helped you!

sak-venom1997 said:
Ya I've tried this android system won't kill but taskmanager can easily kill it and for my application it is essential that this service is not stopped as it monitors information from sensors
The root part
This much I also know what command would I give
Sent from my GT-S5302 using Tapatalk 2
Hit Thanx Button if i helped you!
Click to expand...
Click to collapse
I don't think thats possible. I don't think you can prevent other apps from killing your service.
You could however try to restart service from its own onDestroy() method.
This is just theoretical but this way when something stops service it should re-start itself.
Again I have no idea if this is possible, it's just an idea.
Root task managers that actually kill process(using kill or killall )are completely different matter.
Sent from my Evo 3D GSM using Tapatalk 2

Antivirus services don't get killed unless used a root taskmanager
Sent from my GT-S5302 using Tapatalk 2
Hit Thanx Button if i helped you!

when a service is started with START_STICKY then it will automatically be re-started by the Android system. That's why auto-task killers are a horrible idea, because they kill your service over and over again, and drain your battery easily.
http://developer.android.com/reference/android/app/Service.html#START_STICKY
Unfortunately there's no solution to stop task killers.

You mean there's no way out
Its important for scenarios like mine I'm dumping heavy data to a sql or mysql data base on the cloud that is done only in onDestory() method if done else where would make low memory devices crawl and if a taskmanager kills it I lose all data stored in ram even if it's restarted by the system
Sent from my GT-S5302 using Tapatalk 2
Hit Thanx Button if i helped you!

sak-venom1997 said:
You mean there's no way out
Its important for scenarios like mine I'm dumping heavy data to a sql or mysql data base on the cloud that is done only in onDestory() method if done else where would make low memory devices crawl and if a taskmanager kills it I lose all data stored in ram even if it's restarted by the system
Sent from my GT-S5302 using Tapatalk 2
Hit Thanx Button if i helped you!
Click to expand...
Click to collapse
Maybe you can make something like that:
YourService.java
Code:
@Override
public void onDestroy() {
startService(new Intent(context,Dummy.class));
}
Dummy.java
Code:
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
startService(new Intent(context,YourService.class));
stopSelf();
return super.onStartCommand(intent, flags, startId);
}
I don't know if it is the best way, but I think it will work

DoR2 said:
Maybe you can make something like that:
YourService.java
Code:
@Override
public void onDestroy() {
startService(new Intent(context,Dummy.class));
}
Dummy.java
Code:
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
startService(new Intent(context,YourService.class));
stopSelf();
return super.onStartCommand(intent, flags, startId);
}
I don't know if it is the best way, but I think it will work
Click to expand...
Click to collapse
Hmm when taskmanager kills the service onDestory us not called that's my problem.
Sent from my GT-S5302 using Tapatalk 2
Hit Thanx Button if i helped you!

You should never do important things in OnDestroy as there's no guarantee that the system is calling it, even if no task killers are used. I guess you should rethink your design and push the data earlier, cache it locally, etc.

ramdroid77 said:
You should never do important things in OnDestroy as there's no guarantee that the system is calling it, even if no task killers are used. I guess you should rethink your design and push the data earlier, cache it locally, etc.
Click to expand...
Click to collapse
System never kills a service it only kills activities Google says
activities like dumping data to a sql database should be done in onDestory() method
Well that wasn't the topic I want to prevent taskmanager apps (non root) from killing my service
Sent from my GT-S5302 using Tapatalk 2
Hit Thanx Button if i helped you!

sak-venom1997 said:
System never kills a service it only kills activities Google says
activities like dumping data to a sql database should be done in onDestory() method
Well that wasn't the topic I want to prevent taskmanager apps (non root) from killing my service
Sent from my GT-S5302 using Tapatalk 2
Hit Thanx Button if i helped you!
Click to expand...
Click to collapse
I don't know what your service is exactly doing but permanent foreground services should only be used if you really need them on all the time, e.g. during music playback. According to the docs non-foreground services (like you should normally use) might still get killed by the system after some time...
Otherwise, what happens if the user force stops your application? Or if the phone is shutting down? You shouldn't do any life-depending things in onDestroy, you only want to release allocated resources. Uploading data to the cloud in onDestroy seems plain wrong to me!
Yes, auto-kill task managers are bad, but I think that's not the only problem here

ramdroid77 said:
I don't know what your service is exactly doing but permanent foreground services should only be used if you really need them on all the time, e.g. during music playback. According to the docs non-foreground services (like you should normally use) might still get killed by the system after some time...
Otherwise, what happens if the user force stops your application? Or if the phone is shutting down? You shouldn't do any life-depending things in onDestroy, you only want to release allocated resources. Uploading data to the cloud in onDestroy seems plain wrong to me!
Yes, auto-kill task managers are bad, but I think that's not the only problem here
Click to expand...
Click to collapse
Then where should I write to the database if on in onDestory
And if you force stop the app using Android settings the on destroy is called
Only if it's done with a taskmanager it won't
What my service does it to track the network sites visited by the user in order to bill them accordingly after all we won't sponsor data usage other than official use in our country isp's are not permitted to release info about user other than to the government so if a user kills it with a taskmanager he's off the radar and if database is stored locally the user might tamper with the data
If i write data to sql server periodically the system would crawl as I'd be first compressing it to save data and it's a huge file I will hold data from other in house apps too
Sent from my GT-S5302 using Tapatalk 2
Hit Thanx Button if i helped you!

If you are looking for a way of writing a root app, try this library: http://code.google.com/p/roottools/
At the beginning I tried it without that lib and it worked. However, you will need to keep your shell open if you do not want it to ask for permission again everytime you need to execute a command. And this needs some code. That is why I use roottools now. It is much easier and we can concentrate on our app instead of getting these background things to work.
If your app needs to execute commands not very often, you can ask for the permission every time, but it slows down your application for many commands and there will be annoying Toast messages every time. The advantage would be not having to put some other people into the credits.
That is my experience. I hope that it is helpful.

Well my best idea is to let the user know that your app needs to run the service, so he shouldn't kill it with any task manager. I use root with this code:
Code:
try {
Process proc = Runtime.getRuntime().exec("su");
DataOutputStream DOS = new DataOutputStream(proc.getOutputStream());
//write what you want to send to it here. Example:
DOS.writeBytes("ls /data/data/");
DOS.flush();
DOS.close();
proc.waitFor();
} catch (IOException e1) {
e1.printStackTrace();
} catch (InterruptedException e1) {
e1.printStackTrace();
}

Rotary Heart said:
Well my best idea is to let the user know that your app needs to run the service, so he shouldn't kill it with any task manager. I use root with this code:
Code:
try {
Process proc = Runtime.getRuntime().exec("su");
DataOutputStream DOS = new DataOutputStream(proc.getOutputStream());
//write what you want to send to it here. Example:
DOS.writeBytes("ls /data/data/");
DOS.flush();
DOS.close();
proc.waitFor();
} catch (IOException e1) {
e1.printStackTrace();
} catch (InterruptedException e1) {
e1.printStackTrace();
}
Click to expand...
Click to collapse
At first I did it that way, too. One bad thing with this solution is that everytime you execute a command it will ask for permission again and there will be a new Toast message. If your app has to execute commands multiple times, keeping the shell open is more performant. That is the advantage of roottools.

[GUIDE] Downloading and displaying a web page in a WebView

Hello everyone,
For a while now, I had been trying to figure out how to download and display a web page's HTML file in a WebView. Why, you ask? Well, because this app is probably going to be used offline. More importantly, it is just another thing that you can learn to do and have in your skillset.
A long time passed from my initial Googling efforts, and I forgot about this for a bit. After a couple of weeks, I picked this up again and got it to work correctly.
Since so many different tutorials and explanations exist, I wanted to give a clear and detailed explanation, as well as try to help anyone who attempts to implement this.
So, here we go!
Step 1:
Of course, you need to have specified a button that executes an action.
I chose to have an ActionBar item that checks whether or not the SD card is accessible to your app. It also calls the ASyncTask that downloads the file.
To do this, I used:
Code:
case R.id.save: // Save item
if (Environment.getExternalStorageState().equals(
Environment.MEDIA_MOUNTED)) {
// execute this when the downloader must be fired
DownloadFile downloadFile = new DownloadFile();
downloadFile.execute(downloadUrl);
} else {
Toast.makeText(this, "Can't write to internal storage",
Toast.LENGTH_LONG).show();
}
This checks whether the internal SD card is mounted. If it is, it starts a new download, and gets the file at the webpage with the URL downloadUrl.
If the SD card cannot be accessed, it will show so in a Toast.
Step 2:
For part 2, we will set up the actual download of the file. This is done by an ASyncTask. You can, should you want to, show a progress indicator. However, since I only download small files, I have chosen not to do so.
To download the file:
Code:
private class DownloadFile extends AsyncTask<String, Integer, String> {
[user=439709]@override[/user]
protected String doInBackground(String... sUrl) {
try {
URL url = new URL(downloadUrl);
URLConnection connection = url.openConnection();
connection.connect();
// download the file
InputStream input = new BufferedInputStream(url.openStream());
OutputStream output = new FileOutputStream(Environment
.getExternalStorageDirectory().getPath()
+ "/data/"
+ getPackageName() + "/webpage.html");
byte data[] = new byte[1024];
int count;
try {
while ((count = input.read(data)) != -1)
output.write(data, 0, count);
} catch (IOException e) {
e.printStackTrace();
}
output.flush();
output.close();
input.close();
Toast.makeText(MyWebView.this, "File downloaded", Toast.LENGTH_SHORT).show();
} catch (IOException ioe) {
ioe.printStackTrace();
}
return null;
}
}
So, what do we see here?
Firstly, make a new ASyncTask class. This has a number of standard methods, including one that executes everything in it in a separate background thread: doInBackground.
Now, you want to open a new connection to the site's server, with the downloadUrl, and connect to it. This is easily done with a standard class called URLConnection.
To download and write the file to a specific location on the SD, open a new InputStream. This will download the file from the downloadURL.
Once you have done that, make a new OutputStream to open a connection to the internal storage. In my case, I am writing to what would be /sdcard/data/<mypackagename>/webpage.html, because every new download overwrites the file that was downloaded last.
To actually write the file to the SD, byte by byte, create a new bit array and a counter. As long as there's still data to be read from the file, write the data.
As the last step here, you want to clean and close your in- and output streams, etc. Just do this with the standard commands.
Then show the user a short Toast, to let them know the file has been downloaded correctly.
Should an IOException occur, I print the stack trace.
It would be good to notify the user of the error, though you shouldn't do it in an obtrusive way.
Step 3:
Now, we're almost done. I know you want to know what else is to be done, since the hard parts have been coded already.
This is true, but placement is very important. You want to have the ASyncTask placed correctly in your code.
So, where does it go? Just put it at the bottom of your original class. Subclasses of ASyncTask are usually inside the main Activity class. This ensures you can still easily modify the UI thread (foreground thread, which we use for the Toasts).
Everything should now work, just code a nice little Button (or something else) that triggers the download.
Step 4:
Now, we want to display this web page in the WebView. You should have the HTML file downloaded locally, after which it is quite easy to get it to show in a WebView. This does not automatically show images and other external files! However, I think that kind of defeats the purpose, which is saving on internet costs.
If anyone wants to know how I would do this, please ask in this thread!
To open and display the downloaded HTML in your WebView:
Code:
mWebView.loadUrl("file://"
+ Environment
.getExternalStorageDirectory()
.getPath() + "/data/"
+ getPackageName()
+ "/webpage.html");
Very easy, as I said. Just add file:// to the front of your downloaded file's location, and the WebView will do all the work.
You should make sure, though, that the app doesn't have an Internet connection available. I check this when the WebView starts, but that's material for another guide.
I hope this tutorial helped you. Should you still have questions or see something wrong, please do tell me!
Regards,
bassie1995

Cool guide.
Thanks.

nikwen said:
Cool guide.
Thanks.
Click to expand...
Click to collapse
I might have killed your 444 thanks count .

Is there any advantage of using an URLConnection instead of HttpGet?
I usually do this using a HttpGet object which I execute using a HttpClient.

nikwen said:
Is there any advantage of using an URLConnection instead of HttpGet?
I usually do this using a HttpGet object which I execute using a HttpClient.
Click to expand...
Click to collapse
Honestly, I wouldn't know right now. I'll go and look it up, but have some things to do for school :-\
Sent from my Nexus 7 using Tapatalk HD

bassie1995 said:
Honestly, I wouldn't know right now. I'll go and look it up, but have some things to do for school :-\
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
Ok, I will look it up later and tell you.

nikwen said:
Ok, I will look it up later and tell you.
Click to expand...
Click to collapse
Didn't find too much quickly, but this might help?
http://www.tbray.org/ongoing/When/201x/2012/01/17/HttpURLConnection
Sent from my Nexus 7 using Tapatalk HD

bassie1995 said:
Didn't find too much quickly, but this might help?
http://www.tbray.org/ongoing/When/201x/2012/01/17/HttpURLConnection
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
I will search for it later.
I do not use a HttpURLConnection. I can post my code later. (It is working.)

nikwen said:
I will search for it later.
I do not use a HttpURLConnection. I can post my code later. (It is working.)
Click to expand...
Click to collapse
I'd like to see .
Sent from my GT-I9300 using Tapatalk 4 Beta

bassie1995 said:
I'd like to see .
Sent from my GT-I9300 using Tapatalk 4 Beta
Click to expand...
Click to collapse
That is my code:
Code:
try {
HttpParams params = new BasicHttpParams();
HttpConnectionParams.setConnectionTimeout(params, 4000);
HttpConnectionParams.setSoTimeout(params, 5000);
HttpClient client = new DefaultHttpClient(params);
HttpGet request = new HttpGet("www.google.com");
HttpResponse response = client.execute(request);
InputStream is = response.getEntity().getContent();
BufferedReader reader = new BufferedReader(new InputStreamReader(is));
String line = null;
while((line = reader.readLine()) != null) {
//do something with the line
}
is.close();
} catch (Exception e) {
e.printStackTrace();
}
My sources were http://stackoverflow.com/questions/...-source-of-a-page-from-a-html-link-in-android and http://stackoverflow.com/questions/6503574/how-to-get-html-source-code-from-url-in-android

Sweet guide!
Sent from my GT-S5830M using Tapatalk 2

This thread has evrything i had been looking for ....
Thanks a lot
Sent from my GT-S5360 using xda app-developers app

are you still open for questions ? nice thread btw

Thank you, this helped me so much!

Hello, very nice article provided. I want to open html file from sdcard path like "file:///storage/emulated/0/hensler_bone_press/index.html"
How can we achieve this using webview ?

Just stumbled upon this again...
Pannam said:
are you still open for questions ? nice thread btw
Click to expand...
Click to collapse
Did you get an answer? I assume so, 2 years later?
hardikjoshi8689 said:
Hello, very nice article provided. I want to open html file from sdcard path like "file:///storage/emulated/0/hensler_bone_press/index.html"
How can we achieve this using webview ?
Click to expand...
Click to collapse
Same here, have you got this working?
I'm not working with Android, especially not WebView, right now, but I suspect that you use the line in the last step to normally just load a URL.
Instead of supplying the URL wherever you tell the WebView what page to load, you can probably do what I did in the OP and specify your file path. Be sure to use the correct methods to get the path to your file instead of hard-coding it!

[GUIDE] Implement your own lockscreen-like music controls

Beginner developers, beware! This guide isn't beginner-friendly at all and it's targeted at developers who have some knowledge about Android development.
Or you can use my new library - Remote Metadata Provider, it's MUCH simplier to use.
0. The Introduction
You guys probably seen my apps - Floating Music Widget and Android Control Center.
They both share one feature - good music player integration. They can show you metadata and Floating Music Widget even shows album art. While some players provide API for external music controls(like PowerAmp), the others just somehow integrate with lockscreen. How? Sit down, get a cup of tea, and listen to me.
With the API Level 14 Google introduced class called RemoteControlClient. Citing Google API Reference:
RemoteControlClient enables exposing information meant to be consumed by remote controls capable of displaying metadata, artwork and media transport control buttons.
Click to expand...
Click to collapse
I won't explain how this works - you may go and read some tutorials around the web, there are plenty of them.
Or check API Reference here.
But. Well, we send metadata and album art. Oh, and on 4.3 we can even send playback position. However...how do we receive it? Well, by some reason, I don't know exactly why, Google has hidden this part of API. Maybe they think it's unsere to let you consume other app data, or maybe they just forgot about it. I've asked them multiple times, why did they hid this part of API, but they just ignored me.
So, by posting this article, I hope to maybe somehow make them change their minds and publish this API after all.
1. Getting started
Please note that this guide won't give you Activity examples, or any other things. It will give you the bare bones of the implementation of your own media controls. It's NOT intended to be used by Android/Java newbies.
PLEASE NOTE THAT IT'S A CLOSED API! IT MAY MALFUNCTION OR NOT WORK AT ALL!
Of course, you will need Eclipse IDE.
Also you will need modified Android build platform with hidden and internal API enabled.
There's an excellent guide on how to do this:
Using internal (com.android.internal) and hidden (@hide) APIs
Read it, do all five steps, then come back here for a read.
Please note that you will need to enable hidden APIs for API Level 18(4.3) and one API from 14 to 17. I recommend doing 17.
So, you've enabled hidden and internal API, hacked your ADT plugin, and you're craving for knowledge? Good.
Now some theory.
When the metadata is sent by RemoteControlClient, it is consumed by object called RemoteControlDisplay.
But the problem is, there's no explicit RemoteControlDisplay class, but there is only AIDL interface called IRemoteControlDisplay.
2. Understanding IRemoteControlDisplay
So, let's check which methods this interface has.
void setCurrentClientId(int clientGeneration, in PendingIntent clientMediaIntent, boolean clearing);
This method is used to connect music player to your RemoteControlDisplay.
First parameter is an internal ID of current player.
Second parameter is PendingIntent which will be used for controlling the playback - this is the "address" where you will send commands like "stop playback", "switch to next", etc.
About third parameter...my guess is that it's used when the RemoteControlDisplay is disconnected from current music player. You don't really ned this one.
For next methods I will explain only useful parameters.
void setPlaybackState(int generationId, int state, long stateChangeTimeMs);
This method is called when playback state has changed. For example, it's called when you pause your music.
"state" is obviously the current state of your music player.
It can be one of the following values:
Rarely used:
RemoteControlClient.PLAYSTATE_ERROR - well, there was some kind of error. Normally, you won't get this one.
RemoteControlClient.PLAYSTATE_BUFFERING - the music is buffering and will start playing very-very soon.
Normally used:
RemoteControlClient.PLAYSTATE_PAUSED - the music is paused
RemoteControlClient.PLAYSTATE_PLAYING - the music is playing.
You can check other PLAYSTATE_ constant in RemoteControlClient API reference.
void setTransportControlFlags(int generationId, int transportControlFlags);
In lockscreen it is used for toggling the widget visibility. I couldn't find any appliance for this method in my apps. Well, it sets flags
void setMetadata(int generationId, in Bundle metadata);
Well, that's obvious. It is called when RemoteControlDisplay have to update current track metadata.
The Bundle which we are receiving containing some metadata.
The keys for them are all in class MediaMetadataRetriever.
So, for example, to extract song title, you have to do it this way:
Code:
String title=metadata.getString(Integer.toString(MediaMetadataRetriever.METADATA_KEY_TITLE));
From my research I've found that this Bundle can have the following entries:
Those are for "String" entries:
MediaMetadataRetriever.METADATA_KEY_ALBUMARTIST
MediaMetadataRetriever.METADATA_KEY_ARTIST
MediaMetadataRetriever.METADATA_KEY_ALBUM
MediaMetadataRetriever.METADATA_KEY_TITLE
And this one is "long":
MediaMetadataRetriever.METADATA_KEY_DURATION
void setArtwork(int generationId, in Bitmap artwork);
This one is way too obvious. It gives you the Bitmap with artwork of current song. If there is no artwork, the "artwork" parameter will be null.
void setAllMetadata(int generationId, in Bundle metadata, in Bitmap artwork);
This call just combines previous two.
3. Implementing IRemoteControlDisplay
Hey, I now know everything about RemoteControlDisplay, I will implement my own in split second.
Code:
public class MyRemoteControlDisplay implements IRemoteControlDisplay
Please note that IT WON'T WORK THIS WAY!
As IRemoteControlDisplay is actually a AIDL interface, we need to somehow handle marshalling and unmarshalling of data. But luckily, we don't need to think about it. There is a class which handles basic IPC operations - IRemoteControlDisplay$Stub. We just need to extend it.
So, the right way to implement your own RemoteControlDisplayClass is:
Code:
public class MyRemoteControlDisplay extends IRemoteControlDisplay.Stub
Then you will have to implement methods of IRemoteControlDisplay. However, now listen to me carefully. Please, don't try to write your own super-cool implementation.
Just copy and paste the following code
Code:
public MyRemoteControlDisplay extends IRemoteControlDisplay.Stub {
static final int MSG_SET_ARTWORK = 104;
static final int MSG_SET_GENERATION_ID = 103;
static final int MSG_SET_METADATA = 101;
static final int MSG_SET_TRANSPORT_CONTROLS = 102;
static final int MSG_UPDATE_STATE = 100;
private WeakReference<Handler> mLocalHandler;
MyRemoteControlDisplay(Handler handler) {
mLocalHandler = new WeakReference<Handler>(handler);
}
public void setAllMetadata(int generationId, Bundle metadata, Bitmap bitmap) {
Handler handler = mLocalHandler.get();
if (handler != null) {
handler.obtainMessage(MSG_SET_METADATA, generationId, 0, metadata).sendToTarget();
handler.obtainMessage(MSG_SET_ARTWORK, generationId, 0, bitmap).sendToTarget();
}
}
public void setArtwork(int generationId, Bitmap bitmap) {
Handler handler = mLocalHandler.get();
if (handler != null) {
handler.obtainMessage(MSG_SET_ARTWORK, generationId, 0, bitmap).sendToTarget();
}
}
public void setCurrentClientId(int clientGeneration, PendingIntent mediaIntent,
boolean clearing) throws RemoteException {
Handler handler = mLocalHandler.get();
if (handler != null) {
handler.obtainMessage(MSG_SET_GENERATION_ID, clientGeneration, (clearing ? 1 : 0), mediaIntent).sendToTarget();
}
}
public void setMetadata(int generationId, Bundle metadata) {
Handler handler = mLocalHandler.get();
if (handler != null) {
handler.obtainMessage(MSG_SET_METADATA, generationId, 0, metadata).sendToTarget();
}
}
public void setPlaybackState(int generationId, int state, long stateChangeTimeMs) {
Handler handler = mLocalHandler.get();
if (handler != null) {
handler.obtainMessage(MSG_UPDATE_STATE, generationId, state).sendToTarget();
}
}
public void setTransportControlFlags(int generationId, int flags) {
Handler handler = mLocalHandler.get();
if (handler != null) {
handler.obtainMessage(MSG_SET_TRANSPORT_CONTROLS, generationId, flags).sendToTarget();
}
}
}
Why we have to implement it this way?
Well, it's because those methods calls arrive asynchronously, so, to correctly process them all, we need a Handler. Then we send messages to this Handler with necessary parameters, and it processes them.
But why use this weird WeakReference? Well, I can't explain it better than Google Developers. Citing the source code comment:
/**
* This class is required to have weak linkage
* because the remote process can hold a strong reference to this binder object and
* we can't predict when it will be GC'd in the remote process. Without this code, it
* would allow a heavyweight object to be held on this side of the binder when there's
* no requirement to run a GC on the other side.
*/
Click to expand...
Click to collapse
Tl;dr it's just a clever usage of memory resources.
So, my congratulations! We've implemented hidden IRemoteControlDisplay interface. But now it doesn't actually do anything.
4. Using our RCD implementation
As you can see, the constructor requires a Handler to be passed to it.
But any Handler just won't do, as we have to process messages.
So, you can't just write
Code:
MyRemoteControlDisplay display=new MyRemoteControlDisplay(new Handler());
Then, let's implement our Handler.
Again, I recommend you to use the following code, as it's doing it's job fine. This is the code used by default lockscreen with slight modifications. You can try and implement your own Handler, but this is strongly discouraged, as it can get glitchy. Don't worry, we'll soon get to the part where you can use your imagination
Code:
private int mClientGeneration;
private PendingIntent mClientIntent;
private Bitmap mArtwork;
public static final int MSG_SET_ARTWORK = 104;
public static final int MSG_SET_GENERATION_ID = 103;
public static final int MSG_SET_METADATA = 101;
public static final int MSG_SET_TRANSPORT_CONTROLS = 102;
public static final int MSG_UPDATE_STATE = 100;
Handler myHandler = new Handler(new Handler.Callback() {
[user=439709]@override[/user]
public boolean handleMessage(Message msg) {
switch (msg.what) {
case MSG_UPDATE_STATE:
//if client generation is correct(our client is still active), we do some stuff to indicate change of playstate
if (mClientGeneration == msg.arg1) updatePlayPauseState(msg.arg2);
break;
//if client generation is correct(our client is still active), we do some stuff to update our metadata
case MSG_SET_METADATA:
if (mClientGeneration == msg.arg1) updateMetadata((Bundle) msg.obj);
break;
case MSG_SET_TRANSPORT_CONTROLS:
break;
//if our client has changed, we update the PendingIntent to control it and save new generation id
case MSG_SET_GENERATION_ID:
mClientGeneration = msg.arg1;
mClientIntent = (PendingIntent) msg.obj;
break;
//if client generation is correct(our client is still active), we do some stuff to update our artwork
//while recycling the old one to reduce memory usage
case MSG_SET_ARTWORK:
if (mClientGeneration == msg.arg1) {
if (mArtwork != null) {
mArtwork.recycle();
}
mArtwork = (Bitmap)msg.obj;
setArtwork(mArtwork);
}
break;
}
return true;
}
});
I think you can probably guess what do we do here, but I'll explain anyway.
updatePlayPauseState(msg.arg2) - it's the method where you actually handle the change of playstate.
msg.arg2 is an Integer(or, more correcly, int), which indicates current play state. Please refer to section 2 to see possible play states. For example, you may do check like this:
Code:
updatePlayState(int state) {
if(state==RemoteControlClient.PLAYSTATE_PLAYING) {
setButtonImage(R.drawable.play);
} else {
setButtonImage(R.drawable.pause);
}
}
setArtwork(mArtwork);
It's pretty obvious, do whatever you like with this bitmap, just remember that it can be null.
updateMetadata((Bundle) msg.obj)
That one isn't very easy to handle. There is a bundle containing all of available metadata. So, you can deal with it as you please(you know how to extract data from Bundle, right?), but here's how I do it(modified Google version):
Code:
private void updateMetadata(Bundle data) {
String artist = getMdString(data, MediaMetadataRetriever.METADATA_KEY_ALBUMARTIST);
//if we failed to get artist, then we should try another field
if(artist==null) {
artist=getMdString(data, MediaMetadataRetriever.METADATA_KEY_ARTIST);
}
if(artist==null) {
//if we still failed to get artist, we will return a string containing "Unknown"
artist=mContext.getResources().getString(R.string.unknown);
}
//same idea for title
String title = getMdString(data, MediaMetadataRetriever.METADATA_KEY_TITLE);
if(title==null) {
title=mContext.getResources().getString(R.string.unknown);
}
//album isn't that necessary, so I just ignore it if it's null
String album=getMdString(data, MediaMetadataRetriever.METADATA_KEY_ALBUM);
if((artist!=null)&&(title!=null)) {
setMetadata(artist, title, album);
}
}
private void updatePlayPauseState(int state) {
mPlayButtonState=state;
mService.setPlayButtonState(state);
}
public void setMetadata(String artist, String title, String album) {
mMetadataArtistTextView.setText(artist);
mMetadataTitleTextView.setText(title);
if(album!=null) {
mMetadataAlbumTextView.setText(album);
} else {
mMetadataAlbumTextView.setText("");
}
}
}
private String getMdString(Bundle data, int id) {
return data.getString(Integer.toString(id));
}
You've got the idea.
Okay. So you've implemented your Handler, and created MyRemoteControlDisplayObject. What's next?
5. Registering and unregistering RemoteControlDisplay
In order for your RemoteControlDisplay to be able to receive metadata and album arts, it has to be registered via AudioManager.
You have to get the instance of AudioManager and then call Audiomanager#registerRemoteControlDisplay().
Code:
MyHandler myHandler=new MyHandler();
MyRemoteControlDisplay remoteDisplay=new MyRemoteControlDisplay(myHandler);
AudioManager manager=((AudioManager)mContext.getSystemService("audio"));
mAudioManager.registerRemoteControlDisplay(remoteDisplay);
So, that's it. You've succesfully registered your display. Now it will receive metadata and album art.
However, that's not all.
When the metadata isn't visible to user, you should unregister your RemoteControlDisplay by using this code:
Code:
audioManager.unregisterRemoteControlDisplay(remoteDisplay);
remoteDisplay=null;
mHandler.removeMessages(MSG_SET_GENERATION_ID);
mHandler.removeMessages(MSG_SET_METADATA);
mHandler.removeMessages(MSG_SET_TRANSPORT_CONTROLS);
mHandler.removeMessages(MSG_UPDATE_STATE);
This way you will unregister your RemoteControlDisplay, destroy it(or, actually, just give it garbage collector), and remove all unprocessed messages. This is the correct way to unregister your RemoteControlDisplay.
Please note! You must register your RemoteControlDisplay every time when the View which displays metadata is shown to the user. This is because 4.2.2 and lower versions support only one RemoteControlDisplay, and if system will decide to register it's own RCD, your RCD will be unregistered automatically.
When you're compiling, you have to compile with 4.2.2 modified library for 4.2.2 and lower, and compile with 4.3 modified library for 4.3. That is very important, because if you'll try to launch 4.2.2 implementation on device running 4.3, it will give you AbstractMethodError.
If you have any question regarding the implementation, please ask here. Don't ask "How do I start Eclipse", or anything like that.
And please, if you use this, at least give me a credit. Finding this out was a really hard job.
To understand how it works, I've used source code from Android GitHub repository:
KeyguardTransportControlView.java
Or donate to me, whatever you like more. However, it would be the best if you give me credit and donate to me

Reserved for Android 4.3 implementation.
So, in 4.3 Google change some IRemoteControlDisplay methods.
1. Implementing IRemoteControlDisplay
Those are:
void setTransportControlFlags(int generationId, int transportControlFlags); is replaced by
void setTransportControlInfo(int generationId, int transportControlFlags, int posCapabilities)
The new parameter - posCapabilities - is indicating whether the RemoteControlClient provides information about playback position. It is a bit mask for those (public, but hidden) constants:
0 - no info about playback position
RemoteControlClient.MEDIA_POSITION_WRITABLE - playback position can be changed
RemoteControlClient.MEDIA_POSITION_READABLE - playback position can be read
void setPlaybackState(int generationId, int state, long stateChangeTimeMs); is replaced by
void setPlaybackState(int generationId, int state, long stateChangeTimeMs, long currentPosMs,float speed);
New parameters:
currentPosMs - current playback position in milliseconds.
If it's positive, it's the current playback position.
Negative values means that the position is unknown.
RemoteControlClient.PLAYBACK_POSITION_INVALID means that position is unknown, like if you're listening to live radio.
RemoteControlClient.PLAYBACK_POSITION_ALWAYS_UNKNOWN - that means the music player doesn't provide current position at all, because it's using legacy API(from 4.2.2).
speed - is the playback speed. 1.0 is normal, 0.5 is slower, 2.0 is 2x faster.
The rest stays the same.
However, the IRemoteControlDisplay implementation in my first post doesn't send this kind of data. So, if you want to send this data to your Handler, you may want to pack it into Bundle and send it as Message.obj.
2. Registering RemoteControlDisplay
Now there are two methods:
registerRemoteControlDisplay(IRemoteControlDisplay rcd)
RemoteControlDisplay registered with this method will NOT receive any artwork bitmaps.
Use this method only if you DO NOT NEED ARTWORK.
registerRemoteControlDisplay(IRemoteControlDisplay rcd, int w, int h)
w and h are maximum width and height of expected artwork bitmap. Use this method if you NEED ARTWORK.
3. Multiple RemoteControlDisplays
(FOLLOWING TEXT MAY BE NOT WORKING, AS THIS IS ONLY A THEORY BASED FROM STUDYING OF ANDROID SOURCE CODE)
Until API 18 there could be only one active RemoteControlDisplay. So, that means if you register your RCD, and then system decides to do the same, then your RemoteControlDisplay will be unregistered automatically.
However, this is not the case in 4.3, as from API 18 it does support multiple RemoteControlDisplay. So, in theory, you can just fire AudioManager#registerRemoteControlDisplay. Didn't tried that, however.
And, of course, you have to compile with Android 4.3 library.

Really cool guide. :good:
Thank you.

nikwen said:
Really cool guide. :good:
Thank you.
Click to expand...
Click to collapse
Thanks! I just hope it will have the desired effect and Google will release RemoteControlDisplay API to public, 'cause, you know, now I made it public, there's no reason to hide it now. Now I only need it to be featured on the main page...
How about making it sticky or something?

Dr.Alexander_Breen said:
Thanks! I just hope it will have the desired effect and Google will release RemoteControlDisplay API to public, 'cause, you know, now I made it public, there's no reason to hide it now. Now I only need it to be featured on the main page...
How about making it sticky or something?
Click to expand...
Click to collapse
I voted for it.
The sticky: Contact a mod and if it is relevant to the majority of the users, it will be made sticky.
Those are the mods for the Java development forum: diestarbucks, poyensa, justmpm, mark manning, crachel, Archer

I was looking for this undocumented api's and customized transparent lock screen that can listen for events.
Thank you. I will close my other open thread now.
God is great.

@Dr.Alexander_Breen thanks a lot for this, almost spent the day trying to get this to work with reflection.
Anyway, I still can't get it to work.
I'm trying to do this for my S-View cover mod http://forum.xda-developers.com/showthread.php?t=2368665
But the methods aren't called at all.
I've never used handlers before, so I'm guessing there's a problem with those.
Can you take a look at the source code? Since it's an Xposed module, and you might not know Xposed, I'll state a few things about it
https://github.com/MohammadAG/Xpose...ewpowerampmetadata/SViewPowerampMetadata.java
The mod is not a subclass of Activity, so there's no Context, but I do get the Context used by the S-View widget.
After getting the Context, and the Handler used by the S-View classes, I register the RemoteControlDisplay (method initializeRemoteControlDisplay(Looper))
The rest is mostly your code.
If you're wondering why I construct the Handler in such a weird way, it's because I can't create one on the Xposed module thread (something about Looper.prepare()).
Anyway, any help would be appreciated, if the code seems fine, I guess I'll have to use a service and make the module communicate with that instead, though I can't imagine media buttons being any slower.

@MohammadAG:
Your code looks fine to me, but there is one thing.
You register your RemoteControlDisplay in handleLoadPackage() method. I suppose that this method is called only once, but RemoteControlDisplay needs to be registered every time the metadata view is show to user.
Also, added 4.3 implementation.

Dr.Alexander_Breen said:
@MohammadAG:
Your code looks fine to me, but there is one thing.
You register your RemoteControlDisplay in handleLoadPackage() method. I suppose that this method is called only once, but RemoteControlDisplay needs to be registered every time the metadata view is show to user.
Also, added 4.3 implementation.
Click to expand...
Click to collapse
But that's only if I unregister it right? I'll see about it, maybe I need to do the Handler bit different in Xposed.
Thanks
Sent from my GT-I9500 using xda app-developers app

MohammadAG said:
But that's only if I unregister it right? I'll see about it, maybe I need to do the Handler bit different in Xposed.
Thanks
Sent from my GT-I9500 using xda app-developers app
Click to expand...
Click to collapse
Actually, no. As in 4.2 and lower, there can be only one active RCD. So, in case your system decides to register it's own RCD, it automatically unregisters yours.

Dr.Alexander_Breen said:
Actually, no. As in 4.2 and lower, there can be only one active RCD. So, in case your system decides to register it's own RCD, it automatically unregisters yours.
Click to expand...
Click to collapse
Oh, so that explains why your app displayed Unknown at some point. I guess that was my RCD being registered.
Sent from my GT-I9500 using xda app-developers app

And it's on the portal: Implement Lock Screen-Style Music Controls in Your App

MohammadAG said:
Oh, so that explains why your app displayed Unknown at some point. I guess that was my RCD being registered.
Sent from my GT-I9500 using xda app-developers app
Click to expand...
Click to collapse
So, have you managed to make your app working?

Dr.Alexander_Breen said:
So, have you managed to make your app working?
Click to expand...
Click to collapse
No, actually I haven't :/
I register the display each time the S View screen shows, which is when I want to show metadata, but that doesn't work, the handler's handleMessage method is never called.

MohammadAG said:
No, actually I haven't :/
I register the display each time the S View screen shows, which is when I want to show metadata, but that doesn't work, the handler's handleMessage method is never called.
Click to expand...
Click to collapse
Hmm. I'm afraid this is something with Handler in Xposed. You can, however, move IRemoteControlDisplay implementation to service, which will connect with your Xposed part via AIDL or smth like that.
Also, check, if methods of IRemoteControlDisplay are being called. Like, fire a log message when method is called.

Dr.Alexander_Breen said:
Hmm. I'm afraid this is something with Handler in Xposed. You can, however, move IRemoteControlDisplay implementation to service, which will connect with your Xposed part via AIDL or smth like that.
Also, check, if methods of IRemoteControlDisplay are being called. Like, fire a log message when method is called.
Click to expand...
Click to collapse
I thought about that, but I'm pretty sure it'll use up more memory and introduce a bit of lag (if the service was killed for example).
I was thinking of hooking registerRemoteControlClient and keeping the registered remote(s). Then I can simply get the data from their methods, do you know if they're kept in memory for as long as the app lives?
Sent from my GT-I9500 using xda app-developers app

MohammadAG said:
I thought about that, but I'm pretty sure it'll use up more memory and introduce a bit of lag (if the service was killed for example).
I was thinking of hooking registerRemoteControlClient and keeping the registered remote(s). Then I can simply get the data from their methods, do you know if they're kept in memory for as long as the app lives?
Sent from my GT-I9500 using xda app-developers app
Click to expand...
Click to collapse
Again, please check, if methods of RemoteControlDisplay are being called. Write message to debug log(Log.d) in setMetadata or setAllMetadata methods.
As a workaround, I have this idea.
If I understand correctly, Xposed can hook the method of the class, not the instance. Then you can hook RemoteControlClient methods to get the metadata directly from the clients. Check the API reference to RCC to get necessary methods.

really cool tutorial
Thanks a lot !
Could you post one for implimemtation of IBatteryStats...... etc private battery APIs ??
Sent from my GT-S5302 using Tapatalk 2

sak-venom1997 said:
really cool tutorial
Thanks a lot !
Could you post one for implimemtation of IBatteryStats...... etc private battery APIs ??
Sent from my GT-S5302 using Tapatalk 2
Click to expand...
Click to collapse
Well, I think the answer is "no", because I'm no Google Software Engineer. I'll look into this, however, as it will be simplier, I think.
Something like connecting remote service with IBatteryStats.Stub.asInterface. I'll look into it, however.

Dr.Alexander_Breen said:
Well, I think the answer is "no", because I'm no Google Software Engineer. I'll look into this, however, as it will be simplier, I think.
Something like connecting remote service with IBatteryStats.Stub.asInterface. I'll look into it, however.
Click to expand...
Click to collapse
Connecting to serivice and obtaining data i could manage by diging into source but parsing the info is causing trouble
thanks
Sent from my GT-S5302 using Tapatalk 2

[GUIDE] Using the Share Intent

Hello everyone,
While making an app, I wanted to let the user be able to share some content (shameless plug: from a clearable EditText). So, I looked up how to do this.
In this thread, I will share (pun not even intended) with you how to use the Share Intent yourself, so that your users can also quickly involve anyone they know in what they're doing.
There are some things that I am going to assume you've done:
- You have made your base app
- You have a Button done and set up, only needing a method to execute the Share Intent.
Now, let's get to it!
Step 1 - The method:
First, you have to set up the method. As always, give it a nice and descriptive name, so everyone (including you later, believe me that you'll need it) knows what it does.
Of course, this just follows standard syntax. I'm going to name it share, because simple!
So, you'll get this:
Code:
private void share() {
// This is the method where we share some content
}
Step 2 - The Intent:
You want to make sure that Android recognises your Intent as being a Share Intent. Of course, because of the flexibility of Intents, this is also easily done. Just declare another parameter, which isn't the usual set of Classes.
My Intent will be called shareIntent.
Like so:
Code:
Intent shareIntent = new Intent(android.content.intent.ACTION_SEND);
Step 3 - The type:
When sharing content in Android, you have to let the system know what you're sharing. Naturally, it has to react differently to different types of content. An image can be handled by certain apps, while others can only handle text. Apart from that, the apps have to process the items differently.
This is done by declaring the MIME type, which are unique identifiers for different data types.
Some possible types are text/plain, image/gif and video/mp4.
In this case, we are going to share some text. This is done by adding the following line under the Intent declaration:
Code:
shareIntent.setType("text/plain");
With the setType method, you could target specific apps. However, this is obviously not a good idea. If a user doesn't have that app on their phone, it'll cause trouble. Therefore, just use the right type and let the user select the relevant application.
Step 4 - The Content:
Now for the real work. What are you sharing? Of course, text! But you have to give the Intent that text, because it won't just snuff it out by itself.
How do we do this? Simple, again.
Just create a String and use that. Of course, you can hard code a String in the Intent, but it's best to use a variable. After all, you're probably going to be sharing dynamic content.
This is done as follows, though you should really know this by now:
Code:
String sharedString = "Hey, we are sharing!";
Step 5 - The extras:
You have to also give the Intent its extra information. For this example, we'll be setting two types of extras: a subject and the body.
This way, there is flexibility. If the user chooses to share the text using an email application, the subject will also be used. If they don't, it won't be used.
This is done by adding the following lines to your sharing method:
Code:
shareIntent.putExtra(android.content.Intent.EXTRA_SUBJECT, "This is the subject");
shareIntent.putExtra(android.content.Intent.EXTRA_TEXT, sharedString);
Step 5 - The Chooser:
Whenever you share something, you see the Dialog pop up for you to select the app you want to use in your sharing the content. This is the next and last step in this guide, and is basically just starting the Intent with a special parameter.
Not every type of media can be shared to every app. When you share certain content, Android looks at what apps have declared themselves candidates for that MIME type.
So, if you are not seeing certain apps appear, check whether the app can work with that MIME type!
Start the Intent like this:
Code:
startActivity(Intent.createChooser(shareIntent, "Share via"));
Of course, the title to the chooser doesn't have to be "Share via". It can be any other text or variable (keep this in mind for apps that have translations!).
Facebook doesn't do this right! The facebook app doesn't do sharing right, so it will probably not show up in the list of apps that you might see when following the tutorial. To counteract this, target the app using the specific API.
Have fun sharing, and thanks for reading!
P.S.: Images can be added, should anyone want me to do so.

I also found this for the ActionBar very interesting: http://developer.android.com/reference/android/support/v7/widget/ShareActionProvider.html

nikwen said:
I also found this for the ActionBar very interesting: http://developer.android.com/reference/android/support/v7/widget/ShareActionProvider.html
Click to expand...
Click to collapse
True, the ShareActionProvider is quite nice but has one really big downside: You have to update it with the Intent BEFORE the user clicks the item, and there is no workaround. So if you want to generate an image when the user clicks share, you cannot use the ShareActionProvider.
And thanks for the guide OP!

SimplicityApks said:
True, the ShareActionProvider is quite nice but has one really big downside: You have to update it with the Intent BEFORE the user clicks the item, and there is no workaround. So if you want to generate an image when the user clicks share, you cannot use the ShareActionProvider.
And thanks for the guide OP!
Click to expand...
Click to collapse
Wouldn't it be possible to extend the class? Maybe it could be achieved that way.

nikwen said:
Wouldn't it be possible to extend the class? Maybe it could be achieved that way.
Click to expand...
Click to collapse
Could work, but I have no idea what methods to override... I need to have a closer look at this.

Intent filters

Ok so i used to be a very experienced actionscript user. But i recently wanted to get back into programming so im learning java now or rather trying to.
So im trying to understand the xml side of this so far and have some questions im hoping u guys can answer.
activities
So as i understand it an activity is a screen in an app. So for example the standard launcher on my phone has pages of apps on my main screens. Each one of those would be an activity? And then another activity for when i press the button to display all installed apps?
Have i understood that properly?
intent filters
This is where im getting confused. Ive googled it and read as much as i can find. As i read it, feel like someones explaining rocket science to a 5 year old.
The words component and instances is being thrown around enough that i got no clue whats even being said. What i have understood is it gives data to the activity.
So a best guess from my partwould be its telling it how the screens going to work or maybe like if theres going to be a button on it maybe. Or perhaps it means something different like just the properties sort of stuff like screen size or stuff of that nature.
As u guys can probably tell im confused beyond comprehension. I got no idea how good my grasp is of any of this. But if theres someone out there kind enough to dumb it down a bit so normal people can understand it. Id be very gratefull.

Bump

Bump

Hey,
unfortunately i cant answer your question. This is a part of android I don't understand too.
I think you should post your question again in the Question and Answer forum of XDA. http://forum.xda-developers.com/android/help maybe there is an developer who can help you.
Greetings

Thanks ill post there and see if it makes any difference

Android apps run in sandboxes. Consider a huge box partitioned into 'n' number of sections. Each partitions represent a place in android environment where app can reside. By sandboxing, app are given unique ID(UID) when they start a process. Only apps having same (UID) can access the app's resources so no malicious app can peek into the resources of other app.
If apps cannot see other resources, how could they communicate within apps? Thats where intent comes in. Intents are like post letters and android is the postman. You can either give:
1. Recipient address, here, the package name of the app for which the intent is to be sent and may include your data in the intent if there is any and the postman (android) delivers it to the right person (target app). This is also known as explicit intent because you know the target class to call
2. Intent filter - This is not as specific as the first one. Here, your app has to perform something using an external app but your app doesnt know of the other apps which could perform the action. So, this time it will go for a broadcast and say "Hey! I need to take a picture! All camera apps please come in" and the broadcast is sent by android which displays list of apps which respond to this broadcast. When the user chooses the app to perform the action, the app fires, performs the task for your app, return the data to your app in form of intent result.
To register an app to respond to this type of intent, the app specifies something called intent-filter in their manifest which says the android, in our example context "I can perform camera action". So next time intent for camera action is sent, the app is in the list of apps to perform action with. This type of intent in implicit intent as you let the android and user decide the app. You can also specify your own custom intent-filters apart from standard android ones.

vijai2011 said:
Android apps run in sandboxes. Consider a huge box partitioned into 'n' number of sections. Each partitions represent a place in android environment where app can reside. By sandboxing, app are given unique ID(UID) when they start a process. Only apps having same (UID) can access the app's resources so no malicious app can peek into the resources of other app.
If apps cannot see other resources, how could they communicate within apps? Thats where intent comes in. Intents are like post letters and android is the postman. You can either give:
1. Recipient address, here, the package name of the app for which the intent is to be sent and may include your data in the intent if there is any and the postman (android) delivers it to the right person (target app). This is also known as explicit intent because you know the target class to call
2. Intent filter - This is not as specific as the first one. Here, your app has to perform something using an external app but your app doesnt know of the other apps which could perform the action. So, this time it will go for a broadcast and say "Hey! I need to take a picture! All camera apps please come in" and the broadcast is sent by android which displays list of apps which respond to this broadcast. When the user chooses the app to perform the action, the app fires, performs the task for your app, return the data to your app in form of intent result.
To register an app to respond to this type of intent, the app specifies something called intent-filter in their manifest which says the android, in our example context "I can perform camera action". So next time intent for camera action is sent, the app is in the list of apps to perform action with. This type of intent in implicit intent as you let the android and user decide the app. You can also specify your own custom intent-filters apart from standard android ones.
Click to expand...
Click to collapse
Gave u a thanks fkr that very useful responce. Thank you. So if ive understood this right. If i want to take a picture for example the intent filter part basically calls out for an external app to perform the action. With intent filter so basically when an app asks u with that menu what app youd like to choose thats an intent filter? And implicent thats the same menu or android just chooses it for you? Im trying to picture it from the user-side
Recipient address seems straight forward. You know u need an app and what its called. So u dont even need the user to select anything.

scorpafied said:
Gave u a thanks fkr that very useful responce. Thank you. So if ive understood this right. If i want to take a picture for example the intent filter part basically calls out for an external app to perform the action. With intent filter so basically when an app asks u with that menu what app youd like to choose thats an intent filter? And implicent thats the same menu or android just chooses it for you? Im trying to picture it from the user-side
Recipient address seems straight forward. You know u need an app and what its called. So u dont even need the user to select anything.
Click to expand...
Click to collapse
Your understanding on implicit intent is correct. To make it even more short an precise,
An intent is an abstract definition of the operation to be performed by the app
Click to expand...
Click to collapse
When the target action is known, say you invoke a second activity of you app. You know the target action (the class name), that is your implicit intent. You decide what action to perform without user intervention here. Explicit usually needs user input for inter-app communication to take place.
Examples of few implicit intents:
Starting an activity
Starting a service

vijai2011 said:
Your understanding on implicit intent is correct. To make it even more short an precise,
When the target action is known, say you invoke a second activity of you app. You know the target action (the class name), that is your implicit intent. You decide what action to perform without user intervention here. Explicit usually needs user input for inter-app communication to take place.
Examples of few implicit intents:
Starting an activity
Starting a service
Click to expand...
Click to collapse
Ok cool. So recipient is when we choose the app. Intent is whwn they get a menu to choose it. And implicent is is when android chooses it for them.
Sounds simple enough. Thanks for all the help buddy
And would i be right in assuming that the actions we put in intent filters and the others in form it of stuff like when its triggered, how often and so forth?