I have a problem with my hybrid app. This is android application, which large part is webview with JS app. Everything works generally great, but on some devices things going worser after running 'www protection' in antivirus on this device. To enable this option user need to turn on accessibility service of this antivirus.
After that users have a lot of skipped frames, really laggy app.
At the beggining of investigation what's going on, I want to see all device processes to see that really antivirus process consumes a lot of CPU. How can I do this? In Android Studio profiler I can see only threads from my app package. In developer options I can see only which services are enabled.
Related
I'm trying to build a limited-functionality Android system for our device, which needs to boot quickly, but everything we do seems to slow it down.
For example, our device has no camera, no bluetooth, no wifi, but turning them off wholesale in various /system/etc/init/*.rc files seems to actually slow it down, due to the interdependencies of Android. The services that are turned off end up restarting, or causing timeouts in Settings, for example.
(Android is on the device for its' UI, not for its connectivity abilities.)
Do you have any suggestions for how to do this? Surely Android for cars, TVs and tablets have had to deal with these issues before.
You did not specify what you did exactly, but if you tried to not start HAL services on startup they might just be started dynamically later. If you are using Android 8 or newer you could merge multiple HALs in one process. But I doubt that this will give you any significant speed-up.
Android does provide a guide on how to optimize boot times: https://source.android.com/devices/tech/perf/boot-times. However, you will notice that they focus on the bootloader, kernel, file system, SELinux, and parallelizing init. The elephant in the room is Zygote. It takes forever to start because it preloads the whole Android SDK.
From its history, Android did not care too much about startup times, because you typically do not restart Android. Instead, they rely on Suspend-to-RAM.
You should think about what you want to have your user experience early. Example: for Automotive Android, Google needs to support a rear-view camera that is available within two seconds after boot. They achieve that by a second, faster stack that provides first images before the application SDK is started and takes over. See https://source.android.com/devices/automotive/camera-hal
Android website recommends to test an Android application on a real device before releasing it to others. Based on this I would like to know one thing:
When USB debugging is enabled on the device and android applications are tested in real time, does it have any effect on the functionality or performance of the Android phone?
What I mean to say functionality is, about the working speed, app failure or anything similar.
No, there is none or a little bit that you wont even notice. Your phone will still function normally. You can also use eclipse to log your phones performance and other things. The only thing the eclipse do when you debug the application is attach the debugger to your app and debug it. It will only install your app and lets you test and debug the app. No performance degradation is done. However the application will still occupy the memory on your phone. So it will definitely consume your internal memory like every other application does.
USB debugging allows you to use the debug in Eclipse or any other Android SDK you are using to test your application. You can have it set to allowed (USB debugging) and you won't even notice it. If anything, it will just drain your battery faster
From the perspective of an application it won't affect performance, but at platform level it can.
I've recently ported an application that is known to run with uptime of months (DIY Zoning Project) to Android (the accessory driver, the core process and the remote control). And, unfortunately, though techniques to keep running services alive were used (START_STICKY, startForeground()), sometimes the system^H service app just freezes up - until the user initiates an interaction with the service, after which it resumes normal operation. Most problematic is the fact that it is happening intermittently, and mostly after several days of uptime. The remote control works on the emulator for days at a time with no noticeable degradation, so the problem is most probably either in the service or in the accessory driver.
Currently, the system is targeted at API 10, so advanced service scheduling features are not available - that is, if they're related to the problem to begin with.
Now, what is the realistic way to debug and/or profile such a system? Remember, adb is not available for the Android hardware is connected to an ADK accessory.
Quite a late answer, however, did you try to use Wakelocks?
http://developer.android.com/reference/android/os/PowerManager.WakeLock.html
Possibly the system just hibernates the processor in some cases and it seems like "freezing up"
I hope you're all good. I am working on an android application project and I mostly use android emulator for testing the application. Android Emulator takes too much time for application loading and since I am working on the design I have to run the application after a few seconds again and again. Because of slow emulator I think my time is wasted and I can't focus on the work.
I recently tried my Galaxy Note for running application and its quite fast and running experience is much better. What I wanted to know is.. Does running eclipse project on my Phone will harm my mobile phone in any way?
Because moments back while using the phone the screen got stuck and the icons changed to different green, red and blue color. I restarted the phone and its acting normal now. But I wanted to know if it happened because of the eclipse project running on the phone? Is it safe ?
It is possible to harm your phone.
Apart from the wear and tear (YMMV) of repeatedly flashing your app to memory you may unwittingly (or otherwise) create a virus.
I've been in a situation where a thread has run amok after the app terminated and hogged the processor slowing things down. It did eventually quit though (possibly after elective rebooting). I've often had my phone restart when debugging on it. I wouldn't worry too much about that (although my domain was Samsung's bada, a lot less robust platform).
I don't see too many risks with Java apps as the language is so well managed. Native code is a risk in that, at least, a buffer overflow could place unwanted code outside of the process address space and so escape being cleaned up when the app quits. A shut down and/or force close may result from such errors.
why cant android os be more like apple os on the the ituch/iphone? where the app doesn't run until it is selected. it is also closed; stays closed until it is opened again.
i think this would make the android phones run faster and more efficiently(battery would last longer).
A lot of Android apps (I think most of them) run exactly as you describe it - they have an activity that is closed or suspended as soon as you leave it - a suspended Activity only consumes memory and can be discarded in an instant. (iOS does nearly the same)
Even on the iPhone there are applications that run in the background, the most prominent example being Mobile Safari. The difference is that only Apple can write applications that run in the background without restriction, and that a regular user has no way of monitoring these background apps. (this has led to massive overcharging issues in the case of users leaving Mobile Safari on a page where streaming content was loaded.)
There are legitimate use cases where you need an app to continue running in the background (downloading, uploading, playing music, waiting for a VoIP call) - none of it was possible for a third-party to do it on the iPhone until iOS4, making applications such as Pandora or Skype nearly useless.
For good or ill, Apple consistently restricts what third-party developers are allowed to do on iOS devices (App Store policy, private APIs, specialized APIs for background tasks mentioned in point 3). On the other hand, Google seems to prefer that third-party Android developers have access to the same APIs as Google's Android app developers.
The biggest Android performance problem IMO is responsiveness, the fixing of which is a lot more involved than saying "no Apps in Background thx". (See http://android-developers.blogspot.com/2010/12/new-gingerbread-api-strictmode.html for more information)
An Android developer's blog explains the reasoning behind Android multitasking.
We did not want to require that users close applications when "done" with them.
Mobile devices … have fairly hard limits on memory use.
These competing constraints were a key motivation for Android's design.
The fact that you can see an application's process "running" does not mean the application is running or doing anything.
The articles linked from there also have interesting things to say on the subject
The RadioActive Yak:
When should your app include an exit button? The Short Answer: Never.
Wickenden:
One of the first things the naive but technically inquisitive new android user does is begin to wonder how all the things they are running should be “shut down”.
Google’s android system has been designed for multi-tasking in ways that allow programs to be ready to respond to a changed environmental condition instantly (an alarm to wake you, a notification that you have arrived at your destination and so forth) as well as actually “running” and consuming resources when needed. Additionally the android system itself is smart about how it deals with low memory conditions and is capable of completely blowing away applications in such a way that their state is remembered and can be restored when there is more memory.
Task Killers (whose behavior is radically clipped in Android 2.2 “Froyo”) actually can cause harm by destroying a process that other apps need to function correctly.