I want to receive updates from GPS, but i can't. Method onLocationChanged isn't calling. In this application i using Google Maps API, too. I don't know, maybe it is some cause of my problems.
It's code about GPS in MainActivity:
LocationManager locationManager = (LocationManager) this.getSystemService(Context.LOCATION_SERVICE);
final LocationListener locationListener = new LocationListener() {
public void onLocationChanged(Location location)
{
txtLat.setText("Latitude: " + String.valueOf((int)(location.getLatitude())) + ","
+ String.valueOf(((location.getLatitude() * 100) % 100)) + " degrees");
txtLong.setText("Longtitude: " + String.valueOf((int)(location.getLongitude())) + ","
+ String.valueOf(((location.getLongitude() * 100) % 100)) + " degrees");
}
public void onStatusChanged(String provider, int status, Bundle extras) {}
public void onProviderEnabled(String provider) {}
public void onProviderDisabled(String provider) {}
};
locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 0, 0, locationListener);
and in Manifest i have declared these permissions:
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>
<uses-permission android:name="android.permission.ACCESS_MOCK_LOCATION" />
and other that Google Maps API v2 required
EDIT:
LogCat:
06-27 14:25:28.785: D/dalvikvm(5206): GC_FOR_ALLOC freed 42K, 8% free 2500K/2716K, paused 42ms, total 48ms
06-27 14:25:28.836: I/dalvikvm-heap(5206): Grow heap (frag case) to 6.147MB for 3712016-byte allocation
06-27 14:25:28.906: D/dalvikvm(5206): GC_FOR_ALLOC freed 2K, 4% free 6122K/6344K, paused 64ms, total 64ms
06-27 14:25:28.965: D/dalvikvm(5206): GC_CONCURRENT freed <1K, 4% free 6122K/6344K, paused 8ms+5ms, total 66ms
06-27 14:25:29.595: D/dalvikvm(5206): GC_CONCURRENT freed 3766K, 53% free 3523K/7464K, paused 24ms+46ms, total 149ms
06-27 14:25:30.025: D/dalvikvm(5206): GC_CONCURRENT freed 243K, 51% free 3681K/7464K, paused 5ms+5ms, total 52ms
06-27 14:25:30.045: E/Google Maps Android API(5206): Google Maps Android API v2 only supports devices with OpenGL ES 2.0 and above
06-27 14:25:30.385: D/dalvikvm(5206): GC_FOR_ALLOC freed 146K, 49% free 3826K/7464K, paused 39ms, total 40ms
06-27 14:25:30.685: D/dalvikvm(5206): GC_CONCURRENT freed 82K, 44% free 4234K/7464K, paused 16ms+26ms, total 133ms
06-27 14:25:31.066: D/libEGL(5206): Emulator without GPU support detected. Fallback to software renderer.
06-27 14:25:31.095: I/Choreographer(5206): Skipped 77 frames! The application may be doing too much work on its main thread.
06-27 14:25:31.115: D/libEGL(5206): loaded /system/lib/egl/libGLES_android.so
06-27 14:25:31.175: D/gralloc_goldfish(5206): Emulator without GPU emulation detected.
06-27 14:25:31.819: D/dalvikvm(5206): GC_CONCURRENT freed 402K, 41% free 4428K/7464K, paused 30ms+60ms, total 386ms
06-27 14:25:31.915: D/dalvikvm(5206): WAIT_FOR_CONCURRENT_GC blocked 428ms
06-27 14:25:32.427: D/dalvikvm(5206): GC_CONCURRENT freed 630K, 41% free 4429K/7464K, paused 31ms+18ms, total 100ms
06-27 14:25:32.427: D/dalvikvm(5206): WAIT_FOR_CONCURRENT_GC blocked 59ms
06-27 14:33:03.695: E/Trace(5381): error opening trace file: No such file or directory (2)
06-27 14:33:04.395: D/dalvikvm(5381): GC_FOR_ALLOC freed 46K, 9% free 2500K/2720K, paused 42ms, total 45ms
06-27 14:33:04.435: I/dalvikvm-heap(5381): Grow heap (frag case) to 6.147MB for 3712016-byte allocation
06-27 14:33:04.485: D/dalvikvm(5381): GC_FOR_ALLOC freed 2K, 4% free 6122K/6348K, paused 43ms, total 44ms
06-27 14:33:04.555: D/dalvikvm(5381): GC_CONCURRENT freed <1K, 4% free 6122K/6348K, paused 5ms+5ms, total 70ms
06-27 14:33:05.235: D/dalvikvm(5381): GC_CONCURRENT freed 3774K, 53% free 3500K/7448K, paused 20ms+84ms, total 157ms
06-27 14:33:05.615: D/dalvikvm(5381): GC_CONCURRENT freed 232K, 51% free 3663K/7448K, paused 72ms+5ms, total 118ms
06-27 14:33:05.645: E/Google Maps Android API(5381): Google Maps Android API v2 only supports devices with OpenGL ES 2.0 and above
06-27 14:33:05.875: D/dalvikvm(5381): GC_FOR_ALLOC freed 190K, 49% free 3847K/7448K, paused 39ms, total 40ms
06-27 14:33:06.268: D/dalvikvm(5381): GC_CONCURRENT freed 62K, 44% free 4223K/7448K, paused 71ms+77ms, total 284ms
06-27 14:33:06.815: D/libEGL(5381): Emulator without GPU support detected. Fallback to software renderer.
06-27 14:33:06.865: D/libEGL(5381): loaded /system/lib/egl/libGLES_android.so
06-27 14:33:06.906: I/Choreographer(5381): Skipped 120 frames! The application may be doing too much work on its main thread.
06-27 14:33:07.005: D/gralloc_goldfish(5381): Emulator without GPU emulation detected.
06-27 14:33:07.455: I/Choreographer(5381): Skipped 38 frames! The application may be doing too much work on its main thread.
06-27 14:33:07.545: D/dalvikvm(5381): GC_CONCURRENT freed 381K, 41% free 4427K/7448K, paused 8ms+111ms, total 349ms
06-27 14:33:07.545: D/dalvikvm(5381): WAIT_FOR_CONCURRENT_GC blocked 237ms
06-27 14:33:08.246: D/dalvikvm(5381): GC_CONCURRENT freed 630K, 41% free 4430K/7448K, paused 72ms+7ms, total 171ms
06-27 14:33:08.246: D/dalvikvm(5381): WAIT_FOR_CONCURRENT_GC blocked 32ms
If you're attempting to retrieve the location using the GPS provider, and you're inside a building or have lousy GPS reception, the onLocationChanged will never be called.
There will be no automatic fallback to Wifi or celltower.
Always check what kind of provider you are using, even when specifying criteria.
Google has released a bunch of new Location APIs through Google Play Services that offers more efficient ways of retrieving user location (improving accuracy and battery-life).
I suggest you take a look at those and follow the Retrieving the Current Location tutorial (it includes a sample app that you can download).
Related
I am creating Image apps which has over 4k images. I dont load images as required rather load when required however if user visits different parts of app which links to different images my app becomes slow and waits for GC to run which makes it bad user experience.
I saw logcat with following messages:
10-08 14:21:26.249: D/dalvikvm(31547): GC_FOR_ALLOC freed 1677K, 13% free 14097K/16124K, paused 29ms, total 29ms
10-08 14:21:26.749: D/dalvikvm(31547): GC_FOR_ALLOC freed 1711K, 13% free 14092K/16124K, paused 28ms, total 28ms
10-08 14:21:27.610: D/dalvikvm(31547): GC_FOR_ALLOC freed 1694K, 13% free 14103K/16124K, paused 29ms, total 29ms
10-08 14:21:29.592: D/dalvikvm(31547): GC_FOR_ALLOC freed 1729K, 13% free 14081K/16124K, paused 32ms, total 32ms
10-08 14:21:30.874: D/dalvikvm(31547): GC_FOR_ALLOC freed 1675K, 13% free 14102K/16124K, paused 30ms, total 30ms
10-08 14:21:32.435: D/dalvikvm(31547): GC_FOR_ALLOC freed 1735K, 13% free 14075K/16124K, paused 33ms, total 33ms
10-08 14:21:34.017: D/dalvikvm(31547): GC_FOR_ALLOC freed 1629K, 13% free 14145K/16124K, paused 28ms, total 29ms
10-08 14:21:35.098: D/dalvikvm(31547): GC_FOR_ALLOC freed 1774K, 13% free 14093K/16124K, paused 29ms, total 29ms
10-08 14:21:36.290: D/dalvikvm(31547): GC_FOR_ALLOC freed 1703K, 13% free 14094K/16124K, paused 29ms, total 29ms
10-08 14:21:37.991: D/dalvikvm(31547): GC_FOR_ALLOC freed 1722K, 13% free 14077K/16124K, paused 27ms, total 28ms
10-08 14:21:39.213: D/dalvikvm(31547): GC_FOR_ALLOC freed 1693K, 13% free 14083K/16124K, paused 28ms, total 28ms
10-08 14:21:41.175: D/dalvikvm(31547): GC_FOR_ALLOC freed 1696K, 13% free 14088K/16124K, paused 28ms, total 28ms
I tried to improve/optimize my code by doing following changes:
Everytime I load app I clear my cached images.
Implemented ViewHolder pattern for ListViews.
Used android:largeHeap="true" attribute in Manifest at Application tag level.
Made classes which are used frequently to do some operations singleton.
But still not able to achieve performance i need.
I used Universal Image Loader Library which has cache mechanism but still its runs GC.
How to avoid GC or what are other optimization techniques.
I am working with Google Maps v2 for Android.
I need to display some View over the map's marker, so I am updating its position every 16ms to keep 60fps.
And I got a problem with that code:
Point targetPosition = getMap().getProjection()
.toScreenLocation(mTrackingMarkerPos);
Because it seems that it causes explicitly calls to the System.gc() or Runtime.getRuntime().gc().
So I got this in log output:
03-12 15:00:24.362 19135-19135/my_fake_package_name D/dalvikvm﹕ GC_EXPLICIT freed 122K, 10% free 12710K/14116K, paused 11ms+11ms, total 115ms
03-12 15:00:25.583 19135-19135/my_fake_package_name D/dalvikvm﹕ GC_EXPLICIT freed 123K, 10% free 12711K/14116K, paused 7ms+4ms, total 100ms
03-12 15:00:26.845 19135-19135/my_fake_package_name D/dalvikvm﹕ GC_EXPLICIT freed 123K, 10% free 12711K/14116K, paused 11ms+6ms, total 104ms
03-12 15:00:28.056 19135-19135/my_fake_package_name D/dalvikvm﹕ GC_EXPLICIT freed 217K, 10% free 12710K/14116K, paused 11ms+5ms, total 98ms
03-12 15:00:29.287 19135-19135/my_fake_package_name D/dalvikvm﹕ GC_EXPLICIT freed 121K, 10% free 12712K/14116K, paused 11ms+7ms, total 112ms
03-12 15:00:30.499 19135-19135/my_fake_package_name D/dalvikvm﹕ GC_EXPLICIT freed 123K, 10% free 12712K/14116K, paused 7ms+4ms, total 87ms
03-12 15:00:31.760 19135-19135/my_fake_package_name D/dalvikvm﹕ GC_EXPLICIT freed 126K, 10% free 12711K/14116K, paused 7ms+4ms, total 130ms
As you can see, GC_EXPLICIT can pause my app for about 100ms!
So my approach to keep 60fps is not achievable because of Google Maps v2 :(
If I comment that line, GC_EXPLICIT calls will disappear. I think that problem in Google Maps v2, I checked their .class files but I did not find any calls to System.gc, so may be I am wrong...
If you know how to find call to the System.gc() I will be glad to know it too, or guys from Google can help me with this issue?
P.S. Asked this on gmaps-api-issues: https://code.google.com/p/gmaps-api-issues/issues/detail?id=6483&thanks=6483&ts=1394624273
in my simple app i am using 6 buttons and setting background with png.
Button btnGadgetmusic = (Button) findViewById(R.id.gadgetmusic);
btnGadgetmusic.setBackgroundResource(R.drawable.btnselectedsong);
minimum size of png is 13.5K and maximum size is 40K. When ever i try to run this app on emulator with version 2.3, i get "external allocation too large for this process" and interestningly if i run on honeycomb or on ICS then there is no problem.
So i am confused what should i do, should i ignore it, if not, do we have some better solution for that.
looking for your reply
EDIT Log File added
I/dalvikvm-heap(4190): Clamp target GC heap from 25.494MB to 24.000MB
D/dalvikvm(4190): GC_FOR_MALLOC freed <1K, 51% free 2647K/5379K, external 18806K/20812K, paused 28ms
D/dalvikvm(4190): GC_EXTERNAL_ALLOC freed <1K, 51% free 2647K/5379K, external 18806K/20812K, paused 49ms
I/dalvikvm-heap(4190): Clamp target GC heap from 25.833MB to 24.000MB
D/dalvikvm(4190): GC_FOR_MALLOC freed 0K, 51% free 2647K/5379K, external 19153K/20812K, paused 25ms
D/dalvikvm(4190): GC_EXTERNAL_ALLOC freed <1K, 51% free 2657K/5379K, external 19153K/20812K, paused 56ms
I/dalvikvm-heap(4190): Clamp target GC heap from 25.852MB to 24.000MB
D/dalvikvm(4190): GC_FOR_MALLOC freed <1K, 51% free 2657K/5379K, external 19162K/20812K, paused 24ms
D/dalvikvm(4190): GC_EXTERNAL_ALLOC freed 4K, 51% free 2671K/5379K, external 19162K/20812K, paused 69ms
I/dalvikvm-heap(4190): Clamp target GC heap from 25.887MB to 24.000MB
D/dalvikvm(4190): GC_FOR_MALLOC freed 0K, 51% free 2671K/5379K, external 19184K/20812K, paused 28ms
W/KeyCharacterMap(4190): No keyboard for id 0
W/KeyCharacterMap(4190): Using default keymap: /system/usr/keychars/qwerty.kcm.bin
W/KeyCharacterMap(4190): No keyboard for id 0
W/KeyCharacterMap(4190): Using default keymap: /system/usr/keychars/qwerty.kcm.bin
I/dalvikvm-heap(4190): Clamp target GC heap from 25.913MB to 24.000MB
D/dalvikvm(4190): GC_CONCURRENT freed 16K, 50% free 2697K/5379K, external 19184K/20812K, paused
3ms+35ms
I/dalvikvm-heap(4190): Clamp target GC heap from 25.942MB to 24.000MB
D/dalvikvm(4190): GC_CONCURRENT freed 13K, 50% free 2727K/5379K, external 19184K/20812K, paused 3ms+3ms
D/dalvikvm(4190): GC_EXTERNAL_ALLOC freed 2K, 50% free 2724K/5379K, external 19184K/20812K, paused 65ms
E/dalvikvm-heap(4190): 20736-byte external allocation too large for this process.
I/dalvikvm-heap(4190): Clamp target GC heap from 25.939MB to 24.000MB
E/GraphicsJNI(4190): VM won't let us allocate 20736 bytes
D/dalvikvm(4190): GC_FOR_MALLOC freed 0K, 50% free 2724K/5379K, external 19184K/20812K, paused 38ms
D/skia(4190): --- decoder->decode returned false
D/AndroidRuntime(4190): Shutting down VM
W/dalvikvm(4190): threadid=1: thread exiting with uncaught exception (group=0x40015560)
E/AndroidRuntime(4190): FATAL EXCEPTION: main
E/AndroidRuntime(4190): java.lang.OutOfMemoryError: bitmap size exceeds VM budget
I am trying to setup a android virtual device to test syncing with an activesync-server.
I followed these steps:
The problem is that syncing is not working at all, but there are no errors like connection errors ...
IMO the problem is that the virtual device only has a private IP, so the server never can send anything to it?
So I probably need some kind of forwarding, like here:
But I am not sure if that’s correct and I am also not sure which ports should be forwarded.
Here is the logcat, when I want to sync:
W/InputMethodManagerService( 148): Window already focused, ignoring focus gain of: com.android.internal.view.IInputMethodClient$Stub$Proxy#41302038 attribute=null
I/Choreographer( 274): Skipped 41 frames! The application may be doing too much work on its main thread.
D/dalvikvm( 477): GC_CONCURRENT freed 396K, 6% free 8392K/8903K, paused 15ms+7ms, total 527ms
D/dalvikvm( 274): GC_CONCURRENT freed 360K, 11% free 9493K/10567K, paused 29ms+48ms, total 142ms
I/EAS ContactsSyncAdapterService( 477): Contact sync requested for test#example.com
D/dalvikvm( 148): GREF has increased to 601
D/dalvikvm( 477): WAIT_FOR_CONCURRENT_GC blocked 0ms
I/Choreographer( 274): Skipped 33 frames! The application may be doing too much work on its main thread.
D/dalvikvm( 477): GC_EXPLICIT freed 333K, 7% free 8355K/8903K, paused 78ms+32ms, total 1269ms
I/EAS EmailSyncAdapterService( 477): performSync
I/EAS EmailSyncAdapterService( 477): Mail sync requested for test#example.com
D/dalvikvm( 460): WAIT_FOR_CONCURRENT_GC blocked 0ms
D/dalvikvm( 460): GC_EXPLICIT freed 216K, 5% free 8483K/8839K, paused 145ms+94ms, total 914ms
D/dalvikvm( 148): WAIT_FOR_CONCURRENT_GC blocked 0ms
D/dalvikvm( 148): GC_EXPLICIT freed 510K, 7% free 11338K/12167K, paused 8ms+35ms, total 323ms
D/dalvikvm( 274): GC_CONCURRENT freed 415K, 11% free 9486K/10567K, paused 25ms+28ms, total 125ms
E/Inbox[test#example.com]( 477): Uncaught exception in EasSyncServicejava.lang.ArrayIndexOutOfBoundsException: length=32; index=32
E/Inbox[test#example.com]( 477): Sync ended due to an exception.
D/dalvikvm( 477): GC_CONCURRENT freed 376K, 6% free 8420K/8903K, paused 5ms+18ms, total 66ms
I don't think this is a problem with your networking setup. It looks like you have an error in your Sync code, that is causing the process to stop:
E/Inboxtest#example.com: Uncaught exception in EasSyncServicejava.lang.ArrayIndexOutOfBoundsException: length=32; index=32
E/Inboxtest#example.com: Sync ended due to an exception.
>
Wrap this code in a try/catch block to understand what is happening better.
Why does Android system always call garbage collection every time I make a request to web server to get images? Although I did every actions are asynchronous. Calling GC too many times make my app delays when scrolling or fling.
Update: I guess Android system always call GC when you do something request to web server. Here is the log when using the Android default browser. Each time you click on a link GC will be called automatically.
03-08 16:36:19.530: D/dalvikvm(341): GC_FOR_ALLOC freed 2124K, 31% free 10780K/15623K, paused 49ms
03-08 16:36:19.590: D/dalvikvm(341): GC_FOR_ALLOC freed 0K, 20% free 12635K/15623K, paused 49ms
03-08 16:36:19.700: D/dalvikvm(341): GC_CONCURRENT freed 1K, 20% free 12635K/15623K, paused 3ms+4ms
03-08 16:36:22.610: D/dalvikvm(20845): GC_CONCURRENT freed 735K, 10% free 9018K/9991K, paused 2ms+6ms
03-08 16:36:25.620: D/dalvikvm(20845): GC_CONCURRENT freed 1046K, 12% free 8954K/10119K, paused 4ms+3ms
03-08 16:36:27.880: D/dalvikvm(2781): GC_EXPLICIT freed 263K, 7% free 6373K/6791K, paused 2ms+2ms
03-08 16:36:28.950: D/dalvikvm(20845): GC_CONCURRENT freed 884K, 12% free 8946K/10119K, paused 3ms+3ms
03-08 16:36:29.760: D/dalvikvm(20845): GC_CONCURRENT freed 861K, 12% free 8949K/10119K, paused 3ms+3ms
03-08 16:36:31.390: D/dalvikvm(285): GC_EXPLICIT freed 1275K, 38% free 20843K/33223K, paused 17ms+8ms
03-08 16:36:31.510: D/dalvikvm(20845): GC_CONCURRENT freed 810K, 12% free 8946K/10119K, paused 3ms+5ms
03-08 16:36:38.100: D/dalvikvm(20845): GC_CONCURRENT freed 730K, 11% free 9027K/10119K, paused 3ms+6ms
03-08 16:36:40.920: D/dalvikvm(20845): GC_CONCURRENT freed 864K, 12% free 8989K/10119K, paused 2ms+5ms
03-08 16:36:45.780: D/dalvikvm(20845): GC_FOR_ALLOC freed 620K, 12% free 8909K/10119K, paused 41ms
03-08 16:36:48.250: D/dalvikvm(20845): GC_FOR_ALLOC freed 499K, 12% free 9002K/10119K, paused 45ms
03-08 16:36:48.570: D/dalvikvm(20845): GC_FOR_ALLOC freed 225K, 13% free 8899K/10119K, paused 28ms
03-08 16:36:50.670: D/dalvikvm(20845): GC_FOR_ALLOC freed 388K, 12% free 8915K/10119K, paused 34ms
03-08 16:36:52.550: D/dalvikvm(20845): GC_FOR_ALLOC freed 511K, 11% free 9008K/10119K, paused 44ms
03-08 16:36:53.780: D/dalvikvm(20845): GC_FOR_ALLOC freed 273K, 12% free 8909K/10119K, paused 42ms
03-08 16:37:05.070: D/dalvikvm(569): GC_EXPLICIT freed 376K, 12% free 6207K/6983K, paused 2ms+2ms
03-08 16:37:25.550: D/dalvikvm(2549): GC_CONCURRENT freed 337K, 9% free 7198K/7879K, paused 2ms+3ms
03-08 16:37:31.330: D/dalvikvm(2549): GC_EXPLICIT freed 54K, 10% free 7143K/7879K, paused 7ms+2ms
03-08 16:38:45.630: D/dalvikvm(2549): GC_EXPLICIT freed 268K, 10% free 7161K/7879K, paused 7ms+2ms
Android GC is automatic, opaque, non-deterministic. Which means you have nothing can do on it.
Traditionally, this type of GC works like this.
Wait until enough garbages are generated.
If GC engine thinks it's time, it stops your app.
Clear the garbages
Resume your app.
Of course, this sucks for end-use UI and graphics.
So Google added incremental collection. Essentially, this is just doing above procedure more frequently with less garbages. So pause time itself would be short but collection itself happens a lot more frequently.
As a conclusion, garbage collection happens randomly, but very frequently. So it would look happening always for any of operations.
Practically, there's no guaranteed way to avoid GC lag on typical GC systems.