JPDA MethodEntryEvent causing app to run very slow - java

I am trying to capture all method calls made in any android app. For that I am using JDI to register MethodEntryRequest for each running thread of the app. I am successful to do this, but I am facing the problem that the app becomes very very slow. So I want to know if I am doing anything wrong in my implementation. I am adding my code where I first register ClassPreparedRequest to catch loading of each class by app process and in that I register MethodEntryRequest with threadfilter for thread which caused the class to load.
if(!traceMap.keySet().contains(event.thread()))
{
EventRequestManager mgr = vm.eventRequestManager();
MethodEntryRequest menr = mgr.createMethodEntryRequest();
menr.setSuspendPolicy(EventRequest.SUSPEND_NONE);
menr.addThreadFilter(event.thread());
menr.enable();
}
Code for registering ClassPreparedRequest is
ClassPrepareRequest cpr = mgr.createClassPrepareRequest();
cpr.addClassFilter("com.example.*");
cpr.setSuspendPolicy(EventRequest.SUSPEND_NONE);
cpr.enable();

Related

Java Google Photos Api - How to cancel 'PhotosLibraryClient.initialize(settings)'?

I am developing an app in Java (Kotlin :X) that uses the Google Photos Api.
I am stuck in a flow where I may want to cancel the current client initialization attempt and try again.
val settings = PhotosLibrarySettings.newBuilder()
.setCredentialsProvider(
FixedCredentialsProvider.create(
getUserCredentials(credentialsPath, SCOPES, email)
)
)
.build()
// let the Thread hanging until a successful initialization :/
return PhotosLibraryClient.initialize(settings)
But unfortunately, I did not find any way to do this besides enveloping the PhotosLibraryClient.initialize(settings) call in a Thread and calling the deprecated method Thread#stop().
If I do this call twice (on different threads), without successfully stopping one of the client initializations, the following exception is thrown: java.io.IOException: java.net.BindException: Address already in use (Bind failed).
How can I successfully stop a client initialization attempt without calling Thread#stop()?

killBackgroundProcesses not working, any other suggestions?

I am building an application that should be able to close other android applications. In this case, I am using Google Maps. I have granted permission in the Android Manifest XML to killBackgroundProcesses, but the following code does not close the "Google Maps" application. My app calls killApp() every second to ensure Google Maps is closed. Any idea what I'm doing wrong here?
public void KillApp()
{
Context context = getContext();
String maps = "com.google.android.apps.maps";
ActivityManager activityManager = (ActivityManager)context.getSystemService(Context.ACTIVITY_SERVICE);
activityManager.killBackgroundProcesses(maps);
}
You can only kill your own apps, e.g. the ones running in the same process or with the same userID. You can not kill others, unless the device is rooted.No one can kill process except Android OS itself.
Most of the task killer in android market don't kill the app they just restart the process
by using
public void restartPackage (String packageName)
when this method is called by your activity the operating system immediately called
savedInstanceState and save the state of that activity you want to kill. Now this process is
removed from memory and OS saved it state.Now when next time user start that activity it
will start from where it was killed or in other words restarted. You can verify it from any
task manager that they don't kill the process because no one can do so. This method also
work in ICS.
for above method you can look at here . As far as i know killBackgroundProcesses (String packageName) is for API 8 and above.

Leak memory in war servlet with tomcat

I am having some problems when I try to implement a new function in my working servlet.
Now I have a servlet in which mobile phones can register. Mobile phones use rest to register against this servlet. And it works perfect. Anytime you try to register a phone, it works.
But now, I need to add a new functionality. I want to register this server against other component of my infrastructure.
I want that registration done at the very beggining. I mean, when the servlet starts, make the registration and forget about it, just work as it did before.
This is the error tomcat gives me:
Grave: The web application [/servletRegister] appears to have started a thread named [Timer-8] but has failed to stop it. This is very likely to create a memory leak.
This is my start class:
#Override
public Set<Class<?>> getClasses() {
//-------------------------------
//Set registration here
//GatewayRegistrationHandler reg = GatewayRegistrationHandler.getInstance();
//reg.registerDevice();
//-------------------------------
//register on a new thread due to process time
new Thread (new RegisterGatewayOnBackground()).start();
//Next are the working servlet code
Set<Class<?>> classes = new HashSet<Class<?>>();
classes.add(PublicationsResource.class); /
classes.add(DeviceResource.class);
return classes;
}
}
I tried the commented lines firstly. Then I got a memory leak and I tried to execute them in a new thread trying to avoid the leak. But the behavior is the same.
The background function is this:
public class RegisterGatewayOnBackground implements Runnable {
public RegisterGatewayOnBackground() {
}
public void run() {
registerDevice();
}
private void registerDevice() {
GatewayRegistrationHandler reg = GatewayRegistrationHandler.getInstance();
reg.registerDevice();
}
}
GatewayRegistrationHandler works fine because when I run the servlet, it executes, makes the registration and then, after that, crash. I thought it was a time problem and background would solve it but I am stuck here since background does the same.
I don't know any way to check where to find my memory leak. I am looking for advice or any tools which might help me solve the problem.
When you start your thread like that, it will not be named "Timer-x". Therefore, this was probably a thread started elsewhere.
The message tomcat is giving you indicates that the webapp is somehow being undeployed (and then it checks for threads which are still there, and complains if there is). I'm not sure why the undeploy is happening, but if it's because you are stopping the webapp., you may not need to fix this unless you do (lots of) hot-deploys (deploying and undeploying while keeping the tomcat running). This is because, if it's leaking memory right before you are going to kill the process anyways, the memory leak won't have any harm and it would be waste of time to fix it.
If you want to fix it, one easy way is to hook a profiler and see who started this "Timer" thread.

Java Desktop.browse occasionally returning "requested lookup key not found in any active activation context"

I am really struggling with this issue as it seems to occur randomly for me. When I call,
Desktop.browse("some url");
Internet Explorer will not display. The exception message is as follows,
The requested lookup key was not found in any active activation context.
When it occurs it occurs consistently until I restart the machine, but it eventually occurs again.
The workstations that seem to have this problem are running Windows XP with Internet Explorer 8 set as the default browser.
EDIT: I forgot to mention that if I open up Internet Explorer directly and navigate to the URL in question then it will work fine.
EDIT2: This seems to happen if Desktop.browse is invoked and then is called again at least 15 minutes later. Restarting the application now seems to fix the problem.
I narrowed down the problem and discovered what was TRULY causing this, it had nothing to do with the time after all.
java.awt.Desktop.browse("some url"); was throwing this error because in a previous step in the application an ActiveXObject was opened programmatically using the JACOB framework.
The developer that wrote this code using this ActiveXObject neglected to bother releasing his resources at all. For some reason, this ActiveXObject in memory was preventing or screwing with the Dispatch call to the default OS browser in java.awt.Desktop class. I suppose this makes sense.
I fixed this by declaring a JACOB transaction, and by releasing all resources in a finally block like so:
ActiveXObject ao1 = null;
ActiveXObject ao2 = null;
ComThread.initMTA();
try {
ao1 = new ActiveXObject("blaa.blaa");
ao2 = new ActiveXObject("haa.haa");
// business logic
} finally {
if (ao1 != null) {
ao1.safeRelease();
ao1 = null;
}
if (ao2 != null) {
ao2.safeRelease();
ao2 = null;
}
ComThread.Release();
}

How to close another app in Android?

I have been developing an app, and I need to close another app in my code. Does anyone know any api to call to close an app?
BTW: my app will be pre-installed.
thanks
Since Android 2.2 (i.e. going forward), you can only close the background processes of other apps, you are no longer able to close their main activities.
If your app is targeting Android <2.2, look atandroid.permission.RESTART_PACKAGE.
If you want it to work properly on 2.2 and above (which you should :-)), look at android.permission.KILL_BACKGROUND_PROCESSES, but again, this only closes background services and such and might "mess up" the other app rather than doing any good.
With the right permissions, you can then do the following:
private ActivityManager am = (ActivityManager) this.getSystemService(ACTIVITY_SERVICE);
am.restartPackage("com.jimmy.appToBeClosed");
Try This
ActivityManager am = (ActivityManager) getApplicationContext().getSystemService("activity");
Method forceStopPackage;
forceStopPackage =am.getClass().getDeclaredMethod("forceStopPackage",String.class);
forceStopPackage.setAccessible(true);
forceStopPackage.invoke(am, pkg);
In manifest file add this
<uses-permission android:name="android.permission.FORCE_STOP_PACKAGES"></uses-permission>
If both applications are yours, you can use AIDL for inter-process communication to send a message telling the other application to close. See http://developer.android.com/guide/developing/tools/aidl.html.
I have been able to close another app on Android 12 successfully. Here is how:
Basically, I am closing another app from a service although you should be able to do it from an app too.
My service is a privileged system app that gets installed in system/priv-app/ (It has LOCAL_PRIVILEGED_MODULE := true in its Android.mk)
I added <uses-permission android:name="android.permission.FORCE_STOP_PACKAGES" /> in AndroidManifest.xml
I added in privapp-permissions.xml
<privapp-permissions package="<my service package name>">
<permission name="android.permission.FORCE_STOP_PACKAGES"/>
</privapp-permissions>
I called in my service this method with the package name of the application I want to close:
private void closePackageApp(String namePackage) {
ActivityManager activityManager = (ActivityManager)
context.getSystemService(Context.ACTIVITY_SERVICE);
try {
Method forceStopPackage = activityManager.getClass().
getDeclaredMethod("forceStopPackage", String.class);
forceStopPackage.setAccessible(true);
forceStopPackage.invoke(activityManager, namePackage);
} catch (NoSuchMethodException | InvocationTargetException | IllegalAccessException e) {
e.printStackTrace();
}
}
I tested this and in the logs, I can see the app is being closed. However the app is not removed from the recent screen (logs suggested the app was disposed without first being removed with the input manager!).
However, I am sure the app was really being closed when it was in the background by comparing its lifecycle on opening again. Normally, it is onPause->onResume but now it is onPause->onCreate.
You don't ever really want to close another application, due to Android activity lifecycle.
There's no benefit, and always detriment to closing another app if it's not yours, and very little benefit to closing your own.
http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
If you know for certain that you'll never, ever need a root activity and its children (an "app"), you can stop it to free memory (it doesn't free that much), but if you do the user may restart it while it's still in cache, stopped, which can cause problems if the stopped state is restored. So this is a bad practice.

Categories