Why was the CM11 dev thread closed suddenly?
Will development stop for CM11 on Moto G?
adb logcat then be quiet = bug fixes and happy dev and happy users
Complaining and reporting the bug 62286284 times = dev(s) feeling unfair and moderators constantly having to clean thread
It's because we have a lot of people who don't understand that
ButCode:adb logcat then be quiet = bug fixes and happy dev and happy users
Code:Complaining and reporting the bug 62286284 times = dev(s) feeling unfair and moderators constantly having to clean thread
I'm a developer myself and this is more than often true:
1. Users reporting bugs only see what is right in front of them.
2. Users don't care and don't want to spend time to report bugs, they just want a working device.
3. Some users are lazy and cranky.
Maybe a bug-reporting system where duplicates can be easier to find and manage?
I think people need to be more self aware of things that are going on. Since you're a developer, you would understand that it's hard to meet expectations and constantly being reminded (harshly) really makes you feel down and unappreciated.
It does feel, because people think that bugs are your responsibility as a developer - just that in case of such a large project as Android and CM11, and all the different hardware, it's not.
Still, a good system to report bugs and putting more responsibility of the bug reporters to do it properly - would be a good way to make it better.
Why not make a Github repository for the project and ask people to report bugs there, there would be less pissed off people since they can find out themselves if bugs exist and report what they find.
I didn't noticed until now, where is pulse notification gone?
menu display & light , also change to display.
I'm on nightly 0813.
Sent from my Moto G using XDA Free mobile app
Thx, switch back to 0811 ART working fine.Adding a bug to the list.
# Switch to ART, and check if you get force close on "com.motorola.motgeofencesvc". = easy to reproduce.
com.motorola.motgeofencesvc - it wasn't on 10/8 nightly it was added in the 12/8 nightly since then, FC on ART.
(Sent a bugreport via CM bug report)
This bug is from 12/8 nightly, since Ethan (which has my respect) started changing the kernel.
It's like this since 12/8.
since dhacker isnt maintaining this anymore..does that mean this rom is basically going to stay the same with the same bugs it had when he left?
what bugs are present now? ive heard some people saying the notification led settings have disappeared from display settings among other things
@matmutant Hey, since Ethan is the new dev for CM, is there still any use in submitting bug reports in this thread (or on XDA at all)?
i dont have any contact with him as for now, so bug reports made there go nowhere, but i'll ask him if I can directly report to him issues reported here. wait and see
edit: Ethan answered me, I'm now able to transmit relevant reports directly to him now. this thread won't die finally !
With cm-11-20140815-NIGHTLY-falcon my camera is no longer working properly. When I take a picture, the camera focuses and the flash fires, but instead of actually saving the image, the camera app freezes on this point. I first noticed this with the 0814 nightly, but it could also be present on 0813. No problems using the camera with earlier builds.
I've tried wiping the camera app's data, didn't help. Also tried the Google Camera app from the play store, but it has the same issue. The strange thing is, after a reboot the camera is working fine and I can snap multiple images without problem. But after a while, the bug returns. So far I'm not able to reproduce the conditions.
Logcat attached.
[...]
Total PSS by category:
108786 kB: Native
101428 kB: Dalvik
52426 kB: .dex mmap
48599 kB: .so mmap
47478 kB: Dalvik Other
20583 kB: Other dev
15317 kB: Ashmem
13803 kB: .apk mmap
6924 kB: Unknown
4286 kB: Stack
3092 kB: Other mmap
1734 kB: .ttf mmap
170 kB: .jar mmap
8 kB: Cursor
0 kB: code mmap
0 kB: image mmap
0 kB: Graphics
0 kB: GL
0 kB: Memtrack
Total RAM: 903272 kB
Free RAM: 469660 kB (110976 cached pss + 274788 cached + 83896 free)
Used RAM: 373874 kB (313658 used pss + 3608 buffers + 11320 shmem + 45288 slab)
Lost RAM: 59738 kB
ZRAM: 4304 kB physical used for 15248 kB in swap (131068 kB total swap)
KSM: 44048 kB saved from shared 8208 kB
184956 kB unshared; 326004 kB volatile
Tuning: 64 (large 256), oom 122880 kB, restore limit 40960 kB (high-end-gfx)
up time: 03:39:53, idle time: 01:56:57, sleep time: 01:35:43
$ md5sum cm-11-20140319-UNOFFICIAL-falcon-test2.zip
690636b7b10bd48bcec4fc9a8116fed6 cm-11-20140319-UNOFFICIAL-falcon-test2.zip
Im currently trying to reproduce the ram bug on a build I compiled 30min ago. So far I couldn't achieve more than 100 MB of "Lost RAM", currently it's at ~45 MB.
Because someone said the bug happens with all versions since 20140224, I searched for commits in the device specific repositories that were pushed just after this date, especially in the kernel and qcom display repository. What I found were some commits from 26/02 in android_kernel_motorola_msm8226: https://github.com/CyanogenMod/android_kernel_motorola_msm8226/commits/cm-11.0?page=11
I tried to revert those (cc12abf69bf608b1accffb15682bdeecd36aaaa3..6a8acccc9a65df6cd8782d8858003dea75cfa6e8), got an error during compilation and reverted 518351814c0f60c3ffad26bead05624b668c05ee in android_hardware_qcom_display-caf-new as well (git blame helped here).
It seems that there are still some problems, "Lost RAM" does not go below 40 MB and rises sometimes to as high as 95 MB. But maybe that's just normal. I will test the build for some hours/days and report. If I don't get any problems, I may upload it for others to try so we can verify that the bug was introduced by said commits and track it down further.
Are you posting the fix for wifi to the official cm code review, or will you keep doing your own builds?
Thanks for all the effort.