[JB] CM10 Android 4.1.2 for the Defy(+)

[Antiga Prime]

Hi, could someone please tell me the full list of known bugs in the lastest build? I couldn't find them.

Thanks in advance.

That's probably because there are no "known" bugs. Things differ on each device, some people get black screens, lag, poor battery life, and others don't. I guess you'd just have to try it out and see if it suits your needs.

 

[ezantera]

Something weird is happening with quarx rom when accessing sdcard. iGo navigating software, which is heavily using sdcard because of big maps, is making rom nearly unusable.When I hit home button, even buzz have lag of few sec. My sdcard is nothing special.

 

[drunk_ryder24]

Green lens here too.
What do you mean with great? Are you talking about battery drops?

That's my main problem but everywhere I see people just recommend changing the battery (mine is 2.5 years old). The thing is I can't find original Motorola battery for the defy.

I'm not asking three days with one charge, just the right battery percent displayed in the notification bar.

Cheers.

he is refering to a update-battd.zip i posted early,that zip was posted before in cm9 but looks like its useful in jb for mb525 as it can be noticed

 

[grandpa2007]

AW: [JB] CM10 Android 4.1.2 for the Defy(+)

igo for android...Pssst...

Gesendet von meinem MB526 mit Tapatalk 2

 

[YetAnotherForumUser]

Demonstration and fix of bug in com.android.deskclock

The following code easily demonstrates the accumulating RTC_WAKEUP bug in com.android.deskclock:

$ watch -n 2  sh -c 'clear;dumpsys alarm|grep RTC_WAKEUP'

Now open Clock, add an alarm and repeatedly turn it on and off. Every time you interact with the alarms in Clock the number of RTC_WAKEUP events for com.android.deskclock increases. These wakeup events are only removed when Clock is forcibly closed or the zygote is restarted.

The following patch to DeskClock fixes this bug. Once it is applied, com.android.deskclock only ever has one outstanding RTC_WAKEUP event. This event is updated when the related alarm expires or is disabled before expiry.

diff --git a/src/com/android/deskclock/Alarms.java b/src/com/android/deskclock/Alarms.java
index 9dbe63a..4f0b488 100644
--- a/src/com/android/deskclock/Alarms.java
+++ b/src/com/android/deskclock/Alarms.java
@@ -425,7 +425,7 @@ public class Alarms {
         intent.putExtra(ALARM_RAW_DATA, out.marshall());
 
         PendingIntent sender = PendingIntent.getBroadcast(
-                context, 0, intent, PendingIntent.FLAG_CANCEL_CURRENT);
+                context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);
 
         am.set(AlarmManager.RTC_WAKEUP, atTimeInMillis, sender);
 
@@ -451,7 +451,7 @@ public class Alarms {
                 context.getSystemService(Context.ALARM_SERVICE);
         PendingIntent sender = PendingIntent.getBroadcast(
                 context, 0, new Intent(ALARM_ALERT_ACTION),
-                PendingIntent.FLAG_CANCEL_CURRENT);
+                PendingIntent.FLAG_UPDATE_CURRENT);
         am.cancel(sender);
         setStatusBarIcon(context, false);
         saveNextAlarm(context, "");

A patched version of DeskClock.apk is attached to this posting. To test it, simply replace the version on your phone with this one, taking care to set the file permissions and ownership correctly. Force close Clock and clear its cache and data before you replace the apk. Test the clock with several subsequent alarms, have some repeating alarms and check whether all alarms go off. I have tested the patched version for about half an hour, it seems to work. I have not been able to test whether repeating alarms work as that would take at least a day. I have no reason to believe they would not work but given the nature of the beast it might be prudent to have a backup alarm in case you depend on being alerted by your phone. Insert standard disclaimer, objects in the mirror are closer than they appear, not suitable for children of 45 or younger, etc.

I submitted this bug and patch to the Android bug tracker: #52601. With a bit of luck this problem will be patched upstream. I have not submitted it to Cyanogenmod yet but might do so if the response on the Android bug tracker is tardy or lacking.

 

[brotbuexe]

he is refering to a update-battd.zip i posted early,that zip was posted before in cm9 but looks like its useful in jb for mb525 as it can be noticed

Looks like my hf5x battery in my defy does not charge beyond 82% with this battd. Going back to the battd that was there before (55.840 bytes) and is included in quarx build.

Keep in mind that your installed battd binary will be preserved by /system/addon.d/80-battd.sh when you flash quarx.

 

[drunk_ryder24]

Looks like my hf5x battery in my defy does not charge beyond 82% with this battd. Going back to the battd that was there before (55.840 bytes) and is included in quarx build.

Keep in mind that your installed battd binary will be preserved by /system/addon.d/80-battd.sh when you flash quarx.

did you wipe batterystats before flashing the zip?

 

[vic160890]

The following code easily demonstrates the accumulating RTC_WAKEUP bug in com.android.deskclock:

$ watch -n 2  sh -c 'clear;dumpsys alarm|grep RTC_WAKEUP'

Now open Clock, add an alarm and repeatedly turn it on and off. Every time you interact with the alarms in Clock the number of RTC_WAKEUP events for com.android.deskclock increases. These wakeup events are only removed when Clock is forcibly closed or the zygote is restarted.

The following patch to DeskClock fixes this bug. Once it is applied, com.android.deskclock only ever has one outstanding RTC_WAKEUP event. This event is updated when the related alarm expires or is disabled before expiry.

diff --git a/src/com/android/deskclock/Alarms.java b/src/com/android/deskclock/Alarms.java
index 9dbe63a..4f0b488 100644
--- a/src/com/android/deskclock/Alarms.java
+++ b/src/com/android/deskclock/Alarms.java
@@ -425,7 +425,7 @@ public class Alarms {
         intent.putExtra(ALARM_RAW_DATA, out.marshall());
 
         PendingIntent sender = PendingIntent.getBroadcast(
-                context, 0, intent, PendingIntent.FLAG_CANCEL_CURRENT);
+                context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);
 
         am.set(AlarmManager.RTC_WAKEUP, atTimeInMillis, sender);
 
@@ -451,7 +451,7 @@ public class Alarms {
                 context.getSystemService(Context.ALARM_SERVICE);
         PendingIntent sender = PendingIntent.getBroadcast(
                 context, 0, new Intent(ALARM_ALERT_ACTION),
-                PendingIntent.FLAG_CANCEL_CURRENT);
+                PendingIntent.FLAG_UPDATE_CURRENT);
         am.cancel(sender);
         setStatusBarIcon(context, false);
         saveNextAlarm(context, "");

A patched version of DeskClock.apk is attached to this posting. To test it, simply replace the version on your phone with this one, taking care to set the file permissions and ownership correctly. Force close Clock and clear its cache and data before you replace the apk. Test the clock with several subsequent alarms, have some repeating alarms and check whether all alarms go off. I have tested the patched version for about half an hour, it seems to work. I have not been able to test whether repeating alarms work as that would take at least a day. I have no reason to believe they would not work but given the nature of the beast it might be prudent to have a backup alarm in case you depend on being alerted by your phone. Insert standard disclaimer, objects in the mirror are closer than they appear, not suitable for children of 45 or younger, etc.

I submitted this bug and patch to the Android bug tracker: #52601. With a bit of luck this problem will be patched upstream. I have not submitted it to Cyanogenmod yet but might do so if the response on the Android bug tracker is tardy or lacking.

I, for one, use the clock app from 4.2 (includes stopwatch and timer and is much nicer ) i will try to test what you did on deskclock, and if the same problem occures maybe the same patch could be applied

 

[YetAnotherForumUser]

I, for one, use the clock app from 4.2 (includes stopwatch and timer and is much nicer ) i will try to test what you did on deskclock, and if the same problem occurs maybe the same patch could be applied

I used that version when it just appeared. It turned out to have a bug in that it only ever sounded the first alarm, all subsequent alarms were silently ignored. As I use my phone to alert me for various things this was rather unfortunate. I reverted to the original and ran that without to many problems, apart from the mentioned over-enthusiastic use of AlarmManager's services.

I did test the clock app from 4.2.2 to see whether this bug had been fixed. It had not in the version I used (taken from Quarx's most recent experimental build). I downloaded the source to the AOSP 4.2.2r1 version of DeskClock and found that the bug is still present there so I assume the version you currently use also suffers from over-alertness.

 

[vic160890]

I used that version when it just appeared. It turned out to have a bug in that it only ever sounded the first alarm, all subsequent alarms were silently ignored. As I use my phone to alert me for various things this was rather unfortunate. I reverted to the original and ran that without to many problems, apart from the mentioned over-enthusiastic use of AlarmManager's services.

I did test the clock app from 4.2.2 to see whether this bug had been fixed. It had not in the version I used (taken from Quarx's most recent experimental build). I downloaded the source to the AOSP 4.2.2r1 version of DeskClock and found that the bug is still present there so I assume the version you currently use also suffers from over-alertness.

I must say that I use it to wake me up every morning , but i never use repetitive alarms. I always set it in the evening, at different hours according to the schedule for next day. so I never encountered this problem. always rings perfectly. I shall try a recurring alarm or 2 alarms set one after the other to see if the bug is present. Even so I like it way more than the other one.

Edit: It just rang 2 times in a row with two alarms set for 23:44 and 23:45. both discarded by dragging the ring to the "eye".

 

[rugaxp]

Weird Behavior

After flashing off to new build my phone are acting super weird.

I tried YAFU's at first, phone cant really boot up after the red light, so I remove battery and gave it a few attempt, same result.
So I wipe cache,dalvik and tried, still same, then I decided to wipe data and re-install it. no luck.

Then I go for Quarx 20130220 build, this time after flashing it can boot. after testing for a half a day or so. I rebooted like 3 time but every reboot will prompt me the initial setup page (language, wifi, gmail and stuffs) but the charging is still ok I guess, with white lights.

Not satisfied, I reflash YAFU's builds again. This time it boots up after few attempts. Every reboot prompts setups. Every charge plugin will light up green but its actually hanging there doing nuts and heating up crazily, after removing it from the usb, it still lights up green all the way till I removes the battery. It just heats up tremendously. That was with phone off.

Phone on, I can actually charge it.

I only know that, normal condition, It should light up white. not green or red. but with this, I get green lights.

I don't know where gone wrong, please help me out. I'm thinking I might fried my phone in a while.

 

[blessani]

Ooooookay. So, I've re-flashed a dozen times over the past few days. But I think I'm somewhere near stable.

This guide is solid gold, http://forum.xda-developers.com/showpost.php?p=38560698&postcount=15719&nocache=1&z=9728261723318178

Defy-Gapps-CM10-20121224-without-Voice.zip
SuperOneClickv2.3.3-ShortFuse.zip
CM10-20130220-NIGHTLY-mb526.zip
MotoHelper_2.1.32_Driver_5.4.0.exe
RSDLite5.6.rar
JRDNEM_U3_3.4.2_177-003_BLUR_SIGN_SIGNED_USAJRDNEMARAB1B8RTGB03A.0R_PDS03C_USAJRDNFRYORTGB_P019_A010_HWp3_Service1FF.sbf.gz
SndInitDefy_2.0.apk
Ultimatic_Jar_Patcher_Tools_RC6_ALL_DEX_Windows.exe
BM.Tweaks.Defy.zip

But I didn't bother with Supercharger (as it mimicked what other scripts already did), and I didn't bother with Seeder, as my entropy levels are fine.

When using Ultimatic, it also wasn't necessary to do the memory tweak, or install the versions of su or busybox - as they are older than the bundled Quarx release.

I also removed the journal from the /data and /cache partitions (in recovery, via adb)

umount /data; e2fsck -f /dev/block/mmcblk1p25; tune2fs -O ^has_journal /dev/block/mmcblk1p25; tune2fs -l /dev/block/mmcblk1p25 | grep features
umount /cache; e2fsck -f /dev/block/mmcblk1p24; tune2fs -O ^has_journal /dev/block/mmcblk1p24; tune2fs -l /dev/block/mmcblk1p24 | grep features

And set the follow VSEL/Clock values with Smartass

18/300
30/600
40/800
62/1200

Load averages are nice and low (fairly consistently under <0.2 on idle) - and the phone is very snappy and responsive. Dare I say it, it feels just a little less responsive than my Nexus4 - so that's quite a complement for a phone with a quarter the power.

I've yet to install anything yet, or test the battery at all - so I'm literally just going off idle figures. I'll go from here and see how things progress.

--

Here's a quadrant test from CM7.2

And here's a quadrant test from CM10 - so its not close in terms of raw numbers, but who knows what they changed in the quadrant ratings since I last ran the test.

--

But hopefully, no more of these insane load averages ...

 

[vic160890]

4.2 clock which was first extracted when 4.2 got out.

# dumpsys alarm
Current Alarm Manager state:

  Realtime wakeup (now=2013-03-04 00:28:13):
  RTC_WAKEUP #14: Alarm{40fb8658 type 0 android}
    type=0 when=+55d3h14m7s920ms repeatInterval=3865164 count=0
    operation=PendingIntent{40e538e8: PendingIntentRecord{40e49fe0 android broadcastIntent}}
  RTC_WAKEUP #13: Alarm{413c8e48 type 0 com.google.android.partnersetup}
    type=0 when=+6d18h53m51s94ms repeatInterval=0 count=0
    operation=PendingIntent{4178f318: PendingIntentRecord{41219348 com.google.android.partnersetup startService}}
  RTC_WAKEUP #12: Alarm{410fedd8 type 0 com.google.android.gsf}
    type=0 when=+5d4h7m21s519ms repeatInterval=581130000 count=0
    operation=PendingIntent{40f7c638: PendingIntentRecord{41244280 com.google.android.gsf broadcastIntent}}
  RTC_WAKEUP #11: Alarm{41325d08 type 0 com.google.android.gsf}
    type=0 when=+5d4h7m21s519ms repeatInterval=581130000 count=0
    operation=PendingIntent{416c37f0: PendingIntentRecord{417567d8 com.google.android.gsf broadcastIntent}}
  RTC_WAKEUP #10: Alarm{4101b0a8 type 0 com.google.android.gsf}
    type=0 when=+5d4h7m21s519ms repeatInterval=581130000 count=0
    operation=PendingIntent{41203ed0: PendingIntentRecord{4122c028 com.google.android.gsf broadcastIntent}}
  RTC_WAKEUP #9: Alarm{413ca6e0 type 0 com.google.android.gsf}
    type=0 when=+5d4h7m21s519ms repeatInterval=581130000 count=0
    operation=PendingIntent{40efb578: PendingIntentRecord{4151bef0 com.google.android.gsf broadcastIntent}}
  RTC_WAKEUP #8: Alarm{41209098 type 0 com.google.android.gsf}
    type=0 when=+5d4h7m21s519ms repeatInterval=581130000 count=0
    operation=PendingIntent{41232c78: PendingIntentRecord{413794d8 com.google.android.gsf broadcastIntent}}
  RTC_WAKEUP #7: Alarm{417e6cc8 type 0 com.whatsapp}
    type=0 when=+23h31m46s173ms repeatInterval=86400000 count=1
    operation=PendingIntent{40db5e70: PendingIntentRecord{412546d8 com.whatsapp broadcastIntent}}
  RTC_WAKEUP #6: Alarm{41a308c8 type 0 com.android.providers.calendar}
    type=0 when=+20h34m8s269ms repeatInterval=0 count=0
    operation=PendingIntent{40e67c08: PendingIntentRecord{41a30828 com.android.providers.calendar broadcastIntent}}
  RTC_WAKEUP #5: Alarm{4108e400 type 0 com.google.android.gms}
    type=0 when=+18h11m49s206ms repeatInterval=0 count=0
    operation=PendingIntent{40dd4eb0: PendingIntentRecord{40dfbf90 com.google.android.gms broadcastIntent}}
  RTC_WAKEUP #4: Alarm{4101a808 type 0 com.android.vending}
    type=0 when=+6h25m48s988ms repeatInterval=0 count=0
    operation=PendingIntent{41141600: PendingIntentRecord{40e4e300 com.android.vending startService}}
  RTC_WAKEUP #3: Alarm{40f84828 type 0 com.whatsapp}
    type=0 when=+3h31m46s173ms repeatInterval=86400000 count=0
    operation=PendingIntent{4125b158: PendingIntentRecord{40ea75b8 com.whatsapp broadcastIntent}}
  RTC_WAKEUP #2: Alarm{40e0a0f8 type 0 com.google.android.gms}
    type=0 when=+1h31m46s173ms repeatInterval=86400000 count=1
    operation=PendingIntent{40e37ee0: PendingIntentRecord{40e0a058 com.google.android.gms startService}}
  RTC_WAKEUP #1: Alarm{416cbc98 type 0 com.google.android.gsf}
    type=0 when=+10m51s365ms repeatInterval=1800000 count=0
    operation=PendingIntent{416c4e68: PendingIntentRecord{40f25df0 com.google.android.gsf broadcastIntent}}
  RTC_WAKEUP #0: Alarm{411e9af0 type 0 ccc71.bmw.pro}
    type=0 when=+6m34s476ms repeatInterval=600000 count=1
    operation=PendingIntent{41460110: PendingIntentRecord{411ef478 ccc71.bmw.pro broadcastIntent}}
  RTC #3: Alarm{41712738 type 1 com.touchtype.swiftkey}
    type=1 when=+6d21h57m37s537ms repeatInterval=0 count=0
    operation=PendingIntent{413188d0: PendingIntentRecord{41712698 com.touchtype.swiftkey broadcastIntent}}
  RTC #2: Alarm{413a4d10 type 1 com.android.calendar}
    type=1 when=+23h31m46s173ms repeatInterval=0 count=0
    operation=PendingIntent{41711b20: PendingIntentRecord{40e938f0 com.android.calendar broadcastIntent}}
  RTC #1: Alarm{40e17b68 type 1 android}
    type=1 when=+11h31m46s173ms repeatInterval=0 count=0
    operation=PendingIntent{40f3b898: PendingIntentRecord{40e1c710 android broadcastIntent}}
  RTC #0: Alarm{41b596f8 type 1 com.whatsapp}
    type=1 when=+9h31m46s173ms repeatInterval=86400000 count=0
    operation=PendingIntent{41801708: PendingIntentRecord{411e4c68 com.whatsapp broadcastIntent}}

  Elapsed realtime wakeup (now=+7d5h7m52s218ms):
  ELAPSED_WAKEUP #0: Alarm{40dca088 type 2 com.qo.android.am3}
    type=2 when=+12h40m17s130ms repeatInterval=86400000 count=1
    operation=PendingIntent{41114e10: PendingIntentRecord{40efc428 com.qo.android.am3 broadcastIntent}}
  ELAPSED #6: Alarm{4151bf68 type 3 android}
    type=3 when=+30d22h31m38s554ms repeatInterval=0 count=0
    operation=PendingIntent{410c1bf0: PendingIntentRecord{410c1bb8 android broadcastIntent}}
  ELAPSED #5: Alarm{40e766a8 type 3 android}
    type=3 when=+14h48m56s608ms repeatInterval=0 count=0
    operation=PendingIntent{4109e7b0: PendingIntentRecord{410b5dc0 android broadcastIntent}}
  ELAPSED #4: Alarm{4102a970 type 3 com.android.phone}
    type=3 when=+3h7m7s782ms repeatInterval=28800000 count=1
    operation=PendingIntent{40f73790: PendingIntentRecord{4101a428 com.android.phone broadcastIntent}}
  ELAPSED #3: Alarm{40f43988 type 3 com.whatsapp}
    type=3 when=+52m7s782ms repeatInterval=3600000 count=1
    operation=PendingIntent{41624378: PendingIntentRecord{41326ef0 com.whatsapp broadcastIntent}}
  ELAPSED #2: Alarm{4101ce90 type 3 android}
    type=3 when=+7m7s782ms repeatInterval=1800000 count=1
    operation=PendingIntent{40f50f30: PendingIntentRecord{40f50eb0 android broadcastIntent}}
  ELAPSED #1: Alarm{4130fb00 type 3 android}
    type=3 when=+1m38s557ms repeatInterval=0 count=0
    operation=PendingIntent{410c1ae0: PendingIntentRecord{410c1a40 android broadcastIntent}}
  ELAPSED #0: Alarm{41262bb8 type 3 android}
    type=3 when=+46s106ms repeatInterval=0 count=0
    operation=PendingIntent{40f3cfb0: PendingIntentRecord{40f3b7f0 android broadcastIntent}}

  Broadcast ref count: 0

  Alarm Stats:
  ccc71.bmw.pro
    111162ms running, 1079 wakeups
    1079 alarms: flg=0x14
  com.android.calendar
    2033ms running, 0 wakeups
    8 alarms: act=com.android.calendar.APPWIDGET_SCHEDULED_UPDATE dat=content://com.android.calendar typ=vnd.android.data/update flg=0x14
  android
    671016ms running, 103 wakeups
    7 alarms: act=android.intent.action.DATE_CHANGED flg=0x20000014
    4869 alarms: act=android.intent.action.TIME_TICK flg=0x40000014
    346 alarms: act=com.android.server.action.NETWORK_STATS_POLL flg=0x14
    1003 alarms: act=com.android.server.ThrottleManager.action.POLL flg=0x14
    75 alarms: act=com.android.internal.policy.impl.PhoneWindowManager.DELAYED_KEYGUARD flg=0x14
    5 alarms: act=com.android.server.NetworkTimeUpdateService.action.POLL flg=0x14
    1 alarms: act=android.app.backup.intent.RUN flg=0x40000014
    27 alarms: act=android.content.syncmanager.SYNC_ALARM flg=0x14
    2 alarms: act=com.android.server.ThorottleManager.action.RESET flg=0x14
  com.touchtype.swiftkey
    857ms running, 0 wakeups
    1 alarms: act=com.touchtype.ACTION_SCHEDULED_JOB flg=0x14
  com.whatsapp
    64200ms running, 101 wakeups
    5 alarms: act=ALARM_REPORT_SYNCS flg=0x14
    5 alarms: act=ALARM_MESSAGES_DB_BACKUP flg=0x14
    6 alarms: act=ALARM_ROTATE_LOGS flg=0x14
    12 alarms: act=ALARM_AVAILABLE_TIMEOUT flg=0x14
    181 alarms: act=ALARM_ACTION flg=0x14
    78 alarms: act=com.whatsapp.MessageService.RECONNECT flg=0x4 cmp=com.whatsapp/.messaging.MessageService
  com.android.phone
    97652ms running, 13 wakeups
    236 alarms: act=com.android.internal.telephony.gprs-data-stall flg=0x14
    21 alarms: act=com.android.phone.UPDATE_CALLER_INFO_CACHE flg=0x14
    13 alarms: act=com.android.internal.telephony.gprs-reconnect.0 flg=0x14
  com.google.android.partnersetup
    145ms running, 1 wakeups
    1 alarms: flg=0x4 cmp=com.google.android.partnersetup/.RlzPingService
  com.google.android.gsf
    129197ms running, 750 wakeups
    347 alarms: flg=0x14
    180 alarms: act=com.google.android.intent.action.GTALK_RECONNECT flg=0x14
    8 alarms: act=com.google.android.intent.action.MCS_HEARTBEAT flg=0x14
    215 alarms: act=com.google.android.intent.action.SEND_IDLE flg=0x14
  com.android.vending
    318ms running, 21 wakeups
    9 alarms: flg=0x4 cmp=com.android.vending/com.google.android.finsky.services.DailyHygiene
    12 alarms: flg=0x4 cmp=com.android.vending/com.google.android.finsky.services.ContentSyncService
  com.android.chrome
    772ms running, 0 wakeups
    19 alarms: act=com.google.android.apps.chrome.omaha.ACTION_REGISTER_REQUEST flg=0x4 cmp=com.android.chrome/com.google.android.apps.chrome.omaha.OmahaPingService
    8 alarms: act=com.google.android.apps.chrome.omaha.ACTION_POST_REQUEST flg=0x4 cmp=com.android.chrome/com.google.android.apps.chrome.omaha.OmahaPingService
  com.google.android.inputmethod.latin.dictionarypack
    488ms running, 0 wakeups
    3 alarms: act=com.android.inputmethod.latin.dictionarypack.UPDATE_NOW flg=0x14
  com.android.providers.calendar
    81259ms running, 87 wakeups
    87 alarms: act=com.android.providers.calendar.intent.CalendarProvider2 flg=0x14
  com.qo.android.am3
    2944ms running, 3 wakeups
    3 alarms: flg=0x14
  com.google.android.deskclock
    3718ms running, 18 wakeups
    11 alarms: act=times_up flg=0x14
    2 alarms: act=com.android.deskclock.ON_QUARTER_HOUR flg=0x14
    7 alarms: act=com.android.deskclock.ALARM_ALERT flg=0x14
  com.google.android.gms
    224ms running, 3 wakeups
    1 alarms: act=com.google.android.gms.recovery.WAKEUP flg=0x14
    2 alarms: act=com.google.android.gms.icing.INDEX_RECURRING_MAINTENANCE flg=0x4 cmp=com.google.android.gms/.icing.impl.IndexService
  com.google.android.gm
    328ms running, 0 wakeups
    7 alarms: act=com.google.android.gm.intent.provider.INDEX_MESSAGE_CONTENT dat=content://gmail-ls/[email protected]/indexer flg=0x4 cmp=com.google.android.gm/.provider.MailIndexerService

 

[Antiga Prime]

After flashing off to new build my phone are acting super weird.

I tried YAFU's at first, phone cant really boot up after the red light, so I remove battery and gave it a few attempt, same result.
So I wipe cache,dalvik and tried, still same, then I decided to wipe data and re-install it. no luck.

Then I go for Quarx 20130220 build, this time after flashing it can boot. after testing for a half a day or so. I rebooted like 3 time but every reboot will prompt me the initial setup page (language, wifi, gmail and stuffs) but the charging is still ok I guess, with white lights.

Not satisfied, I reflash YAFU's builds again. This time it boots up after few attempts. Every reboot prompts setups. Every charge plugin will light up green but its actually hanging there doing nuts and heating up crazily, after removing it from the usb, it still lights up green all the way till I removes the battery. It just heats up tremendously. That was with phone off.

Phone on, I can actually charge it.

I only know that, normal condition, It should light up white. not green or red. but with this, I get green lights.

I don't know where gone wrong, please help me out. I'm thinking I might fried my phone in a while.

Something similar happened to me once, don't remember how I did it but the data partition got damaged, so nothing was saved upon reboot, so everytime I rebooted I had to set every thing up again. The only thing that got it fixed was starting all over again with stock SBF and Rsdlite.

 

[YetAnotherForumUser]

4.2 clock which was first extracted when 4.2 got out....

You don't have any scheduled alarms it seems. Schedule some, then enable/disable one of them a few times. Try with recurring alarms as well. Sooner or later you're bound to see the number of RTC_WAKEUP events increasing. It could be that recurring alarms are the key to this bug so try both with and without.

 

[Antiga Prime]

There has been something interesting that has happened to me with every CM10 rom for the past few months. For some reason Android OS uses ridiculously large amounts of data on Wifi as far as I know. The last time I was up to 15gb, on 31/12 build. Now I'm not really sure if these are just false alarms and the OS is showing bad stats or not, but one thing I can be sure about is that this does NOT happen on the unofficial 17/01 rom compiled by Sevenrock.

Even though it's currently showing Whatsapp using about 40mb, which, considering the usage I've had since I flashed this rom a few days ago, there is no way that can be right, at least it's not Android OS that is showing high data usage like it usually happens with other roms. I have used other apps to try to pinpoint what is using the data (Onavo, My Data Manager, among others), and they all show it's Android OS.

I always use roughly the same apps, and even got to the point that I even used Droidwall/ Android Firewall to only allow certain apps, and the data usage was still extremely high.

Now the only thing different from most of the recent builds is that they use the .60 kernel, while Sevenrock's build is using .9 kernel. I didn't use the 20/02 official build long enough to see if the high data usage is gone on that rom too.

Now, I don't know if this has actually anything to do or not, but I was wondering if anyone else on either kernels who use wifi most of the time could check their data usage and see if it's unusually high, and maybe post their results here, unless some other dev could shed some light on this.

 

[Antiga Prime]

I used that version when it just appeared. It turned out to have a bug in that it only ever sounded the first alarm, all subsequent alarms were silently ignored. As I use my phone to alert me for various things this was rather unfortunate. I reverted to the original and ran that without to many problems, apart from the mentioned over-enthusiastic use of AlarmManager's services.

I did test the clock app from 4.2.2 to see whether this bug had been fixed. It had not in the version I used (taken from Quarx's most recent experimental build). I downloaded the source to the AOSP 4.2.2r1 version of DeskClock and found that the bug is still present there so I assume the version you currently use also suffers from over-alertness.

Even though I do not see Deskclock in the attached dump, I do use recurring alarms on a daily basis, as also scheduled tasks with Tasker, so I was wondering if you find anything out of the ordinary. I cannot post it because it's too long for the 30k character limit specified by the forum.

 

[vic160890]

You don't have any scheduled alarms it seems. Schedule some, then enable/disable one of them a few times. Try with recurring alarms as well. Sooner or later you're bound to see the number of RTC_WAKEUP events increasing. It could be that recurring alarms are the key to this bug so try both with and without.

Ok, I did play with the alarms a little and I have now up to 91 RTC_WAKEUP events. How can I apply your patch to this apk (the 4.2 clock)

 

[woodman]

Hi all,

On post #15693, I reported an issue I had about media managment / SD card access. I said that I will report, what I'm doing now. I though it was the famous 'ringtone' bug but apparently it's NOT.

I'm currently testing with sevenrock's 20130117 build and after 4 days and 21 hours of uptime and intensive music playback (stored on my sd card). I did NOT encounter my described issue I had with 20130220 Quarx build (it could occur with previous builds too).
The issue was that music playback suddenly stopped and it was impossible to play music again (and ringtones didn't work too). nevertheless, it was possible to access to my sd card with a file explorer app. The only way to recover music playback was to do an unmount/mount of my sd card.

With 20130220 Quarx build this issue occured twice in 2 or 3 days of uptime.

 

[YetAnotherForumUser]

Even though I do not see Deskclock in the attached dump, I do use recurring alarms on a daily basis, as also scheduled tasks with Tasker, so I was wondering if you find anything out of the ordinary. I cannot post it because it's too long for the 30k character limit specified by the forum.

The mere fact that the alarm table exceeds the quote length limit should set off a bell.

No, I did not find deskclock in your list. What I did find was 140 scheduled RTC_WAKEUP events for com.google.android.gsf, all scheduled to go off at the same time. Clearly it is not just com.android.deskclock which mis-handles AlarmManager. As GSF is closed source it is not as easy to fix the bugs there. On my phone I disabled the whole Google family, to be enabled on demand and disabled right afterwards. If you can't fix 'm, disable 'm...

Also... Tasker... 683 wakeups. Rather excessive.