ACRA report not found on own server

ACRA report not found on own server - android

I have implemented ACRA using this
I have added code in my application, log is saying that report file is uploaded
here is the log :
05-04 11:38:02.890: D/dalvikvm(3171): GC_FOR_ALLOC freed 0K, 9% free 6508K/7111K, paused 18ms, total 18ms
05-04 11:38:02.900: D/ACRA(3171): About to start ReportSenderWorker from #handleException
05-04 11:38:02.900: D/ACRA(3171): Mark all pending reports as approved.
05-04 11:38:02.900: D/ACRA(3171): Looking for error files in /data/data/com.white.xspl.sonyjive/files
05-04 11:38:02.900: D/ACRA(3171): #checkAndSendReports - start
05-04 11:38:02.900: D/ACRA(3171): Looking for error files in /data/data/com.white.xspl.sonyjive/files
05-04 11:38:02.910: I/ACRA(3171): Sending file 1399183682000-approved.stacktrace
05-04 11:38:02.930: D/dalvikvm(3171): GC_FOR_ALLOC freed 83K, 9% free 6498K/7111K, paused 19ms, total 20ms
05-04 11:38:02.930: D/ACRA(3171): Waiting for Toast + worker...
05-04 11:38:02.970: D/dalvikvm(3171): GC_FOR_ALLOC freed 82K, 9% free 6484K/7111K, paused 20ms, total 20ms
05-04 11:38:03.000: D/dalvikvm(3171): GC_FOR_ALLOC freed 16K, 9% free 6531K/7111K, paused 20ms, total 20ms
05-04 11:38:03.000: I/dalvikvm-heap(3171): Grow heap (frag case) to 6.486MB for 65552-byte allocation
05-04 11:38:03.030: D/dalvikvm(3171): GC_FOR_ALLOC freed 76K, 10% free 6519K/7239K, paused 28ms, total 28ms
05-04 11:38:03.030: D/ACRA(3171): Connect to http://mylocal.ip/reportpath
05-04 11:38:03.120: D/dalvikvm(3171): GC_CONCURRENT freed 379K, 10% free 6535K/7239K, paused 23ms+2ms, total 52ms
05-04 11:38:03.120: D/dalvikvm(3171): WAIT_FOR_CONCURRENT_GC blocked 29ms
05-04 11:38:03.150: D/dalvikvm(3171): GC_FOR_ALLOC freed 77K, 11% free 6501K/7239K, paused 22ms, total 22ms
05-04 11:38:03.160: D/ACRA(3171): Sending request to http://mylocal.ip/reportpath
05-04 11:38:03.250: D/ACRA(3171): #checkAndSendReports - finish
05-04 11:38:03.350: D/ACRA(3171): Wait for Toast + worker ended. Kill Application ? true
Don't know what going wrong please help..
This is what i added in Manifest
<application
android:name=".MyAppication"
android:allowBackup="true"
android:icon="#drawable/appicon"
android:label="#string/app_name"
android:theme="#style/Theme.Sherlock" >
here is my Class
public class MyAppications extends Application {
#Override
public void onCreate() {
// The following line triggers the initialization of ACRA
super.onCreate();
ACRA.init(this);
}
}

I think you need to look at your server.
ACRA says that it has sent the error report to http://mylocal.ip/reportpath
What does the server that is listening at that address say in its logs?

Related

Volley - parseNetworkResponse OutOfMemoryError

I am using Volley to manage my app. Sometimes when a response is to large, I will get an OOM on devices with no much RAM. I am unsure how to resolve this. I understand Volley stores its responses in memory but I have my app wrapped around Volley so much that it would be a pain to switch. I had issues using Retrofit too. I have tried using a JsonReader but it still seems to happen. I have a custom request used with Volley. It returns a Gson JsonObject. Here is my code currently, the app is receiving an OOM when the response data length is returning 5511532 (5mb).
#Override
protected Response<T> parseNetworkResponse(NetworkResponse response) {
try {
String json = new String(response.data, HttpHeaderParser.parseCharset(response.headers));
if (LOG_HEADERS) {
Log.d("GsonResponseHeaders", response.headers.toString());
}
if (LOG_JSON) {
Log.d("GsonRequestResponse", json);
}
return Response.success(gson.fromJson(json, clazz), HttpHeaderParser.parseCacheHeaders(response));
} catch (UnsupportedEncodingException e) {
return Response.error(new ParseError(e));
} catch (JsonSyntaxException e) {
return Response.error(new ParseError(e));
} catch (OutOfMemoryError e) {
Log.d("ResponseLength", "-- " + response.data.length);
return Response.error(new ParseError(e));
}
}
EDIT:
Here is a sample response that throws OOM.
GsonRequestResponse: {"user_company_info":[{"id":"1","company_id":"5","circle_id":"34","status":"A","cat_id":"1","company_map":"0","timestamp":"2015-07-09 15:28:40","added_by":"1","add_date":"0000-00-00","name":"FSM","added_datetime":"2014-02-12 16:16:51","clause":"fsm_company","company_name":"Assero Services LLC - FSM","circles":[{"id":"1","company_id":"5","circle_id":"34","status":"A","cat_id":"1","company_map":"0","timestamp":"2015-07-09 15:28:40","added_by":"1","add_date":"0000-00-00","circle_name":"Cityside - HUD Contract Area - 5D","create_by":"2536","create_date":"0000-00-00","circle_owner":"0","circle_owner_company":"26792","circle_company_identifier":"0","level":"OUTER","assign_fsm":"26792","assign_client":"25491","assign_am":"0","routine_1":"10065","routine_2":"10209","routine_3":"10062","routine_4":"0","image_duplicate_api":"Y","routine_1_type":null,"routine_1_method":null,"routine_1_cancel_buffer":null,"routine_2_type":null,"routine_2_method":null,"routine_2_cancel_buffer":null,"routine_3_type":null,"routine_3_method":null,"routine_3_cancel_buffer":null,"routine_4_type":null,"routine_4_method":null,"routine_4_cancel_buffer":null,"name":"FSM","added_datetime":"2014-02-12 16:16:51","clause":"fsm_company","can_issue":"1"},{"id":"1","company_id":"5","circle_id":"33","status":"A","cat_id":"1","company_map":"0","timestamp":"2015-07-09 15:28:40","added_by":"1","add_date":"0000-00-00","circle_name":"Cityside - HUD Contract Area - 4D","create_by":"2536","create_date":"0000-00-00","circle_owner":"0","circle_owner_company":"26792","circle_company_identifier":"0","level":"OUTER","assign_fsm":"26792","assign_client":"25491","assign_am":"0","routine_1":"10065","routine_2":"10209","routine_3":"10062","routine_4":"0","image_duplicate_api":"Y","routine_1_type":null,"routine_1_method":null,"routine_1_cancel_buffer":null,"routine_2_type":null,"routine_2_method":null,"routine_2_cancel_buffer":null,"routine_3_type":null,"routine_3_method":null,"routine_3_cancel_buffer":null,"routine_4_type":null,"routine_4_method":null,"routine_4_cancel_buffer":null,"name":"FSM","added_datetime":"2014-02-12 16:16:51","clause":"fsm_company","can_issue":"2"},{"id":"1","company_id":"5","circle_id":"32","status":"A","cat_id":"1","company_map":"0","timestamp":"2015-07-09 15:28:40","added_by":"1","add_date":"0000-00-00","circle_name":"Cityside - HUD Contract Area - 2D","create_by":"2536","create_date":"0000-00-00","circle_owner":"0","circle_owner_company":"26792","circle_company_identifier":"0","level":"OUTER","assign_fsm":"26792","assign_client":"25491","assign_am":"0","routine_1":"10065","routine_2":"10209","routine_3":"0","routine_4":"0","image_duplicate_api":"Y","routine_1_type":null,"routine_1_method":null,"routine_1_cancel_buffer":null,"routine_2_type":null,"routine_2_method":null,"routine_2_cancel_buffer":null,"routine_3_type":null,"routine_3_method":null,"routine_3_cancel_buffer":null,"routine_4_type":null,"routine_4_method":null,"routine_4_cancel_buffer":null,"name":"FSM","added_datetime":"2014-02-12 16:16:51","clause":"fsm_company","can_issue":"1"}
EDIT:
Hey guys, so I tried splitting up my responses. It seemed to help but after 3-4 requests it still gives me an OOM. I believe it has something to do with Volley. Here is my GC for each response, it grows each time. Notice that the heap grows each time. I put some spacing between those so you can see the heap log.
10-12 06:52:21.236 23515-23515/com.droid.visneta D/RequestQueue: batch_open_orders_request started...
10-12 06:52:21.236 23515-23855/com.droid.visneta D/GsonCustomHeaders: {UserSession=source=Android-ffffffff-83d1-3e36-ffff-ffff99d603a9,id=6,token=9eb7c26405defb48fe884cfef8000696}
10-12 06:52:21.236 23515-23855/com.droid.visneta I/qtaguid: Failed write_ctrl(t -1 4883184842671390720 -1) res=-1 errno=9
10-12 06:52:21.236 23515-23855/com.droid.visneta I/qtaguid: Tagging socket -1 with tag 43c48ebe00000000(1136955070) for uid -1 failed errno=-9
10-12 06:52:21.236 23515-23855/com.droid.visneta I/NetworkManagementSocketTagger: tagSocketFd(-1, 1136955070, -1) failed with errno-9
10-12 06:52:21.936 23515-23855/com.droid.visneta I/System.out: Removed SSLv3 from enabled protocols
10-12 06:52:21.976 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 1990K, 15% free 33771K/39495K, paused 11ms+1ms, total 38ms
10-12 06:52:29.940 23515-23855/com.droid.visneta I/qtaguid: Failed write_ctrl(u -1) res=-1 errno=9
10-12 06:52:29.940 23515-23855/com.droid.visneta I/qtaguid: Untagging socket -1 failed errno=-9
10-12 06:52:29.940 23515-23855/com.droid.visneta W/NetworkManagementSocketTagger: untagSocket(-1) failed with errno -9
10-12 06:52:31.808 23515-23855/com.droid.visneta D/dalvikvm: GC_FOR_ALLOC freed 747K, 14% free 34267K/39495K, paused 18ms, total 18ms
10-12 06:52:32.616 23515-23855/com.droid.visneta D/dalvikvm: GC_FOR_ALLOC freed 596K, 12% free 34778K/39495K, paused 21ms, total 21ms
10-12 06:52:32.616 23515-23855/com.droid.visneta I/dalvikvm-heap: Grow heap (frag case) to 36.423MB for 2093068-byte allocation
10-12 06:52:32.648 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 10K, 12% free 36811K/41543K, paused 10ms+1ms, total 29ms
10-12 06:52:32.648 23515-23855/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 9ms
10-12 06:52:33.272 23515-23855/com.droid.visneta D/dalvikvm: GC_FOR_ALLOC freed 1122K, 14% free 35790K/41543K, paused 20ms, total 20ms
10-12 06:52:33.272 23515-23855/com.droid.visneta D/Volley: [212] BasicNetwork.logSlowRequests: HTTP response for request=<[ ] https://dev.visneta.com/amf/gateway?contentType=application/json 0x43c48ebe NORMAL 2> [lifetime=12039], [size=1652746], [rc=200], [retryCount=0]
10-12 06:52:33.296 23515-23855/com.droid.visneta D/dalvikvm: GC_FOR_ALLOC freed 2048K, 15% free 35360K/41543K, paused 22ms, total 22ms
10-12 06:52:33.296 23515-23855/com.droid.visneta I/dalvikvm-heap: Grow heap (frag case) to 38.149MB for 3305504-byte allocation
10-12 06:52:33.340 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 1K, 14% free 38586K/44807K, paused 11ms+11ms, total 43ms
10-12 06:52:33.392 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 555K, 11% free 40078K/44807K, paused 11ms+0ms, total 33ms
10-12 06:52:33.392 23515-23855/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 9ms
10-12 06:52:33.448 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 558K, 8% free 41568K/44807K, paused 11ms+1ms, total 36ms
10-12 06:52:33.448 23515-23855/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 15ms
10-12 06:52:33.504 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 564K, 4% free 43050K/44807K, paused 12ms+1ms, total 38ms
10-12 06:52:33.504 23515-23855/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 15ms
10-12 06:52:33.560 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 561K, 3% free 44537K/45575K, paused 10ms+1ms, total 38ms
10-12 06:52:33.560 23515-23855/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 8ms
10-12 06:52:33.616 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 577K, 3% free 46056K/47111K, paused 11ms+0ms, total 38ms
10-12 06:52:33.624 23515-23855/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 9ms
10-12 06:52:33.676 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 550K, 3% free 47555K/48583K, paused 11ms+1ms, total 38ms
10-12 06:52:33.676 23515-23855/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 16ms
10-12 06:52:33.764 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 4602K, 11% free 45006K/50119K, paused 11ms+12ms, total 58ms
10-12 06:52:33.840 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 2055K, 11% free 44998K/50119K, paused 10ms+0ms, total 45ms
10-12 06:52:33.840 23515-24293/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 26ms
10-12 06:52:33.916 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 2057K, 11% free 44988K/50119K, paused 11ms+1ms, total 43ms
10-12 06:52:33.916 23515-24293/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 21ms
10-12 06:52:33.988 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 2044K, 11% free 44991K/50119K, paused 11ms+1ms, total 41ms
10-12 06:52:33.988 23515-24293/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 21ms
10-12 06:52:34.056 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 2037K, 11% free 45002K/50119K, paused 11ms+1ms, total 41ms
10-12 06:52:34.060 23515-24293/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 8ms
10-12 06:52:34.132 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 2050K, 11% free 44995K/50119K, paused 11ms+0ms, total 42ms
10-12 06:52:34.132 23515-24293/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 8ms
10-12 06:52:34.216 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 2017K, 11% free 45026K/50119K, paused 11ms+11ms, total 53ms
10-12 06:52:34.216 23515-24293/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 2ms
10-12 06:52:34.284 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 2067K, 11% free 45004K/50119K, paused 11ms+0ms, total 40ms
10-12 06:52:34.288 23515-24293/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 23ms
10-12 06:52:34.372 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 2028K, 11% free 45000K/50119K, paused 11ms+12ms, total 54ms
10-12 06:52:34.452 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 2036K, 11% free 45012K/50119K, paused 12ms+1ms, total 48ms
10-12 06:52:34.452 23515-24293/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 4ms
10-12 06:52:34.524 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 2056K, 11% free 45003K/50119K, paused 12ms+0ms, total 41ms
10-12 06:52:34.524 23515-24293/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 22ms
10-12 06:52:34.596 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 2042K, 11% free 45004K/50119K, paused 11ms+1ms, total 43ms
10-12 06:52:34.600 23515-24293/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 18ms
10-12 06:52:34.668 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 2041K, 11% free 45009K/50119K, paused 11ms+1ms, total 42ms
10-12 06:52:34.668 23515-24293/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 21ms
10-12 06:52:34.744 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 2049K, 11% free 45007K/50119K, paused 11ms+1ms, total 41ms
10-12 06:52:34.744 23515-24293/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 19ms
10-12 06:52:34.776 23515-24293/com.droid.visneta D/BatchOpenOrders: 2000 open wos batched.
10-12 06:52:34.776 23515-23515/com.droid.visneta D/Routine Services Count: 1411
10-12 06:52:34.776 23515-23515/com.droid.visneta D/Open Order Count: 2000
10-12 06:52:37.288 23515-23515/com.droid.visneta D/RequestQueue: batch_open_orders_request started...
10-12 06:52:37.288 23515-23856/com.droid.visneta D/GsonCustomHeaders: {UserSession=source=Android-ffffffff-83d1-3e36-ffff-ffff99d603a9,id=6,token=9eb7c26405defb48fe884cfef8000696}
10-12 06:52:37.288 23515-23856/com.droid.visneta I/qtaguid: Failed write_ctrl(t -1 4883184842671390720 -1) res=-1 errno=9
10-12 06:52:37.288 23515-23856/com.droid.visneta I/qtaguid: Tagging socket -1 with tag 43c48ebe00000000(1136955070) for uid -1 failed errno=-9
10-12 06:52:37.288 23515-23856/com.droid.visneta I/NetworkManagementSocketTagger: tagSocketFd(-1, 1136955070, -1) failed with errno-9
10-12 06:52:37.592 23515-23856/com.droid.visneta I/System.out: Removed SSLv3 from enabled protocols
10-12 06:52:42.612 23515-23856/com.droid.visneta I/qtaguid: Failed write_ctrl(u -1) res=-1 errno=9
10-12 06:52:42.616 23515-23856/com.droid.visneta I/qtaguid: Untagging socket -1 failed errno=-9
10-12 06:52:42.616 23515-23856/com.droid.visneta W/NetworkManagementSocketTagger: untagSocket(-1) failed with errno -9
10-12 06:52:42.924 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 1779K, 10% free 45206K/50119K, paused 11ms+1ms, total 42ms
10-12 06:52:43.724 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 1104K, 9% free 46034K/50119K, paused 10ms+0ms, total 39ms
10-12 06:52:43.816 23515-23856/com.droid.visneta D/dalvikvm: GC_FOR_ALLOC freed 15K, 9% free 46033K/50119K, paused 28ms, total 28ms
10-12 06:52:43.816 23515-23856/com.droid.visneta I/dalvikvm-heap: Grow heap (frag case) to 47.417MB for 2095116-byte allocation
10-12 06:52:43.852 23515-23518/com.droid.visneta D/dalvikvm: GC_CONCURRENT freed 8K, 8% free 48071K/52167K, paused 12ms+1ms, total 38ms
10-12 06:52:43.852 23515-23856/com.droid.visneta D/dalvikvm: WAIT_FOR_CONCURRENT_GC blocked 16ms
10-12 06:52:44.312 23515-23856/com.droid.visneta D/dalvikvm: GC_FOR_ALLOC freed 1108K, 10% free 47049K/52167K, paused 26ms, total 26ms
10-12 06:52:44.312 23515-23856/com.droid.visneta I/dalvikvm-heap: Grow heap (frag case) to 47.922MB for 1585235-byte allocation
10-12 06:52:44.340 23515-23856/com.droid.visneta D/dalvikvm: GC_FOR_ALLOC freed 0K, 10% free 48597K/53767K, paused 25ms, total 25ms
10-12 06:52:44.340 23515-23856/com.droid.visneta D/Volley: [213] BasicNetwork.logSlowRequests: HTTP response for request=<[ ] https://dev.visneta.com/amf/gateway?contentType=application/json 0x43c48ebe NORMAL 3> [lifetime=7052], [size=1585223], [rc=200], [retryCount=0]
10-12 06:52:44.364 23515-23856/com.droid.visneta D/dalvikvm: GC_FOR_ALLOC freed 2050K, 14% free 46551K/53767K, paused 26ms, total 26ms
10-12 06:52:44.368 23515-23856/com.droid.visneta I/dalvikvm-heap: Grow heap (frag case) to 48.949MB for 3170458-byte allocation

The response is pretty big (over 5 Mb) and it makes sense that weak devices do not have enough RAM for it. It's a tough work, but if the server-side is managed by you, you should split this response into few responses. Sending it in chunks wouldn't work since you still have to piece them together before handling the response, and anyway I don't think that you should parse so much data in one request.
I also suggest you to check out this answer, it will help you find the limits of the device you check: https://stackoverflow.com/a/9428660/5280641.

The problem is not with Volley or Retrofit it is most likely to do with the size or the data response. If you have control over the web service you should look at breaking down the information in to smaller chunks by using paging.

If you have control over your server side, IMO, response data compression is another working way for such issues.
Of course, in client side, you will have to decompress the network response first, then parse as normal.
If your server app is ASP.NET Web API, for example, you can take a look at this ASP.NET Web API Compression documentation for reference. I think other web services or some Web servers also support compression.
Hope this helps!

Well i don't know much about volley but i've handled this kind of json response with Jackson lib.
Check this answers Android: Parsing large JSON file
I think Jackson stream API is the way to go.

Logcat doesnot show errors

When I click on the share button of my App, a message shows Unfortunately has stopped. But, this doesn't cause the app to crash. I am able to share my file. The logcat doesn't show any errors. The following is what my logcat displays .
03-28 15:10:23.585 18455-18455/com.example.akn.play_music D/dalvikvm﹕ GC_FOR_ALLOC freed 208K, 2% free 17001K/17240K, paused 28ms, total 28ms
03-28 15:10:25.165 18455-18455/com.example.akn.play_music D/dalvikvm﹕ GC_FOR_ALLOC freed 142K, 2% free 17003K/17312K, paused 11ms, total 12ms
03-28 15:10:25.175 18455-18464/com.example.akn.play_music D/dalvikvm﹕ GC_FOR_ALLOC freed 3K, 2% free 17576K/17892K, paused 11ms, total 11ms

Why the GC happens so frequent in Android?

I have exit my app, but there is still a backgroud service is running. Whe the GC logs come a log. I will so you the logs beblow. You can see, about 3 logs per second. Is This phenomenon is normal ? My device's memory is enough, and the backgroud service is holding a WebSocket connection.
08-11 10:33:54.456 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2020K, 18% free 10682K/12871K, paused 12ms+6ms, total 44ms
08-11 10:33:54.776 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1985K, 18% free 10676K/12871K, paused 12ms+8ms, total 54ms
08-11 10:33:55.109 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1950K, 18% free 10671K/12871K, paused 12ms+17ms, total 68ms
08-11 10:33:55.459 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2004K, 18% free 10680K/12871K, paused 13ms+8ms, total 62ms
08-11 10:33:55.769 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2010K, 18% free 10680K/12871K, paused 12ms+7ms, total 48ms
08-11 10:33:56.093 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1996K, 18% free 10677K/12871K, paused 12ms+9ms, total 50ms
08-11 10:33:56.416 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2028K, 18% free 10681K/12871K, paused 2ms+8ms, total 37ms
08-11 10:33:56.746 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2031K, 18% free 10682K/12871K, paused 8ms+8ms, total 46ms
08-11 10:33:57.079 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1996K, 18% free 10677K/12871K, paused 12ms+7ms, total 46ms
08-11 10:33:57.429 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2002K, 18% free 10678K/12871K, paused 12ms+19ms, total 59ms
08-11 10:33:57.766 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2003K, 18% free 10679K/12871K, paused 12ms+7ms, total 46ms
08-11 10:33:58.143 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1945K, 18% free 10669K/12871K, paused 12ms+17ms, total 72ms
08-11 10:33:58.473 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2020K, 18% free 10682K/12871K, paused 2ms+6ms, total 41ms
08-11 10:33:58.786 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2013K, 17% free 10690K/12871K, paused 12ms+8ms, total 48ms
08-11 10:33:59.106 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2031K, 18% free 10683K/12871K, paused 12ms+8ms, total 53ms
08-11 10:33:59.443 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2021K, 18% free 10681K/12871K, paused 12ms+8ms, total 48ms
08-11 10:33:59.786 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2028K, 18% free 10681K/12871K, paused 11ms+7ms, total 44ms
08-11 10:34:00.153 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1997K, 18% free 10677K/12871K, paused 12ms+18ms, total 58ms

Is This phenomenon is normal ?
It depends what you mean by "normal".
If you mean normal for an application with those particular heap dimensions, that amount of heapspace used for long-lived objects, and that rate of allocation ... then the answer is "Yes, it is normal".
Basically, you are running your application with a heap that is (objectively) too small for the work that you are asking it to do. You have roughly 2Mb of free space, and you are allocating objects at roughly 6Gb per second. If you want to reduce the number of GC cycles, you need to do one or more of the following:
Increase the heap size. (I don't know if this is feasible for an Android app ...)
Reduce the "working set" of long-lived objects. Maybe you have a memory leak, lots of large images loaded, or an overly large in-memory cache of ... something.
Reduce the rate at which new objects are being allocated by your application.
The last two require you to track down the source of the memory usage / allocation, and change you code to mitigate the effects. There are tools (memory profilers) that can help with this, but the details will be specific to your application.
Here's how I'd interpret the GC log lines ... by example:
08-11 10:33:54.456 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕
GC_CONCURRENT freed 2020K, 18% free 10682K/12871K, paused 12ms+6ms, total 44ms
The "GC_CONCURRENT" collector is being used.
This GC collection cycle reclaimed 2020K bytes.
When the GC cycle completed, 18% of the heap is free, and 10682K out of a total usable heap size of 12871K is in use.
Normal thread activity was paused for two intervals of 12ms and 6ms respectively.
The elapsed time for the GC cycle was 44ms.
Note that the amount of heap freed isn't always exactly the same as the different between total and available ... because for much of the time that the GC is running there are normal threads allocating new objects.

Google Maps v2 calls System.gc() explicitly? Or how to find call to the System.gc()?

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

Testing activesync with android virtual devices

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.

Develop Reference

The Android operating system is a mobile operating system that was developed by Google (GOOGL?) to be primarily used for touchscreen devices, cell phones, and tablets.