Exiting app in android

Finding the reason for the exit in Android Application

When working with an Android application, we might have to keep an eye on crashes or unwanted ways that the user exits the app. We use many third-party libraries to log exits in android.

Now, with Android R, we can log the exits in our app which can help us fix any issue that might exist in our app.

In this blog, we are going to talk, how we can log the exits of the user from our application.

Let’ s first discuss the type of crashes and exits we might see in our application. There can be a crash for an exception or maybe there might be an ANR that might lead your app to crash and drop users out of the application. The users might also exit the app intentionally when they have completed using the app.

Consider an example, let us say we are using WhatsApp and we want to log all the actions when a user exits the app. It can be a crash or an exception, or maybe a user action to close the app.

So, to get all the information we are going to use the ActivityManager .

But before that,

What is ActivityManager?

ActivityManager gives information about and interacts with, activities, services, and the containing process. Methods in this class give us certain information that we can use to debug our application.

So, first, I will create a project with MainActivity like,

Now, we will initialize the ActivityManager like,

Now, we will use ActivityManager to get the list of historic exit reasons for the app. To get the list, we will use,

Here, getHistoricalProcessExitReasons takes three parameters,

• Package name: Here, we passed the package name of our application
• PID: We passed 0 as default to get all the reasons
• Size: The size of the list of exit reasons. So, we will get a list of type ApplicationExitInfo with only one item.

Here the exitList returns the history of exit, not the exit information in real-time as it provides the historical data.

Now, let’s first set up the exitList to return us the cause and reason of our crashes.

In our onCreate(), I will add,

Since we have only one item in the list lastExitInformation will get the value from the list using .first()

Now, we will Log the exit reasons, time and description using,

• lastExitInformation will return an integer which corresponds to the reason of the crash
• Timestamp returns Time in Epoch and,
• The description returns the descriptive version of the crash.

Now, let’s add a TextView in XML file like,

and set the reason of crash to the textView using,

We are done setting up everything to get the historic exit reasons. Now, let’s start logging the reasons.

Case 1:

When we close the app from the recent app’s tray and then reopen the app again we would see the following log,

• Reason code is 10 which means, REASON_USER_REQUESTED.
• We got timestamp as well in our log and,
• We got the description as remove a task, as we removed the app from the recent app’s tray.

We can also see the reason code in the textView .

The reason code and its meaning are,

So, for example, if we get a crash the reason code would be 4 according to the above table.

Case 2:

When we get a crash in our application. So, first, let’s introduce a crash in our application. We will create a button using,

and on click of textView, we will invoke the button’s click listener like,

This would lead to a crash of our application because the button is not mapped to any widget in XML.

When we reopen the app again, the app will generate a log,

Here, the reason code is 4, which maps to REASON_CRASH from the above table and the description also specifies crash.

If any exception occurs as well, the reason code would be REASON_CRASH

Case 3:

Let us terminate the JVM using System.exit().

So, In on the click of textView, we will add System.exit() like,

This will terminate the app. When we reopen the app, it will generate a log like,

Here, we won’t see any description but the reason code is 1 which maps to REASON_EXIT_SELF. This means it terminated itself.

Case 4:

When our application gets ANR.

So, to generate an ANR we will run an infinite loop on click of textView using,

So, when App gets an ANR the Log generated would be,

Here, the reason code is 6, which means REASON_ANR.

These are a few cases where we can log our exits form our application.

In this blog, we are using the maximum size as 1. If we change it to any number more then 1, let’s say maybe 10. It will return the list of last 10 exit reasons information. To set max size to 10, we update the code,

This is how we can use getHistoricalProcessExitReasons to get the reasons for the exit of the app which might be very useful for developers to understand the user’s behavior of using the app or maybe checking for crashes.

Источник

What is the right way to close apps in Android?

I’m new to the Android platform, and this is probably a dumb question, but.

How do you close an app?

When I’m in an app, and I want to get out, I just click on «Home» and move on, but I just installed a Task Manager app, and I noticed everything is left running.

Is there a way to exit apps? Or do I need to use the Task Manager every time I exit something?

6 Answers 6

If you exit the app using the BACK button then it will call onDestroy() on the current Activity, If you press HOME it only calls onPause()
Don’t be too worried about it though, Activities won’t drain battery they are just left in memory so they can be opened faster in the future.

I wouldn’t recommend using one of those task killer apps Android is designed to keep that stuff in memory for a reason, using a task killer is only one more extra service tugging away at your battery.. What you need to watch out for is apps that run services in the background like twitter or email clients pulling their servers, any good app that has a service like that will have an option to turn it off.

I’m pretty sure that everything I’ve ever read says that the Back button is the right way to exit out of apps.

Pressing Home leaves them running in the background until Android decides that they’re not needed any more, which can be handy if you just need to switch between apps to check something (holding Home for a couple of seconds gives you the list of recently running apps you can switch back to on most phones) but coming out using the back button tells the app that you want it to close.

Some apps have an «Exit» option in their menus. Most don’t.

You don’t really need to worry about it. You can just go to whatever app you need next. Android does a pretty good job freeing up resources when required.

Activities don’t run in the background

In Android, activities (that is, the part of the app you can see) never run in the background. They can only run (and use battery power) while they’re on the screen. The activity stops running regardless of whether you use home or back to leave it. The only difference is what data Android asks the app to save, so neither option is «the right way». It just depends on what you want to do.

If you use home, Android leaves the app in the same state, so that if you come back to it later (e.g. through the recent apps list), it’ll still be in the same state you left it: on the same screen, with the same stuff shown. For example, if it’s an email app, and you were looking at one email, then it’ll remember which email that was, and show you the same one.

Eventually (after about half an hour), Android concludes that you’re not coming back to the app, so it resets this state: next time you start the app, it’ll start from the front/main screen. To continue the example, the email app will forget which email and folder you were looking at, and show you the inbox.

If you use back, you’re telling Android that you don’t want to come back to this view. It’ll destroy the information about what you were looking at right away. Next time you start the app, it’ll show the front screen (e.g. the inbox).

As others have said, apps can control the behaviour of the back button: for example, web browsers use it to go back in the browser history. What I’ve described is the default behaviour of the back button, and developers are urged to keep the behaviour like that to avoid being confusing.

Cached background processes

Whichever method you use, Android will leave the app in memory (but not running) for as long as it can. This is to be more efficient. When you come back to the app, if it’s still in memory, Android can run it again right away; if it isn’t still in memory, then Android has to spend time and energy loading the app from storage again.

In old Android versions, apps left in memory in the background this way were included in the list of «running apps». This is a little confusing for users — it makes people think the app is really still running — so newer versions call these apps «cached background processes», to make it clear they’re only cached, not running.

What about background apps?

Earlier on, I said that activities don’t run in the background. So how does your email client check for mail? As well as activities, apps can have services. Services don’t have any GUI for you to see or interact with, but they do run in the background. Usually, a service will only run infrequently, such as to check mail once an hour, but it’s possible for the app developer to run the service all the time, draining your battery.

Leaving an activity with back or home doesn’t change how Android treats any services from the same app: the service can continue to run, or be triggered later at a given time (next time the mail check is due).

Summary

In summary, it doesn’t really matter whether you use back or home: it only changes what the app shows you next time you run it. It doesn’t have an effect on battery use. Neither of them corresponds to «exiting» a program on your PC.

Источник

Get started with the Navigation component

This topic shows you how to set up and work with the Navigation component. For a high level overview of the Navigation component, see the Navigation overview.

Set up your environment

To include Navigation support in your project, add the following dependencies to your app’s build.gradle file:

Groovy

Kotlin

For information on adding other Architecture Components to your project, see Adding components to your project.

Create a navigation graph

Navigation occurs between your app’s destinations—that is, anywhere in your app to which users can navigate. These destinations are connected via actions.

A navigation graph is a resource file that contains all of your destinations and actions. The graph represents all of your app’s navigation paths.

Figure 1 shows a visual representation of a navigation graph for a sample app containing six destinations connected by five actions. Each destination is represented by a preview thumbnail, and connecting actions are represented by arrows that show how users can navigate from one destination to another.

Figure 1. A navigation graph that shows previews of six different destinations that are connected via five actions.

1. Destinations are the different content areas in your app.
2. Actions are logical connections between your destinations that represent paths that users can take.

To add a navigation graph to your project, do the following:

1. In the Project window, right-click on the res directory and select New > Android Resource File. The New Resource File dialog appears.
2. Type a name in the File name field, such as «nav_graph».
3. Select Navigation from the Resource type drop-down list, and then click OK.

When you add your first navigation graph, Android Studio creates a navigation resource directory within the res directory. This directory contains your navigation graph resource file ( nav_graph.xml , for example).

Navigation Editor

After adding a graph, Android Studio opens the graph in the Navigation Editor. In the Navigation Editor, you can visually edit navigation graphs or directly edit the underlying XML.

Figure 2. The Navigation Editor

1. Destinations panel: Lists your navigation host and all destinations currently in the Graph Editor.
2. Graph Editor: Contains a visual representation of your navigation graph. You can switch between Design view and the underlying XML representation in the Text view.
3. Attributes: Shows attributes for the currently-selected item in the navigation graph.

Click the Text tab to see the corresponding XML, which should look similar to the following snippet:

Источник

In-app updates

When your users keep your app up to date on their devices, they can try new features, as well as benefit from performance improvements and bug fixes. Although some users enable background updates when their device is connected to an unmetered connection, other users might need to be reminded to install updates. In-app updates is a Play Core library feature that prompts active users to update your app.

The in-app updates feature is supported on devices running Android 5.0 (API level 21) or higher, and requires your app to use Play Core library version 1.5.0 or higher. Additionally, in-app updates are only supported for Android mobile devices, Android tablets, and Chrome OS devices.

Update flows

Your app can use the Play Core library to support the following UX flows for in-app updates:

Flexible updates

Flexible updates provide background download and installation with graceful state monitoring. This UX flow is appropriate when it’s acceptable for the user to use the app while downloading the update. For example, you might want to encourage users to try a new feature that’s not critical to the core functionality of your app.

Figure 1. An example of a flexible update flow.

Immediate updates

Immediate updates are fullscreen UX flows that require the user to update and restart the app in order to continue using it. This UX flow is best for cases where an update is critical to the core functionality of your app. After a user accepts an immediate update, Google Play handles the update installation and app restart.

Figure 2. An example of an immediate update flow.

Support in-app updates in your app

Learn how to support in-app updates in your app, depending on your development environment:

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

Источник