Is there any way the android system can inform a service that an activity or a task in the system(not only my activities/tasks!) has somehow changed (e.g. another activity is brought to the front or is stopped)? This is to avoid polling the same information, of course.
There is an identical question here, but it was asked 3 years ago, so in the meantime, maybe someone has an answer to this? As a supplement to this question: If the answer is no, is there any way someone could enhance this feature by, let's say, low-level programming or something?
No, there is no general solution. You can only record this information in the lifecycle methods of your own activities. And starting in Android 5, even polling does not work. ActivityManager#getRecentTasks() was nerfed. From the docs:
This method was deprecated in API level 21. As of LOLLIPOP, this method is no longer available to third party applications: the introduction of document-centric recents means it can leak personal information to the caller. For backwards compatibility, it will still return a small subset of its data: at least the caller's own tasks (though see getAppTasks() for the correct supported way to retrieve that information), and possibly some other tasks such as home that are known to not be sensitive.
Since this is considered a security issue, you can bet that if there is a low-level way to do it, Google will eventually find out and break it.
Isn't what you want covered already by the activity lifecycle events?
Aren't onPause() and onResume() sufficient?
i am feeling lazy sorry, try this logic.
check this post. what you would want to achieve here is record all the Tasks running currently; and in a loop you keep checking, you will be notified when a task die by checking the overall running Task, loop through and you will know who died- but this is limited not all versions, and some people will tell you, it is not meant for that.
Related
As part of my application I need to block incoming calls. I.e While my application is running, I will drop any call and simply notify the caller that the user is busy or something similar.
I wish to do this using the android SDK, I hope to support Android versions 2.2 and above.
I've already looked at
How to block calls in android
(Says, and I quote "It is Mission Impossible for the time being.")
Intercept incoming calls
(Also says not possible)
Can we intercept incoming call in android?
(Gives telephonyService.endCall(); as the solution)
Create a custom call handling Application
(Says it's not possible)
https://groups.google.com/forum/?fromgroups=#!topic/android-developers/gc5vOHjBE30
(discussion seemed inconclusive)
But they don't seem to be of much help.
Even after reading of a lot of questions on stack overflow, google groups and other forums I am still not clear as to whether this is possible or not. Also a lot of the questions and threads are over 2-3 years old, thus adding to my confusion.
And if this is possible then what would be the best way to do it?
Seems like this is not possible after android 2.2 which dropped the hidden itelephony interface.
So yes "It is Mission Impossible for the time being."
I've been digging the web in quest of finding nice, androidish solution for this concrete problem, but havent found one, so here I am, posting my first question on StackOverflow.
To elaborate on my problem, I have a full-fledged aidl service, to which some other processes bind. My service will allocate some resources for each of process connecting to it, and I want to make this statement bold, the resource allocation is made for process, I make some kind of a session tracking, where getCallingPid() and getCallingUid() play a role of session identifiers.
So the problem here is that Android will never tell us if an application which was bound to us went away for some reason, so the system resources allocated for that destroyed process would be wasted away by being held by our service.
One solution that I found somewhat feasible is just to poll ActivityManager.getRunningAppProcesses and calculate set difference between current and previous snapshots, but this method looks really dirty.
Could anyone suggest some better method to do this? I'd be really grateful!
Thanks,
Giorgi
As far as I'm aware, Android won't tell you when processes are killed.
I suspect the only method is to get a list of running applications every x seconds or minutes, and keep track of the applications that way. I think this is what you already suggested in the question as well.
It's not pretty, but it's likely one of the only ways to do it.
Creation of a hidden process seems to be impossible ... so i came to conclusion that hiding a process from the user is impossible so if the service or process appears to RUN as a sub process to any other applications like PHONE APP , or MESSAGING APP , the running process can be hidden to an extend .
This can be only achieved by code injection , so want a help in achieving this . code injection from the user level.
Sure this is possible - http://www.phrack.org/issues.html?issue=68&id=6#article. And as for #commonswear's answer, that's completely wrong. Many respectable developers do this type of this for good, in fact some rooting techniques work this way. Also, sometimes developers can do this to their own code post-deployment, and some developers may do this and notify the user because it provides extra functionality that they wanted in the first place.
Fortunately, this is impossible, short of a security flaw as #Dave notes.
No respectable developer tries to hide processes from users or inject code into foreign processes, as seems to be your intent.
This is actually a very simple thing: I need to know if there is any of MY activities in the history stack? I'm not talking about other apps, just my own app. And I don't even need to know what are they or how many of them, I just need to know IF THERE IS ANY? Is there a way to achieve this? (ActivityManager.getRunningTasks().topActivity() is not for this purpose.)
(I'm implementing a backward/forward feature, as seen in many browsers. At first I tried to manage my own history stack and not use Android's at all. So I used noHistory=true for all activities in the manifest. This leads to the problem that the app's behavior is weird when it comes to the interacting with other apps or the Launcher. Now I tried to utilize Android's history stack for Backward operation, but my own stack for Foreward. But then it hits an unexpcted problem. .... Not just that, there is this security consideration in the app so that I can't let the user go back to any activity if the file has been locked up. I have to have total control over the stack.
Having been bothered by Android's activity life-cycle model and the history stack for several days. Extremely inflexible. How can they assume that all applications all activities in the world behave in the way they imagined in the lab!!!??? Seeing lots of people asking questions on the Internet in this area, and it seems to me everybody hit a dead end and then try to find some work-around, or compromise, or might as well change the spec. Android has been around for 3 years now, but they still didn't do anything to make it more flexible. I guess it must be a very fundamental thing in the design since Day One so that they know about the problem, but they can't do anything about it. Call it a wrong design.)
(And this non-blocking, non-synchronize dialog/message boxes. I don't know how they come up with this design. Whenever you want the user to confirm something, you have to break the program flow into several parts. This undoubtedly makes the program difficult to write and impossbile to maintain! If you have a series of questions one dependent on another, you might as well limplement a state machine.)
If you use Fragments in SDK level 11 and higher (so Honeycomb and certain Gingerbread levels), you can explicitly manage the stack. For regular Activities, you really don't have access to the stack, so you're out of luck there. You could possibly implement a personal stack using an application-level stack: storing the Intents you're using to launch Activities so you can move forward and then returning another Intent with the configuration data for each Activity (when each Activity finish()es you pass this state in the onActivityResult call back).
It would be very messy though.
Since you create and finish the activities, you should be aware of what is on the stack at runtime. Generally, you can control the stack pretty well. Take a look at the ApiDemo revolving around manipulating the stack.
My main activity is basically useless without another activity (act2). act2 can be accessed from a button in the main activity. It is also available through a home screen widget, which when clicked calls my main activity and immediately calls act2.
Right now, I have it set to check license anytime the function that handles the button click is called. This covers the button press in the main activity as well as if you come from the widget.
My question is, is this too often? Is getting a cache response anymore draining than checking a variable for example?
I have tried putting it on onCreate but when it says it's not licensed, you can just close the application and open it again and it will not run through onCreate again.
Here I assume you've read all the licensing documentation, and that you're using the SDK. You said nothing, so I'm going for the "defaults". There are a few clues on the Android developers blog as well as on the Internet.
I asked myself the same question last year. Or at least something similar. So let's go one step at a time:
My question is, is this too often? Is
getting a cache response anymore
draining than checking a variable for
example?
I would say that the difference is going to be "imperceptible" to "not much". First of all, the validity timestamp (VT field from extras) is stored locally, properly encrypted/obfuscated. I'm assuming you're using the ServerManagedPolicy policy, since you said nothing about it.
Depending on the kind of the app, we should notice that you may be even writing things on onPause, for example (checking for changes if applicable, of course). So, I wouldn't worry about it.
But because there is no perceptible harm does not mean you should do something. That's why I disagree with what Kerin posted:
I'm sure you'll stop loads of piracy and you aren't wasting your time at all.
More on that later. For now I say that you shouldn't need to do lots of checkings. That's what the policies are for. They handle it probably better than you and me. Anything else is indeed a waste. Personally, I only do checkings on onCreate (obviously), and also in one more situation rarely used (but very important on the app usefulness).
What you should do, however, and I say because nobody said here yet, is properly obfuscate and change the LVL library, as well as your own code side (the checkerCallbacks). Here, I changed a lot of things on the LVL library, including some simple single key cryptography (weak), and also changed how the interfaces are implemented, and how arguments are passed, and so on. Basically, I created my own LVL after posting that question here on SO.
On the opposite of what you're doing, I also customized the VT field in order to mandate a minimum time for the validity of the cached response. That's why my app is to be used in the wild, where net access is not always available. Those subtle details depend on your app, what it does, how it does, where people would be using them.
If you're a developer, it's easy to forget about the user. There is nothing worse than a legitimate user being denied access to an app he bought. So far, I didn't have problems (I check usage statistics and compare to my account), but I believe games have more trouble (it's typical of that field).
So, returning to my constructive (please, we are all trying to learn here, myself included) critic about Kerin's post, I would say that even LVL itself is not enough to "stop loads of piracy".
If you know anything about how Android works, you'd know that the apks can be easily decrypted to source code, just use dex2jar and jdgui (Google them). In fact, I always decrypt my apps before publishing to check if everything is working the way it should. And take into account that I never did computer college, I just happened to learn java and Android to create my own app that I needed and was unavailable for Android (a tide app for my country). I'm sure there are hackers and techies much smarter out there that can do even more.
People start thinking that LVL will stop piracy, and then learn the ugly truth and be disappointed. That's not what the LVL is for. Just look at the code... it was made to avoid "automated" piracy. It is to force someone to personally look into the code, see how it works, and then "switch" the proper flags, if he can make sense of them. But then again, if you use proguard, it will make the task horrible, exhaustive (believe me, that's why I use dex2jar + jdgui myself).
If your app is being sold for $1 or even around $5 or more, it will make this trouble not worth it. That's my stance on the LVL. Obviously, if you have an niche app that costs $100, for example, you probably can do it properly, server side, with public keys. But I feel that it's not the case here.
Anyway, just my 2 cents.
You can check for the license for the first time, then cache it. The next time when your app runs, read the license from the cache, and also start a Thread that gets the license from your server. If the license that you got from the server is now invalid. You can pop up a dialog box to tell the user that the license is invalid, remove the cached license, and quit the app.