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
Related
The problem seems to be known, but I could not find the right solution.
I will describe the scenario:
There is an application making requests to the API. In some FirstActivity, a request is made to the API, upon positive result of which startActivity () is called in SecondActivity. The problem is that if, while sending the request, the application is minimized to the background (that is, startActivity () will be called in the background), then:
If android version> = 29 then startActivity () basically won't work. The one following startActivity () finish () will work and upon restarting the application will restart (which is logical)
If the android version is < 29, then startActivity () will fire and bring this SecondActivity to the foreground.
Based on this, the question is. How can I force the application, regardless of version, to transition between activities and not bring them to the front?
Intent intent = new Intent(FirstActivity.this, SecondActivity.class);
startActivity(intent);
finish();
As per documentation
Android 10 (API level 29) and higher place restrictions on when apps
can start activities when the app is running in the background.
Workaround : In specific situations, your app might need to get the user's attention urgently, such as an ongoing alarm or incoming call. You might have previously configured your app for this purpose by launching an activity while your app was in the background.
To provide similar behavior on a device running Android 10 (API level 29) or higher, complete the steps described in this guide.
you can show a high-priority notification with a full-screen intent.
More Details
Updated answer for new requirement: For your comment
(Well, please tell me how to make startActivity () in the background start the activity also in the background, and not raise the application from the background)
you can add a LifecycleObserver that will be notified when the LifecycleOwner changes state.
Inside your activity api response callback use the following condition
if (lifecycle.currentState.isAtLeast(Lifecycle.State.RESUMED)) {
// Activity is in resumed state, Open new activity immediately
} else {
// else add a LifecycleObserver that will be notified when the LifecycleOwner changes state
lifecycle.addObserver(object : DefaultLifecycleObserver {
override fun onStart(owner: LifecycleOwner) {
super.onStart(owner)
// remove observer immediately so that it will not get triggered all the time
lifecycle.removeObserver(this)
// Activity is in start state again, Open new activity here
}
})
}
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
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.
I've implemented google drive into my android application and it work pretty nice, but I'm trying to figure out a way to run an upload/download in a background thread so that I can leave an activity and do something else on my app. The problem is, drive needs the activity reference in case of exceptions, such as UserRecoverableAuthIOException.
Here's the issue I cannot understand. Here's some try/catch code:
try {
//...drive api stuff here
} catch (UserRecoverableAuthIOException e) {
possibleException = e;
try {
e.getIntent();
} catch ( NullPointerException e2 ) { //this is the crazy part
// e.getIntent() should not throw a nullpointer
e2.printStackTrace();
possibleException = e2;
}
onActivityRestartWhat = RESTART_IMPORT;
// just a note i do handle this exception properly in another section of a code when there is an intent.
} catch (FileNotFoundException e) {
possibleException = e;
e.printStackTrace();
} catch (IOException e) {
possibleException = e;
e.printStackTrace();
}
What I can't figure out is why UserRecoverableAuthIOException is throwing a NullPointerException whey I try to access getIntent.
More Info
I do catch UserRecoverableAuthIOException when more authentication is needed and request it via the startActivityForResult method. Also, this exception is thrown only if I back out of the activity that has started, aka destroy the activity. Basically, I have a process that uploads/downloads drive files in a thread and if I don't leave the activity until completion it works, if I destroy the activity via the back button then I get this exception.
Stack Trace
07-10 14:45:32.903: W/System.err(1450): java.lang.NullPointerException
07-10 14:45:32.913: W/System.err(1450): at android.content.Intent.<init> (Intent.java:3529)
07-10 14:45:32.913: W/System.err(1450): at com.google.android.gms.auth.UserRecoverableAuthException.getIntent(Unknown Source)
07-10 14:45:32.913: W/System.err(1450): at com.google.api.client.googleapis.extensions.android.gms.auth.UserRecoverableAuthIOException.getIntent(UserRecoverableAuthIOException.java:62)
07-10 14:45:32.913: W/System.err(1450): at my.app.DriveHelper$2.run(DriveHelper.java:211)
My Desire
I want to run downloads/uploads (via google drive) in a background thread. Since the sdk requires startActivityForResult and other methods that might require a reference to an Activity or Context that makes this difficult, but it should work once the app has been granted the sdk permissions that require those references. Hopefully this makes sense.
Below are the steps you can follow to handle UserRecoverableAuthIOException Exception properly and you can even avoid getting that exception when back pressed.
In some cases if you are receiving that error mean the activity is destroyed so you shouldn't depend on the activity
You need to
create fresh com.google.api.services.tasks.Tasks object from
Context of Service not from any Activity directly like shown in 'tasks-android-sample'
When you get Exception
You need show a notification with PendingIntent from Service
PendingIntent should contain the reference to an Activity , say
HomeActivity
Activity should handle the intent extra and should do
the required things like showing choose account dialog
you can go through the sample code here (GoogleTasksService)
What you can do, in this case don't use multiple activities.
By switching to views you can achieve your task.
The title explains all... I have this snippet of code in my application:
String url = createTelUrl("3112007315");
Intent intent = new Intent(Intent.ACTION_CALL);
intent.setData(Uri.parse(url));
context.startActivity(intent);
It does make a call, but once the call ends, my application crashes. I'd like to return to my application once the call has finished, but I read this post and it seems not to be possible. So... is there anyway to at least pause my application and resume it once the call has finished?
EDIT:
Thanks for the two answers I received, I feel I'm really close to my goal... I had already done some of the things you guys suggested. But, maybe I didn't explain some details of the application... I'm developing Who Wants To Be A Millonarie game, so I need to implement calls (I don't know how it's called in USA or other countrys, but here we call it "call to a friend").
Anyway... I've done too many changes to this app and now it's not crashing. But, the Canvas where I draw the UI is not been showed once the called has ended.
I have a SurfaceView that holds the UI. For that SurfaceView I created a thread that is meant to refresh the UI... this is basically what the thread does:
#Override
public void run() {
Canvas c;
while (_run) {
c = null;
try {
c = _surfaceHolder.lockCanvas(null);
// Check if should wait
synchronized (_surfaceHolder) {
_panel.onDraw(c);
}
} finally {
// do this in a finally so that if an exception is thrown
// during the above, we don't leave the Surface in an
// inconsistent state
if (c != null) {
_surfaceHolder.unlockCanvasAndPost(c);
}
}
}
}
But, once the call has ended I get a black screen. The surface is there (I know it because it still can receive some touch events), but it's not showing anything. Another thing to take in account is how I'm starting the Thread from the SurfaceView class:
public void surfaceCreated(SurfaceHolder holder) {
hilo.setRunning(true);
try{
hilo.start();
}catch(IllegalThreadStateException ite){
Log.e("wwtbam", "god dammed");
}
}
This worked nice before I start implementing phone-calls. The problem here is that once the call has ended and it executes again the start method which throws a IllegalThreadStateException because the thread has already been started. I've tried using some 'technics' to pause the UI thread while calling but I haven't been able to solve this problem. I tried doing something like:
// this in the UI thread class
if(haveToWait)
wait();
....
// this in the surface view class
if(callEnded)
hilo.notify();
But that didn't work. I also have tried some other 'tricks' like using sleep(50); instead of wait(); but it does not work either.
With all that information I provided... what could you suggest to me?
The problem here is the place you're using to start the thread. Once you start a new call, your main activity will be paused and the surfaceview will be destroyed. Though, the thread will keep running. So, once your app takes the control back, the surface is created again and the start method will be invoked. That causes a IllegalThreadStateException.
The way to go here is to manipulate the thread out of the SurfaceView class. That will give you the control of the thread from the main activity, and you will be able to decide when to start or pause your thread.
Take a look of this example: http://code.google.com/p/apps-for-android/source/browse/trunk/SpriteMethodTest/src/com/android/spritemethodtest/
This is possible using an android.telephony.PhoneStateListener.
First, we need to take care of the manifest of the app:
We need the permission to make calls (duh!) as well as the permission to watch the phone state. The latter is needed so the app can react to the ending of a call as well. So we add these lines to out application manifest:
<uses-permission android:name="android.permission.CALL_PHONE" />
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
Also, we don't want Android to start a different instance of our activity when the call has ended, so we set the launchMode attribute of the activity to "singleInstance".
<activity android:name=".CallTest" android:label="Calling Test"
android:launchMode="singleInstance" />
Having prepared everything in the manifest, we can now look at the activity making the call:
public class CallTest extends Activity {
PhoneStateListener mListener;
TelephonyManager mTelMgr;
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
mListener = new CallEndedListener();
mTelMgr = (TelephonyManager) this.getSystemService(TELEPHONY_SERVICE);
}
public void makecall(View v) {
// Register our listener to be notified of the beginning
// and ending of calls
mTelMgr.listen(mListener, PhoneStateListener.LISTEN_CALL_STATE);
// Start the call
Intent call = new Intent(Intent.ACTION_CALL);
call.setData(Uri.parse("tel:12345"));
startActivity(call);
}
class CallEndedListener extends PhoneStateListener {
boolean called = false;
#Override
public void onCallStateChanged(int state, String incomingNumber) {
super.onCallStateChanged(state, incomingNumber);
// Don't fire before the call was made
if (state == TelephonyManager.CALL_STATE_OFFHOOK)
called = true;
// Call has ended -- now bring the activity back to front
if (called && state == TelephonyManager.CALL_STATE_IDLE) {
called = false;
mTelMgr.listen(this, PhoneStateListener.LISTEN_NONE);
startActivity(new Intent(CallTest.this, CallTest.class));
}
}
}
}
The only new thing in the makecall method, compared to the code snippet in the question, is the PhoneStateListener implementation added right before actually making the call. This listener then gets notified by Android when an outgoing call is dialed, an incoming call is ringing or when an active call is ended.
Our implementation waits for the latter CALL_STATE_IDLE event and starts our activity again, so that after the call has ended we're back in our app where we left it. It then deregisters itself, so our activity doesn't get restarted every time the user ends a call not initiated by our own activity.
However, when registering for the CALL_STATE-events with the TelephonyManager, Android instantly fires a notification with the current status -- so our listener would get triggered before the call had even started. Therefore our listener implementation first waits until an outgoing call was started (CALL_STATE_OFFHOOK) and only after that happened reacts to the CALL_STATE_IDLE notification.
HTH!
As for the crash - please post the log and put your debugger onStart/onResume to find out why you're crashing. It's possible that something is initialized in the wrong place and you might something as simple as nullpointer.
As for the call end thing - i've never try this, but i'd try to register receiver, catch
http://developer.android.com/reference/android/telephony/TelephonyManager.html#ACTION_PHONE_STATE_CHANGED
Evaluate the state of the phone and do what you need to do .
Also there is more info here
http://developer.android.com/reference/android/telephony/
http://developer.android.com/reference/android/telephony/PhoneStateListener.html
And finally you'll find examples of how to use that in the applications that are use that functionality in source.android.com