I'm building some general testing tool for Android apps and trying to get the activity name (e.g. com.android.calculator/.Calculator, the com.android.calculator can be obtained through UiDevice.currentPackageName, the pain is from the second part) during the testing. This is to say that my tool may test other apps that are not in the same package as mine. For example, testing the stock calculator app.
Here is a list of attempts I have made:
the UiDevice.currentActivityName is deprecated and it does not provide the accurate information
InstrumentationRegistry.getInstrumentation().targetContext.getSystemService<ActivityManager>(), then access the ActivityManager.getRunningTasks(1).get(0).topActivity, which always returns the same value even though the view has switched (and this is deprecated too)
Similar to 2, I tried ActivityManager.getAppTasks().get(0).getTaskInfo().topActivity, but this keeps giving me null
ActivityLifecycleMonitorRegistry.getInstance().getActivitiesInStage(RESUMED). This gives me an empty collection
Application.ActivityLifecycleCallbacks. I registered it with the application, but no callback is received.
(Kinda works, but not perfect) using adb dumpsys activity then find it there. But this way I have to wait for some arbitrary time until the view is updated, otherwise the result is still inaccurate
So I am currently in a cul-de-sac now, and I appreciate any help on this issue. I try to avoid reflection, because as I know it does not work on newer devices. So any clue will be appreciated.
As there is no answer posted, I wanna share my current strategy, which is not perfect, but somewhat helpful.
So first of all, as UiDevice.getActivityName is deprecated, I can only obtain the activity name through adb. Specifically, I use adb shell dumpsys activity top for API lower than 28 and adb shell dumpsys activity activities otherwise.
Then I subscribed to AccessibilityEventListener callbacks. Specifically, I run the adb command whenever I receive callbacks with type AccessibilityEvent.TYPE_WINDOWS_CHANGED. You can set up AccessibilityEventListener using this method: setOnAccessibilityEventListener
An app I am working on at work was recently pen tested. One of the risks that came back in the report was that it has no proper Hook detection. I had implemented the RootBeer library but that was easily avoided.
A Frida script was created by the tester for the Android application to modify the root detection logic at run time. The script hooked into the System.exit method to return false instead of true. This prevented the application from exiting after the application detected that the device has been rooted.
It was recommended by the pen testers that we implement as many different checks as possible in order to deter reverse engineers.
One of those checks is to get the Android application to scan its own memory map file located at
/proc/<pid>/maps
where
<pid>
is the app’s process ID (PID).
I have checked the Android docs and can only find info on handling memory but nothing on scanning the memory. eg. https://developer.android.com/topic/performance/memory
I see you can "get a MemoryInfo object for the device's current memory status". But this only shows the available memory on the system.
Does anyone have a solution to this problem?
Been testing the new Android 6 auto backup/restore function, and run into a problem with my app crashing immediately after a restore. Further investigation revealed that the Application.onCreate() initialization method was not being called before the main Activity.onCreate() method. This strikes me as a likely bug in the new autorestore logic. But I thought I would ask for advice here before reporting it as an official bug.
The sequence of events I go through is
Run the app, always open a main activity window.
Force a backup of app data by entering
adb shell bmgr fullbackup net.anei.cadpage
Use the app manager to force close the app and to clear all app and cache data
Restore app information with
adb shell bmgr restore
Manually launch the app
Resulting logs show that the Activity.onCreate() method is called before the Application.onCreate() is. The app crashes because some critical initialization was not performed by the Application.onCreate() method.
Is there something obvious that I am missing???
FWIW, launching the app a second time after the crash works perfectly.
It's actually intentional, though intrusive.
For full-data backup and restore operations, the package is launched with a base class Application instance, not your manifest-declared subclass. This is because, unfortunately, many apps open files or databases via Application subclasses, and this blocks the ability of the backup machinery to correctly read/write the underlying files. Similarly, your app's content providers are not automatically instantiated for full-data backup/restore operations. The app process is then destroyed following the operation, because of course your app cannot continue to run normally without its expected Application subclass or content providers.
You also don't say exactly what command you're using to perform a test restore, but I suspect you're using the bmgr command with this syntax:
adb shell bmgr restore PACKAGE
This doesn't do what you expect. In particular, it invokes the code path that happens when your app calls BackupManager.requestRestore(observer). In this specific code path, the app is NOT shut down following the restore operation, because the app has asked to observe the operation itself. This means that you're left with the app process still running but with a base class Application. It's a power-user API that is pretty much only safe when the app uses the original key/value backup API. You need to test instead using the other bmgr syntax:
adb shell bmgr restore TOKEN PACKAGE
where TOKEN is the identifier for which dataset should be used. At least on the most recent versions of the OS you can see the current and ancestral dataset tokens in the output of adb shell dumpsys backup.
This all needs to be better documented and made less surprising.
Subclassing Application is generally discouraged; this is one reason. Try to use your own lazy-init statics instead of subclassing Application.
I need a starting point to make the following possible.
I have a Main activity start when the Android application starts, as well as an alternate screen that I want to be Debug output (only strings). What I am struggling with is, what layout do I use for the debug screen, and how do I keep this screen constantly populating while I am viewing my Main activity? I do not have any code for this functionality as everything I have tried has crashed my application, so I was hoping to start fresh. I am a super noob to Android so any information would be helpful.
Thanks in advance.
EDIT:
I am sorry, I should have been more specific. I will be receiving Debug information over Bluetooth from a robot. Sensor information, location, possibly a camera feed, etc. At the moment I am looking for a good way to display the Debug information that is Text only. I have a Main Activity that will have the controls of the Robot, and I want to have a second separate screen (that can be switched to from the Options menu) that will have the debug information updated in real time. Don't worry about any of the Bluetooth stuff I can already read and write to the socket. Just the "debug screen"
I would suggest using the log associated with each method, listener, etc. you'd like to keep track of. See here: http://developer.android.com/reference/android/util/Log.html
The TAG identifies the aspect you'd like to track in your logCat:
private static final String TAG = "MyActivity";
Then you simply add the following into your methods, listeners, etc.
Log.v(TAG, insert variables and other info here);
You use your app on the device or emulator normally and filter your logCat output for the items your tracking. You can do it simultaneously or inspect you logcat after you've used the app for a bit.
Hope that helps...
I would use the eclipse debugger. The console output as well as logcat are also very useful for debugging.
If you must create your own debug screen I would create an asynctask that can run in the background. Each time you get output that should go to your debugger I would send it to your asynctask and have the asynctask store it in the database along with a time stamp. Then any time you want to view debug output pull up your custom view that pulls data from your database. You could use a LinearLayout that has 6 textviews. The textviews could display the last 6 messages from your debugger. How you implement the layout is really up to you. Just make sure you persist the debug info in your database rather than in memory or I can almost guarantee some of your debug info will be lost.
After doing some more research I have decided to use a TabActivity instead of trying to do two separate screens. This allows the Tabs to be under 1 Activity and I do not need to worry about inter-Activity communication. Thank you all for you help.
This question already has answers here:
Is quitting an application frowned upon?
(40 answers)
Closed 9 years ago.
Please suggest how I may close my whole Android Application with one line code.
Yes - Why, then how(sort of):
Short answer:
System.exit(0);
This nicely and cleanly terminates the whole java machine which is dedicated to running the app. However, you should do it from the main activity, otherwise android may restart your app automatically. (Tested this on Android 7.0)
Details and explanation of why this is a good question and a programmer may have a very legitimate reason to terminate their app this way:
I really don't see the gain in speaking harshly to someone who's looking for a way to terminate their app.
Good is a friendly reminder to beginners that on Android you don't have to worry about closing your app -- but some people actually do want to terminate their app even though they know that they don't have to -- and their question of how to do so is a legitimate question with a valid answer.
Perhaps many folks live in an ideal world and don't realize that there's a real world where real people are trying to solve real problems.
The fact is that even with android, it is still a computer and that computer is still running code, and that it is perfectly understandable why someone may wish to truly exit their "app" (i.e. all of the activities and resources belonging to their app.)
It is true that the developers at Google designed a system where they believed nobody would ever need to exit their app. And maybe 99% of the time they are right!
But one of the amazing things about allowing millions of programmers to write code for a platform is that some of them will try to push the platform to its limits in order to do amazing things! -- Including things that the Android Developers never even dreamed of!
There is another need for being able to close a program, and that is for troubleshooting purposes. That is what brought me to this thread: I'm just learning how to utilize the audio input feature to do realtime DSP.
Now don't forget that I said the following: I well know that when I have everything done right, I won't need to kill my app to reset the audio interface.
BUT: Remember, perfect apps don't start out as perfect apps! They start out as just barely working apps and grow to become proper ideal apps.
So what I found was that my little audio oscilloscope test app worked great until I pressed the android Home button. When I then re-launched my oscilloscope app, there was no audio coming in anymore.
At first I would go into
Settings->Applications->Manage Applications->AppName->Force Stop.
(Note that if the actual linux process is not running, the Force Stop button will be disabled. If the button is enabled, then the Linux process is still running!)
Then I could re-launch my app and it worked again.
At first, I was just using divide by zero to crash it - and that worked great.
But I decided to look for a better way - which landed me here!
So here's the ways I tried and what I found out:
Background:
Android runs on Linux.
Linux has processes and process IDs (PIDs) just like Windows does, only better.
To see what processes are running on your android (with it connected into the USB and everything) run adb shell top and you will get an updating list of all the processes running in the linux under the android.
If you have linux on your PC as well, you can type
adb shell top | egrep -i '(User|PID|MyFirstApp)' --line-buffered
to get just the results for your app named MyFirstApp. You can see how many Linux Processes are running under that name and how much of the cpu power they are consuming.
(Like the task manager / process list in Windows)
Or if you want to see just the running apps:
adb shell top | egrep -i '(User|PID|app_)' --line-buffered
You can also kill any app on your device by running
adb shell kill 12345
where 12345 is it's PID number.
From what I can tell, each single-threaded app just uses a single Linux process.
So what I found out was that (of course) if I just activate the android Home option, my app continues to run.
And if I use the Activity.finish(), it still leaves the process running.
Divide by zero definitely terminates the linux process that is running.
Killing the PID from within the app seems the nicest so far that I've found, at least for debugging purposes.
I initially solved my need to kill my app by adding a button that would cause a divide by zero, like this in my MainActivity.java:
public void exit(View view)
{
int x;
x=1/0;
}
Then in my layout XML file section for that button I just set the android:onClick="exit".
Of course divide by zero is messy because it always displays the "This application stopped..." or whatever.
So then I tried the finish, like this:
public void exit(View view)
{
finish();
}
And that made the app disappear from the screen but it was still running in the background.
Then I tried:
public void exit(View view)
{
android.os.Process.killProcess(android.os.Process.myPid());
}
So far, this is the best solution I've tried.
UPDATE: This is the same as above in that it instantly terminates the Linux process and all threads for the app:
public void exit(View view)
{
System.exit(0);
}
It instantly does a nice full exit of the thread in question without telling the user that the app crashed.
All memory used by the app will be freed. (Note: Actually, you can set parameters in your manifest file to cause different threads to run in different Linux processes, so it gets more complicated then.)
At least for quick and dirty testing, if you absolutely need to know that the thread is actually fully exited, the kill process does it nicely. However, if you are running multiple threads you may have to kill each of those, probably from within each thread.
EDIT: Here is a great link to read on the topic:
http://developer.android.com/guide/components/fundamentals.html
It explains how each app runs in its own virtual machine, and each virtual machine runs under its own user ID.
Here's another great link that explains how (unless specified otherwise in manifest) an app and all of its threads runs in a single Linux process: http://developer.android.com/guide/components/processes-and-threads.html
So as a general rule, an app really is a program running on the computer and the app really can be fully killed, removing all resources from memory instantly.
(By instantly I mean ASAP -- not later whenever the ram is needed.)
PS: Ever wonder why you go to answer your android phone or launch your favorite app and it freezes for a second? Ever reboot because you get tired of it? That's probably because of all the apps you ran in the last week and thought you quit but are still hanging around using memory. Phone kills them when it needs more memory, causing a delay before whatever action you wanted to do!
Update for Android 4/Gingerbread: Same thing as above applies, except even when an app exits or crashes and its whole java virtual machine process dies, it still shows up as running in the app manager, and you still have the "force close" option or whatever it is. 4.0 must have an independent list of apps it thinks is running rather than actually checking to see if an app is really even running.
You could finish your Activity by calling Activity.finish(). However take care of the Android Activity life-cycle.
You could close your Android Application by calling System.exit(0).
just call the finish() in the method you would like to end the activity in, for example when you use the onCreate() method, in the end of the method, just add finish() and you will see the activity ends as soon as it is created!
As per my knowledge, finish function close the current displayed screen only.
Refer this example (where see the answer given by 'plusminus'), it will sure help you to close your application.
Before doing so please read this other question too:
android.os.Process.killProcess(android.os.Process.myPid());
android.os.Process.killProcess(android.os.Process.myPid());
This code kill the process from OS
Using this code disturb the OS. So I would recommend you to use the below code
this.finish();
Intent intent = new Intent(Intent.ACTION_MAIN);
intent.addCategory(Intent.CATEGORY_HOME);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
The answer depends on what you mean by "close app". In android's terms its either about an "activity", or a group of activities in a temporal/ancestral order called "task".
End activity: just call finish()
End task:
clear activity task-stack
navigate to root activity
then call finish on it.
This will end the entire "task"
not a one-line-code solution, but pretty easy:
sub-class Activity, then override and add finish() to onPause() method
this way, activity will be gone once it enters background, therefore the app won't keep a stack of activities, you can finish() the current activity and the app is gone!
If you close the main Activity using Activity.finish(), I think it will close all the activities.
MAybe you can override the default function, and implement it in a static way, I'm not sure
I don't think you can do it in one line of code. Try opening your activities with startActivityForResult. As the result you can pass something like a CLOSE_FLAG, which will inform your parent activity that its child activity has finished.
That said, you should probably read this answer.
That's one of most useless desires of beginner Android developers, and unfortunately it seems to be very popular. How do you define "close" an Android application? Hide it's user interface? Interrupt background work? Stop handling broadcasts?
Android applications are a set of modules, bundled in an .apk and exposed to the system trough AndroidManifest.xml. Activities can be arranged and re-arranged trough different task stacks, and finish()-ing or any other navigating away from a single Activity may mean totally different things in different situations. Single application can run inside multiple processes, so killing one process doesn't necessary mean there will be no application code left running. And finally, BroadcastReceivers can be called by the system any time, recreating the needed processes if they are not running.
The main thing is that you don't need to stop/kill/close/whatever your app trough a single line of code. Doing so is an indication you missed some important point in Android development. If for some bizarre reason you have to do it, you need to finish() all Activities, stop all Services and disable all BroadcastReceivers declared in AndroidManifest.xml. That's not a single line of code, and maybe launching the Activity that uninstalls your own application will do the job better.