I don't understand about this problem. My android application need to generate Custom button.
It can work if I have less than 144 buttons but if I generate button more over 144 buttons.
it can't work(Forcse Closed) and show error in log cast like this.....
ANR in com.Sanuk.mahjongandroid (com.Sanuk.mahjongandroid/.MainActivity)
Load: 0.92 / 1.0 / 0.83
CPU usage from 21998ms to 0ms ago:
98% 3225/com.Sanuk.mahjongandroid: 98% user + 0% kernel
0% 1141/com.android.voicedialer: 0% user + 0% kernel / faults: 30 minor
I'm sure, It 's not error in my code. What wrong?
The answer here is that you are freezing the UI Thread by doing too much thing. The UI Thread is the thread that is responsible for view painting on screen and intercepting touches from users. It should be as free as possible to get a fluid app.
If you have heavy processing to do like creating a lot of buttons, here are some alternatives :
use an AsyncTask, although here, you should take care of creating the button in the background, but adding them in the UI Thread.
why don't you use a list ?
Related
I am trying to read (and understand) the CPU usage provided by the top command in my Samsung Galaxy S7.
From another post here I can see the explanation of the top command with the output that this person is getting.
However, when I go inside my Samsung using adb shell and I cal the top command, what I get is different from what the other used posted.
Am I doing something different/wrong?
If not, how do I read this output from top??
The output from the user on the other post has this:
User 5%, system 15%, IOW 0%, IRQ 0%
User 5 + Nice 0 + Sys 14 + Idle 73 + IOW 0 + IRQ 0 + SIRQ 0 = 92
PID CPU% S #THR VSS RSS UID Name
213 11% R 1 900K 340K app_16 top
However, the output from my top gives me something like that:
Tasks: 371 total, 7 running, 359 sleeping, 0 stopped, 0 zombie
Mem: 3618604k total, 3545056k used, 73548k free, 118980k buffers
Swap: 2097148k total, 894520k used, 1202628k free, 1441660k cached
800%cpu 9%user 0%nice 11%sys 780%idle 0%iow 0%irq 0%sirq 0%host
Basically, I cannot see the row
User 5%, system 15%, IOW 0%, IRQ 0%
which seems to be the key to understand the CPU usage.
Not really sure why, but "top" command is not longer accepting params on Android 8
I am doing some memory testing and I came across procstats in my research - before I start using it though I would like to fully understand everything before I start relying on its data.
Here is a condensed file of what I am trying to work with:
CURRENT STATS:
* com.samsung.android.providers.context / u0a6:
TOTAL: 100% (4.2MB-4.2MB-4.2MB/3.3MB-3.3MB-3.3MB over 1)
Service: 100% (4.2MB-4.2MB-4.2MB/3.3MB-3.3MB-3.3MB over 1)
* com.sec.android.inputmethod / 1000:
TOTAL: 100% (28MB-28MB-28MB/27MB-27MB-27MB over 2)
Imp Fg: 100% (28MB-28MB-28MB/27MB-27MB-27MB over 2)
* com.google.android.googlequicksearchbox / u0a54:
TOTAL: 0.05%
Imp Bg: 0.05%
(Cached): 100% (4.8MB-4.9MB-5.0MB/3.2MB-3.3MB-3.4MB over 2)
* com.google.android.talk / u0a98:
TOTAL: 0.03%
Imp Bg: 0.03%
Receiver: 0.00%
(Cached): 100% (8.8MB-8.8MB-8.8MB/7.4MB-7.4MB-7.4MB over 2)
(Home): 100% (20MB-20MB-20MB/18MB-18MB-18MB over 1)
Run time Stats:
SOff/Norm: +24m36s393ms (running)
TOTAL: +24m36s393ms
Start time: 2014-12-08 14:22:50
Total elapsed time: +24m36s508ms (partial) libdvm.so chromeview
Here are the questions:
What does "over 1" / "over 2" mean?
What is the difference between Service, Imp Bg, Receiver, and Imp Fg?
Why doesn't every total list the RAM usage (com.google.android.talk for example)
What does 100% mean and what does .03% mean?
Why do only some have (Cached)/(Home)?
What does 100% (Cached)/(Home) mean?
What does "(partial) libdvm.so chromeview" mean?
Lastly, am I correct in assuming that (4.8MB-4.9MB-5.0MB/3.2MB-3.3MB-3.4MB) is (low pss - avg pss - high pss / low uss - avg uss - high uss)?
If anyone could shed any light on this is would be greatly appreciated. Thanks.
As a heads up, I've already read these two links.... android-developers.blogspot.com/2014/01/ and android.googlesource.com/platform/frameworks/base/+/master/core/ .... and a few other pages - these are still the questions that I have left over. Can anyone go into detail about all 8 questions?
Edit
So I have been trying to compare numbers between procstats and meminfo and it really only adds more questions.
Here is an excerpt from procstats
CURRENT STATS:
* com.dropbox.android:crash_uploader / u0a87:
TOTAL: 100% (4.8MB-4.8MB-4.9MB/3.9MB-3.9MB-3.9MB over 6)
Service: 100% (4.8MB-4.8MB-4.9MB/3.9MB-3.9MB-3.9MB over 6)
* com.mobileposse.client / u0a22:
TOTAL: 0.16%
Service: 0.13%
Receiver: 0.03%
(Cached): 98% (7.2MB-8.4MB-9.3MB/6.1MB-7.2MB-8.1MB over 7)
* com.android.chrome / u0a79:
TOTAL: 0.01%
Receiver: 0.01%
(Cached): 86% (5.2MB-5.2MB-5.4MB/4.4MB-4.4MB-4.4MB over 3)
Here is an excerpt from meminfo
Total PSS by process:
5524 kB: com.android.chrome (pid 7334)
4969 kB: com.dropbox.android:crash_uploader (pid 5617)
Now dropbox makes sense, and I would say 80% of the processes follow dropbox's lead with having matching numbers between meminfo and pocstats. What I don't get - why does chrome not have any totals in the procstats but is listed in the meminfo and why does mobileposse have higher stats than chrome in the procstats but is not listed in the meminfo?
Take a look to the sources linked by Alex P. You can find the answer to some questions there:
What does "over 1" / "over 2" mean?
That is the number of samples taken.
What is the difference between Service, Imp Bg, Receiver, and Imp Fg?
They are different states (Imp Bg means Important Background, and Imp Fg Important Foreground)
Why doesn't every total list the RAM usage (com.google.android.talk for example)
What does 100% mean and what does .03% mean?
% of the time that these apps have been running.
Why do only some have (Cached)/(Home)?
What does 100% (Cached)/(Home) mean?
What does "(partial) libdvm.so chromeview" mean?
Lastly, am I correct in assuming that (4.8MB-4.9MB-5.0MB/3.2MB-3.3MB-3.4MB) is (low pss - avg pss - high pss / low uss - avg uss - high uss)?
Yes, you are corrent, the documentation describes them as minPss-avgPss-maxPss / minUss-avgUss-maxUss
The percentages tell you how much of the overall time each process has spent in various key states. The memory numbers tell you about memory samples in those states, as minPss-avgPss-maxPss / minUss-avgUss-maxUss. The procstats tool also has a number of command line options to control its output — use adb shell dumpsys procstats -h to see a list of the available options.
Comparing this raw data from procstats with the visualization of its data we previously saw, we can see that it is showing only process run data from a subset of states: Imp Fg, Imp Bg, Service, Service Rs, and Receiver. These are the situations where the process is actively running in the background, for as long as it needs to complete the work it is doing. In terms of device memory use, these are the process states that tend to cause the most trouble: apps running in the background taking RAM from other things.
Quoted from: http://android-developers.blogspot.be/2014/01/process-stats-understanding-how-your.html Maybe you'll find more information using procstats -h or man procstats.
I am trying to monitor CPU usage using the top command in my android phone, using the following command:
Process p = Runtime.getRuntime().exec("top -m 15 -d 1 -n 1");
One of the output's of the top command I got is this:
User 2%, System 9%, IOW 0%, IRQ 0%
User 3 + Nice 0 + Sys 10 + Idle 95 + IOW 0 + IRQ 0 + SIRQ 0 = 108
PID PR CPU% S #THR VSS RSS PCY UID Name
743 0 15% R 1 2416K 948K bg u0_a692 top
15351 0 2% S 79 1921396K 114536K bg u0_a59 com.google.android.googlequicksearchbox:search
167 0 1% S 6 9668K 3512K logd /system/bin/logd
496 0 0% S 1 0K 0K root kworker/0:3
20447 0 0% S 1 0K 0K root kworker/u:34
I am using a Nexus 4 which has a quad core chip i.e. 4 CPUs
Here the total CPU usage is (intuitively) user + system = 11%. However, the top process itself takes 15% of the CPU. It happens most of the time. Here's a graph which I plotted using running the top command at an interval of 1s.
As seen in most cases, the top command uses more CPU than user and system CPU usage combined.
What causes this behavior?
I wanted to calculate how much CPU is used in an idle, sleep state. So, I thought of subtracting the CPU used by the top process from the combined CPU usage of user and system. But, having these kind of output cannot help me to determine exactly how much CPU the phone is using.
Also, is the CPU% of a process the total of user and system? i.e. if a process is utilizing 10% CPU, is it actually using something like 6% user and 4% system CPU?
In my Android application I am getting a very strange crash, when I press a button (Image) on my UI the entire application freezes and after a couple of seconds I getthe dreaded force close dialog appearing.
Here is what gets printed in the log:
WARN/WindowManager(88): Key dispatching timed out sending to package name/Activity
WARN/WindowManager(88): Dispatch state: {{KeyEvent{action=1 code=5 repeat=0 meta=0 scancode=231 mFlags=8} to Window{432bafa0 com.android.launcher/com.android.launcher.Launcher paused=false} # 1281611789339 lw=Window{432bafa0 com.android.launcher/com.android.launcher.Launcher paused=false} lb=android.os.BinderProxy#431ee8e8 fin=false gfw=true ed=true tts=0 wf=false fp=false mcf=Window{4335fc58 package name/Activity paused=false}}}
WARN/WindowManager(88): Current state: {{null to Window{4335fc58 package name/Activity paused=false} # 1281611821193 lw=Window{4335fc58 package name/Activity paused=false} lb=android.os.BinderProxy#434c9bd0 fin=false gfw=true ed=true tts=0 wf=false fp=false mcf=Window{4335fc58 package name/Activity paused=false}}}
INFO/ActivityManager(88): ANR in process: package name (last in package name)
INFO/ActivityManager(88): Annotation: keyDispatchingTimedOut
INFO/ActivityManager(88): CPU usage:
INFO/ActivityManager(88): Load: 5.18 / 5.1 / 4.75
INFO/ActivityManager(88): CPU usage from 7373ms to 1195ms ago:
INFO/ActivityManager(88): package name: 6% = 1% user + 5% kernel / faults: 7 minor
INFO/ActivityManager(88): system_server: 5% = 4% user + 1% kernel / faults: 27 minor
INFO/ActivityManager(88): tiwlan_wifi_wq: 3% = 0% user + 3% kernel
INFO/ActivityManager(88): mediaserver: 0% = 0% user + 0% kernel
INFO/ActivityManager(88): logcat: 0% = 0% user + 0% kernel
INFO/ActivityManager(88): TOTAL: 12% = 5% user + 6% kernel + 0% softirq
INFO/ActivityManager(88): Removing old ANR trace file from /data/anr/traces.txt
INFO/Process(88): Sending signal. PID: 1812 SIG: 3
INFO/dalvikvm(1812): threadid=7: reacting to signal 3
INFO/dalvikvm(1812): Wrote stack trace to '/data/anr/traces.txt'
This is the code for the Button (Image):
findViewById(R.id.endcallimage).setOnClickListener(new OnClickListener() {
public void onClick(View v) {
mNotificationManager.cancel(2);
Log.d("Handler", "Endcallimage pressed");
if(callConnected)
elapsedTimeBeforePause = SystemClock.elapsedRealtime() - stopWatch.getBase();
try {
serviceBinder.endCall(lineId);
} catch (RemoteException e) {
e.printStackTrace();
}
dispatchKeyEvent(new KeyEvent(KeyEvent.ACTION_DOWN,KeyEvent.FLAG_SOFT_KEYBOARD));
dispatchKeyEvent(new KeyEvent(KeyEvent.ACTION_UP, KeyEvent.KEYCODE_BACK));
}
});
If I comment the following out the pressing of the button (image) doesn't cause the crash:
try {
serviceBinder.endCall(lineId);
} catch (RemoteException e) {
e.printStackTrace();
}
The above code calls down through several levels of the app and into the native layer (NDK), could the call passing through several objects be leading to the force close? It seems unlikely as several other buttons do the same without issue.
How about the native layer? Could some code I've built with the NDK be causing the issue?
Any other ideas as to what the cause of the issue might be?
You must be as fast as possible in your onClick implementation. Expensive operations should be, in general, offloaded to a background thread.
In onClick, try:
Thread t = new Thread(){
public void run(){
your_stuff();
}
};
t.start();
instead of just
your_stuff()
You can encounter this error when you block the main thread (a.k.a. the UI thread) for a few seconds. Expensive operations should be, in general, offloaded to a background thread. AsyncTask is very helpful in these cases.
In your case you could do the following:
new AsyncTask<Void, Void, Void>() {
#Override
protected Void doInBackground(Void... params) {
try {
serviceBinder.endCall(lineId);
} catch (RemoteException e) {
e.printStackTrace();
}
}
}.execute();
Do your long Operation in a seperate thread or use AsyncTask to get rid of ANR.
An ANR(Activity Not Responding) happens when some long operation takes place in the "main" thread. This is the event loop thread, and if it is busy, Android cannot process any further GUI events in the application, and thus throws up an ANR dialog.
Your activity took to long to say to the Android OS 'hey i'm still alive'! (This is what the UI thread does).
http://developer.android.com/guide/practices/design/responsiveness.html
Basically if you make the UI thread do some complex task it's too busy doing your task to tell the OS that it is still 'alive'.
http://android-developers.blogspot.co.uk/2009/05/painless-threading.html
You should move your XML Parsing code to another thread, then use a callback to tell the UI thread you have finished and to do something with the result.
http://developer.android.com/resources/articles/timed-ui-updates.html
Detecting where ANRs happen is easy if it is a permanent block (deadlock acquiring some locks for instance), but harder if it's just a temporary delay. First, go over your code and look for vunerable spots and long running operations. Examples may include using sockets, locks, thread sleeps, and other blocking operations from within the event thread. You should make sure these all happen in separate threads. If nothing seems the problem, use DDMS and enable the thread view. This shows all the threads in your application similar to the trace you have. Reproduce the ANR, and refresh the main thread at the same time. That should show you precisely whats going on at the time of the ANR
If Logcat doesn't output anything usefull, try to pull traces.txt from /data/anr/traces.txt
adb pull /data/anr/traces.txt .
as it may give more information on where the ANR Exception occurrred
And this link may also helpful for creating AsyncTask and Threads
If you are doing a resource intensive task then it might happen. While resuming the Activity.
1. Try stopping all your intensive work on onPause and then restarting it on onResume.
2. If you are showing map on Activity drawing overlay on it then stop refreshing the overlays while on sleep. And then restart it on onResume.
In my Android application I am getting a very strange crash, when I press a button (Image) on my UI the entire application freezes and after a couple of seconds I getthe dreaded force close dialog appearing.
Here is what gets printed in the log:
WARN/WindowManager(88): Key dispatching timed out sending to package name/Activity
WARN/WindowManager(88): Dispatch state: {{KeyEvent{action=1 code=5 repeat=0 meta=0 scancode=231 mFlags=8} to Window{432bafa0 com.android.launcher/com.android.launcher.Launcher paused=false} # 1281611789339 lw=Window{432bafa0 com.android.launcher/com.android.launcher.Launcher paused=false} lb=android.os.BinderProxy#431ee8e8 fin=false gfw=true ed=true tts=0 wf=false fp=false mcf=Window{4335fc58 package name/Activity paused=false}}}
WARN/WindowManager(88): Current state: {{null to Window{4335fc58 package name/Activity paused=false} # 1281611821193 lw=Window{4335fc58 package name/Activity paused=false} lb=android.os.BinderProxy#434c9bd0 fin=false gfw=true ed=true tts=0 wf=false fp=false mcf=Window{4335fc58 package name/Activity paused=false}}}
INFO/ActivityManager(88): ANR in process: package name (last in package name)
INFO/ActivityManager(88): Annotation: keyDispatchingTimedOut
INFO/ActivityManager(88): CPU usage:
INFO/ActivityManager(88): Load: 5.18 / 5.1 / 4.75
INFO/ActivityManager(88): CPU usage from 7373ms to 1195ms ago:
INFO/ActivityManager(88): package name: 6% = 1% user + 5% kernel / faults: 7 minor
INFO/ActivityManager(88): system_server: 5% = 4% user + 1% kernel / faults: 27 minor
INFO/ActivityManager(88): tiwlan_wifi_wq: 3% = 0% user + 3% kernel
INFO/ActivityManager(88): mediaserver: 0% = 0% user + 0% kernel
INFO/ActivityManager(88): logcat: 0% = 0% user + 0% kernel
INFO/ActivityManager(88): TOTAL: 12% = 5% user + 6% kernel + 0% softirq
INFO/ActivityManager(88): Removing old ANR trace file from /data/anr/traces.txt
INFO/Process(88): Sending signal. PID: 1812 SIG: 3
INFO/dalvikvm(1812): threadid=7: reacting to signal 3
INFO/dalvikvm(1812): Wrote stack trace to '/data/anr/traces.txt'
This is the code for the Button (Image):
findViewById(R.id.endcallimage).setOnClickListener(new OnClickListener() {
public void onClick(View v) {
mNotificationManager.cancel(2);
Log.d("Handler", "Endcallimage pressed");
if(callConnected)
elapsedTimeBeforePause = SystemClock.elapsedRealtime() - stopWatch.getBase();
try {
serviceBinder.endCall(lineId);
} catch (RemoteException e) {
e.printStackTrace();
}
dispatchKeyEvent(new KeyEvent(KeyEvent.ACTION_DOWN,KeyEvent.FLAG_SOFT_KEYBOARD));
dispatchKeyEvent(new KeyEvent(KeyEvent.ACTION_UP, KeyEvent.KEYCODE_BACK));
}
});
If I comment the following out the pressing of the button (image) doesn't cause the crash:
try {
serviceBinder.endCall(lineId);
} catch (RemoteException e) {
e.printStackTrace();
}
The above code calls down through several levels of the app and into the native layer (NDK), could the call passing through several objects be leading to the force close? It seems unlikely as several other buttons do the same without issue.
How about the native layer? Could some code I've built with the NDK be causing the issue?
Any other ideas as to what the cause of the issue might be?
You must be as fast as possible in your onClick implementation. Expensive operations should be, in general, offloaded to a background thread.
In onClick, try:
Thread t = new Thread(){
public void run(){
your_stuff();
}
};
t.start();
instead of just
your_stuff()
You can encounter this error when you block the main thread (a.k.a. the UI thread) for a few seconds. Expensive operations should be, in general, offloaded to a background thread. AsyncTask is very helpful in these cases.
In your case you could do the following:
new AsyncTask<Void, Void, Void>() {
#Override
protected Void doInBackground(Void... params) {
try {
serviceBinder.endCall(lineId);
} catch (RemoteException e) {
e.printStackTrace();
}
}
}.execute();
Do your long Operation in a seperate thread or use AsyncTask to get rid of ANR.
An ANR(Activity Not Responding) happens when some long operation takes place in the "main" thread. This is the event loop thread, and if it is busy, Android cannot process any further GUI events in the application, and thus throws up an ANR dialog.
Your activity took to long to say to the Android OS 'hey i'm still alive'! (This is what the UI thread does).
http://developer.android.com/guide/practices/design/responsiveness.html
Basically if you make the UI thread do some complex task it's too busy doing your task to tell the OS that it is still 'alive'.
http://android-developers.blogspot.co.uk/2009/05/painless-threading.html
You should move your XML Parsing code to another thread, then use a callback to tell the UI thread you have finished and to do something with the result.
http://developer.android.com/resources/articles/timed-ui-updates.html
Detecting where ANRs happen is easy if it is a permanent block (deadlock acquiring some locks for instance), but harder if it's just a temporary delay. First, go over your code and look for vunerable spots and long running operations. Examples may include using sockets, locks, thread sleeps, and other blocking operations from within the event thread. You should make sure these all happen in separate threads. If nothing seems the problem, use DDMS and enable the thread view. This shows all the threads in your application similar to the trace you have. Reproduce the ANR, and refresh the main thread at the same time. That should show you precisely whats going on at the time of the ANR
If Logcat doesn't output anything usefull, try to pull traces.txt from /data/anr/traces.txt
adb pull /data/anr/traces.txt .
as it may give more information on where the ANR Exception occurrred
And this link may also helpful for creating AsyncTask and Threads
If you are doing a resource intensive task then it might happen. While resuming the Activity.
1. Try stopping all your intensive work on onPause and then restarting it on onResume.
2. If you are showing map on Activity drawing overlay on it then stop refreshing the overlays while on sleep. And then restart it on onResume.