[G2 Android Development (D802)] 1ceb0x:
The rom is great, everyone knows that. But it will be even greater if all the errors will be fixed. That's why the Android OS consumes so much power that it does.

Someone said - Android OS is OK to consume and keep the phone awake because you run Android. Wrong! On AOSP, the Android OS process doesn't go higher than 1 hour in one single charge whereas on Stock, it can go up to 8 hours of awake.

Sure, this means nothing because in theory, everytime you draw something on the screen, you will have the phone awake. But i have another theory - due to the attached log, you get high Android OS usage. I am looking in ADM (Android debug monitor) and when the screen is off, there is no error whatsoever - thus the phone can keep its battery drain under 1% in 8 or more hours.

Tell me i am crazy, but all these errors are something each developer should want to fix. I'm not saying [MENTION=4713009]pendroz[/MENTION] doesn't make a good job, all i am saying is it will be great to have this dealt once and for all.

The errors that you get are mainly from:

Parcel (whatever this is - i don't know) ->> "Reading NULL string not supported here" Here where?

WiFiStateMachine ->> "LG_RSSI Update newRssi= -x value"

lightsbindercall ->> 06-05 13:05:17.555: E/lightsbindercall(1092): virtual void android::BpEmotionalLedManager::updateLightList(int32_t, int32_t, int, int32_t, int32_t, int32_t, const android::String16&) : Binder Transaction End!! (error code 0)

And the most pesky of all (related to Location):

06-05 13:12:39.275: E/LocSvc_utils_q(1092): D/msg_q_snd: Sending message with handle = 0x683F9FA0
06-05 13:12:39.275: E/LocSvc_utils_ll(1092): D/linked_list_add: Adding to list data_obj = 0x683F9FA0
06-05 13:12:39.275: E/LocSvc_utils_q(1092): D/msg_q_snd: Finished Sending message with handle = 0x683F9FA0
06-05 13:12:39.275: E/LocSvc_utils_ll(1092): D/linked_list_remove: Removing from list
06-05 13:12:39.275: E/LocSvc_utils_q(1092): D/msg_q_rcv: Received message 0x683F9FA0 rv = 0
06-05 13:12:39.275: E/LocSvc_api_v02(1092): V/loc_alloc_slot:271]: returning slot 0
06-05 13:12:39.275: E/LocSvc_api_v02(1092): V/loc_sync_select_ind:356]: client handle 0x61178c70, ind_id 106, req_id 106
06-05 13:12:39.275: E/LocSvc_api_v02(1092): V/validateRequest:1552]: reqId = 106
06-05 13:12:39.275: E/LocSvc_api_v02(1092): V/validateRequest:1915]: reqId=106, len = 24
06-05 13:12:39.275: E/LocSvc_api_v02(1092): V/locClientSendReq:2396] sending reqId= 106, len = 24
06-05 13:12:39.275: E/LocSvc_api_v02(1092): I/---> locClientSendReq line 2402 QMI_LOC_INJECT_GSM_CELL_INFO_REQ_V02
06-05 13:12:39.275: E/LocSvc_api_v02(1092): V/locClientSendReq:2413] qmi_client_send_msg_sync returned 0
06-05 13:12:39.275: E/LocSvc_api_v02(1092): V/convertQmiResponseToLocStatus:681]: result = 0, error = 223, status = 0
06-05 13:12:39.275: E/LocSvc_api_v02(1092): V/locClientIndCb:1356]: Indication: msg_id=106 buf_len=7 pCallbackData = 0x61178c70
06-05 13:12:39.275: E/LocSvc_api_v02(1092): V/locClientGetSizeByRespIndId:2563]: resp ind Id 106 size = 4
06-05 13:12:39.275: E/LocSvc_api_v02(1092): V/locClientGetSizeAndTypeByIndId:556]: indId 106 is a resp size = 4
06-05 13:12:39.275: E/LocSvc_ApiV02(1092): I/<--- void globalRespCb(locClientHandleType, uint32_t, locClientRespIndUnionType, void*) line 106 QMI_LOC_INJECT_GSM_CELL_INFO_REQ_V02
06-05 13:12:39.275: E/LocSvc_ApiV02(1092): V/void globalRespCb(locClientHandleType, uint32_t, locClientRespIndUnionType, void*):112] client = 0x61178c70, resp id = 106, client cookie ptr = 0x63208300
06-05 13:12:39.280: E/LocSvc_api_v02(1092): V/loc_sync_process_ind:165]: received indication, handle = 0x61178c70 ind_id = 106
06-05 13:12:39.280: E/LocSvc_api_v02(1092): V/loc_sync_process_ind:195]: found slot 0 selected for ind 106
06-05 13:12:39.280: E/LocSvc_api_v02(1092): V/locClientGetSizeByRespIndId:2563]: resp ind Id 106 size = 4
06-05 13:12:39.280: E/LocSvc_api_v02(1092): V/loc_sync_process_ind:201]: copying ind payload size = 4
06-05 13:12:39.280: E/LocSvc_api_v02(1092): V/loc_sync_process_ind:219]: ind 106 arrived before wait was called
06-05 13:12:39.280: E/LocSvc_api_v02(1092): V/loc_sync_send_req:512]: select_id = 0,locClientSendReq returned 0
06-05 13:12:39.280: E/LocSvc_api_v02(1092): D/loc_free_slot:299]: freeing slot 0
06-05 13:12:39.280: E/LocSvc_api_v02(1092): V/loc_sync_send_req:539]: success (select id 0)
06-05 13:12:39.280: E/LocSvc_LBSApiV02(1092): V/Exiting virtual int lbs_core::LBSApiV02::cinfoInject(int, int, int, int, bool) line 239 1
06-05 13:12:39.280: E/LocSvc_MsgTask(1092): D/MsgTask::loop() 8558 listening ...
06-05 13:12:39.280: E/LocSvc_utils_q(1092): D/msg_q_rcv: Waiting on message

Every time you wake your phone - you get these spamming like crazy (most spammer of all is Parcel error).

Every time you lock your phone - all this spam STOPS.

Hope this will help.....somehow.

LE + more info:

I know we don't run aosp here, but i can't seem to find sources for stock rom so here it is:

Parcel error comes from here: frameworks/native/libs/binder/Parcel.cpp

It is actually a verbose log which can easily be disabled and i bet we will get less Android OS usage.

String16 Parcel::readString16() const
{
size_t len;
const char16_t* str = readString16Inplace(&len);
if (str) return String16(str, len);
ALOGE("Reading a NULL string not supported here.");
return String16();
}

[MENTION=4713009]pendroz[/MENTION] can do it by decompiling, if he doesn't work with sources, i think!

Parcel.cpp info taken from here: http://code.metager.de/source/xref/android/4.4/frameworks/native/libs/binder/Parcel.cpp