I'm working on a phone-conference app on Android 7. I found this problem.
When app crash I loose ongoing call control resulting in app closed and voice channel open.
Reopening app result in two ongoing calls.
There are ways to close the first voice call?
I try closing the call at app restart but obviously Android OS don't let me touch it.
the best (still not working) result I achieved is error class extension. that event is fired at crash start.
here is my class CrashKillCall that implements Thread.UncaughtExceptionHandler
public void uncaughtException(Thread t, Throwable e) {
//"the last song kill the audience" by Crash & the boys
Log.e(TAG, "--------------------------------------");
Log.e(TAG,t.getName());
Log.e(TAG,e.getCause().getMessage());
Log.e(TAG, "--------------------------------------");
crashCall.disconnect();
Log.e(TAG,"work?");
}
public static void setCall(Call call){
crashCall=call;
}
the desired result is some way to, or to let system know that i want to, terminate the ongoing or all calls.
thank you for your help.
ended out that i was pointing at wrong Call object. code work, you just need declare an istance of that class as default exception listener and register the right Call
Related
As soon as I receive a push notification from my app I want to trigger the KeyguardManager to launch the fingerprint/pass code screen to open the phone from lock screen so that person can enter the phone and unlock the device.
I want to trigger this programmatically similar to when we click on any notification from lock screen we get the fingerprint/pass-code screen.
I did a lot of RnD but didn't find any solution, this is one of the challenging use case task given to me in class, I have been exploring a lot from quite few weeks with no success at all.
Did tried Broadcast receiver with BiometricManager and many things with no success, any lead will be very helpful.
As soon as you receive push message, onNotificationReceived() (or some other method if you use some 3rd party libs) method gets called as below. from there, you can launch your Main screen where you have written biometric/unlocking code.
class MyReceiver : PushReceiver {
override fun onNotificationReceived(message: Message) : Boolean {
//Launch your MainActivity where you can show Unlock screen.
return super.onNotificationReceived(message);
}
}
I've got a very weird problem and is difficult to describe so please read carefully the assumptions before the answer to avoid jumping into something I already know isn't
1 - I've got an android app which login from my server
2 - after a successful login I instantiate a Singleton API which will be shared across the activities in order to make the requests to the server
3 - Isn't possible to use the app without login
4 - in my login activity I have a very clean condition
if(APIFacade.getInstance() != null){
startActivity(new Intent(this,MainActivity.class));
finish();
}else {/*error handling*/}
5 - there is just one call to startActivity method in the whole LoginActivityclass so isn't possible to start MainActivity without check if the facade is null
6 - it isn't possible to set APIFacade.INSTANCE to null after instantiating it
But even with all these conditions sometimes users get NullPointerException on MainActivity when the app tries to make the first call to API after login
String url = APIFacade.getInstance().getProfilePicUrl(); //throws nullpointerexception on 5% of the times
APIFacade class is like this:
public class APIFacade {
private static APIFacade INSTANCE = null;
#WorkerThread
public APIFacade(Object i, final boolean preLoad) {
INSTANCE = this;
//other stuff
}
public static APIFacade getInstance() {
return INSTANCE;
}
}
I'm not able to reproduce the problem in the development environment so I just know it happens due to the crashlytics dashboard on firebase...
I believe my code has no leak to lead this situation, so the only theory I got is: Android is cleaning some variables from memory when my app goes background...
I know android naturally does it for activities, but singletons?
and if yes what can I do to solve it?
Well I found the answer myself thanks to a great article: https://medium.com/#davethomas_9528/please-dont-use-singletons-to-persist-state-on-android-7bac9bc78b29
Briefly:
Everybody says that singleston on android are attached to the application life, so will only be released if the application is killed
THIS IS TRUE
what you dont hear, is that the application can be killed by the SO without user interaction (to release memory for foreground apps) and in this scenario when the user tries to come back to your app it will restart from the last used activity and not from the launcher activity.
Got asked this today in an Android interview. I answered the usual, you know, intent + startActivity, etc. Interviewer then asked more pointedly,
"Yes, but where is it actually instantiated? You don't call new
Activity anywhere".
Which now that I think about it, I don't really know. He hinted that it used Java reflection, but I dont have a lot of experience with that, and I've only used it to access some variables in the Android SDK.
Can someone explain how Activities are instantiated using reflection, and why? Bonus points for insight into what value the interviewer saw in knowing this.
When an app's launcher icon is clicked on homescreen, following event happens under the android system :
Homescreen/Launcher app sends an intent to start an activity using startActivity()(startActivity() is binder call to ActivityManager)
Activity Manager sends a process fork request using a socket to Zygote.
Zygote forks a new VM instance that loads ActivityThread(Activity thread manages the execution of the main thread in an application process, scheduling and executing activities, broadcasts, and other operations on it as the activity manager requests.).
ActivityThread has real main() for an app.
ActivityThread calls the app's onCreate().
Hence ActivityThread is responsible for instantiating Activity(inside performLaunchActivity method)
Explanation :
If you observe the stacktrace :
android.app.Instrumentation.newActivity(Instrumentation.java:1021)
android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2175)
android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2261)
Code where new activity is instantiated :
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
... //More code
Activity activity = null;
try {
java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
StrictMode.incrementExpectedActivityCount(activity.getClass());
r.intent.setExtrasClassLoader(cl);
r.intent.prepareToEnterProcess();
if (r.state != null) {
r.state.setClassLoader(cl);
}
} catch (Exception e) {
if (!mInstrumentation.onException(activity, e)) {
throw new RuntimeException(
"Unable to instantiate activity " + component
+ ": " + e.toString(), e);
}
}
... //More code
return activity;
}
Instrumentation.java(class will be instantiated for you before any of the application code)
public Activity newActivity(ClassLoader cl, String className,
Intent intent)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
return (Activity)cl.loadClass(className).newInstance();
}
The simple way to check the path to the constructor method is to create a temporary project, override constructor in your Activity and place breakpoint there.
You should be able to walk through the all code and find what exactly you want.
As long as you are not in an interview for an Android system developer (kernel hacker, ...) the answer is simply: That is an implementation detail of the Android framework a normal Android developer should not need to care about because of the abstraction and layer principle and it can be looked up in the rare case you would really need to know it.
Android core is responsible to manage de activity instantiation, and manage it into his activity lifecycle.
The android system takes care about calling all the events you can control in your class in the correct order, add the activity to the stack and many other things.
When you call startActivity, Android core takes control and makes an activity instance (or reuse a previous one if match) and starts to call activity lifecycle events
You can see it here: http://developer.android.com/reference/android/app/Activity.html in Activity Lifecycle part
How can I force stop an app with Java? I'm trying to build a memory cleaner that can help clean out background processes.
I know there is a way to kill the process of an app, but when you go to the running list, the app is still there even after you have killed it. And I have tried a lot of similar memory cleaning apps, only one of them can totally force stop apps but it has so many useless notifications - very annoying.
P.S.: When you go to Settings -> Apps, you will see a list of apps. Click on one of these apps and you end up on the app's info. There is a button named "force stop". By clicking on it, the app is killed. I want to perform that kind of action in my app. How can this be done?
get the process ID of your application, and kill that process onDestroy() method
#Override
public void onDestroy()
{
super.onDestroy();
int id= android.os.Process.myPid();
android.os.Process.killProcess(id);
}
or
getActivity().finish();
System.exit(0);
and if you want to kill other apps from your activity, then this should work
You can send the signal using:
Process.sendSignal(pid, Process.SIGNAL_KILL);
To completely kill the process, it's recommended to call:
ActivityManager.killBackgroundProcesses(packageNameToKill)
before sending the signal.
Please, note that your app needs to own the KILL_BACKGROUND_PROCESSES permission. Thus, in the AndroidManifest.xml, you need to include:
<uses-permission android:name="android.permission.KILL_BACKGROUND_PROCESSES" />
Try to use following code
finish(); // for stopping Current Activity
// add this line for Removing Force Close
#Override
protected void onDestroy() {
// closing Entire Application
android.os.Process.killProcess(android.os.Process.myPid());
super.onDestroy();
}
}
May be this solution will help you Force Close an app programmatically
My company is developing a complex android project which is not available on google play. They sell tablets with the app already installed and the updates are done through our ftp.
Recently we've started having some sporadic crashes in field, that never happen when the tablet is connected to the computer (so I can never see the logcat). So I've implemented a crash report system that sends the logcat file and crash report through email, with uncaughtExceptionHandler called in onCreate of the main activity:
protected void onCreate(Bundle savedInstanceState) {
Thread.setDefaultUncaughtExceptionHandler(handleAppCrash);
super.onCreate(savedInstanceState);
}
private Thread.UncaughtExceptionHandler handleAppCrash = new Thread.UncaughtExceptionHandler() {
#Override
public void uncaughtException(Thread thread, Throwable ex) {
#crash report stuff here
};
};
Although pretty much all crashes are getting caught with this method, that specific and sporadic one which I'm searching for is not. The 'app has stopped' dialog appears, but this method is never called. After this I started using Splunk Mint (http://www.splunk.com/en_us/homepage.html), hoping that the library was more powerful, but I have the exact same behavior.
So my question is: which type of crashes are not caught with this uncaughtExceptionHandler? Could be a crash on Java itself? Is there a way to go around this to understand where the crash comes from?
Thank you!