yashsingh1/xdaforums huggingface dataset:
[E 2015 Original Android Development] IronTechmonkey:
Although certainly a reasonable consideration this is unlikely to be a CM issue (no issues here with CGapps). FYI: Similar problems with play services (and some potential workarounds) reported in Delta Gapps http://xdaforums.com/android/software/app-minimal-gapps-gapps-lp-20150107-1-t2997368/page157. From a quick read of recent posts there it looks like, among other things, Google has attempted to address some wakelock issues with their most recent update and this is causing problems, at least for people who have been disabling keep awake and other components of GFS in order to prevent the wakelocks. This may be a case where blocking one of the service is actually the cause of problem (unless the problem has shown it's self before anything is blocked). In any event it seems that this is indeed a Gapps issue and using the older gapps CGapps package and allowing Google play services to update naturally may be less problematic. As to wiping, for both clean and dirty flash - not wiping cache and dalvik cache undermines and invalidates just about any testing result or conclusions, especially with Gapps.
[E 2015 Original Android Development] IronTechmonkey:
Auto-brighness seems to be a disaaser for motoE (although not for other devices). It now hugs lowest possible value of about 1% until under very bright and direct light, and it never makes the display bright enough to be readable until under direct sunlight. This is the worst autobrightness combination I've seen in 3 years of droiding on 2 devices in dozens ROMS. Good golly.
[E 2015 Original Android Development] india_motoe2015:
Everything you said checks-out in my case. I have disabled wakelocks to squeeze out as much performance from battery as possible. I'll either wait for Google to fix it, or dismiss the notice (as it is harmless) that says 'Play Services have stopped.' for now.

Thank you!
[E 2015 Original Android Development] IronTechmonkey:
An additional consideration is that the DisableService app has a tendency to allow it's setting to persist when the app is removed or frozen, and to truly restore normalcy settings should be reversed before removing the app (which is a drag and often forgotten). The native Privacy Guard settings (which you seem to be using) are a bit friendlier. Also, dirty flashing might allow some settings to persist where clean flashing forces a reset...unless a TiBU restore of DisableService is done.
[E 2015 Original Android Development] squid2:
Heh, auto brightness seems to be working just fine for me, choosing reasonable levels in all lighting conditions and adapting to change in reasonable amounts. They do fiddle with the auto brightness code in CM occasionally, but I haven't noticed anything particularly bad myself.
[E 2015 Original Android Development] IronTechmonkey:
Good to have more feedback from the same device, which induced more testing here. Thanks. This is a specific recent commit I'm testing against http://review.cyanogenmod.org/#/c/113127/ and it is not as bad as I thought but there is something funky which may affect people who use low brightness settings:

It is known that the auto-brightness range is set, in part, relative to the last manually set brightness value but... apparently... only if that value is manually set after auto-brightness is enabled .(Seeming change in behavior).

If a low brightness value is manually set while auto-brightness is enabled, and if auto-brightness is then disabled; that low value will persist as the relative reference point for auto-brightness even if higher brightness values were manually set in the interim while auto-brightness was disabled, and even if the phone is put under brighter light. (Seeming change in behavior).

Until a higher brightness value is set while auto brightness is enabled, auto-brightness abides by the previously set low value, which causes the whole auto-brightness range to be too dim if the device is moved to brighter light. (Seeming change in behavior).

In the past auto-brightness did not do this. I could see how a quick peek at the light sensor reading and or better preservation of previous settings history might have prevented this too-dim thing programmatically. Perhaps something like that was lost during the recent changes..
[E 2015 Original Android Development] squid2:
I usually keep the brightness slider between 1/3 and 2/5, and always stay in auto brightness mode, so my usage is a bit different from yours. I hadn't realized how complicated the brightness logic has been made in Android. If I were implementing it myself, I would have just taken the last n samples, rejected a certain percentage of outliers from the n samples, taken the average of what remains, logarithmically adjust the average based on the slider setting, and then just map the computed light level to a brightness based off the setting in the overlays. I don't think the complicated logic used by Android behaves significantly better than this, but it does create a bunch of edge cases with undesirable performance. Oh well, I guess the complicated way works for most people so they haven't tried to simplify it.

EDIT: I looked over the code a bit more carefully. It is a bit overdesigned, but it does do something along the lines of what I described above. While I didn't look at it carefully enough to say with certainty, it seems to just take the computed "average" (not straight average but more complicated, though sort of thing), adjust it based solely off the current slider value (not any other relative level set earlier when in manual mode), and map it to a screen brightness based off the table in the overlay. It doesn't seem to care about previously set manual brightness, or I'm probably misunderstanding what you mean. You can see the relevant logic in this function: https://github.com/CyanogenMod/andr...splay/AutomaticBrightnessController.java#L478
[E 2015 Original Android Development] squid2:
You're certainly very thorough :highfive:

An auto brightness toggle in the status bar would definitely be convenient and make testing easier for this type of thing. I'll try to reproduce your behaviour when I get time.
[E 2015 Original Android Development] IronTechmonkey:
LOL Johny Test Pilot here cant code so I've got to do something.
[E 2015 Original Android Development] IronTechmonkey:
Pardon the self quote but a correction is in order: I thought I tested for this in the internal SD card's \Alarms folder but either something has changed since I tested or I got lost while testing. Although the alarm app's ringtone list does not seem to show contents of the external SD card's ringtone directory (which does work fine in the phone app), copying either OGGs or MP3s into the internal SD card's \Alarms folder rather than \system\media\audio\alarms allows them to be selected in the Alarm app's ringtone list with proper audio preview without any fiddling with permissions .Apologies for what turned out to be false report.
[E 2015 Original Android Development] squid2:
New May 10 Release

I've fiddled with some WiFi configuration files, and it seems to have made WiFi network detection a bit faster and more reliable. It still seems a bit slower to detect WiFi than stock, but I think it is better than before. Downloads will be up shortly.
[E 2015 Original Android Development] sumitps2:
Working good

Thanx a ton for this.:o Everything is working good for now. Just flashed it, I'll update on any issues.

But the gapps recommended by you is quite large sized. I tried another minimal gapps package and it was giving playservices FC issue. I'll wait for a minimal package before making it my go to rom.

Edit- even after unchecking the increasing ringtone box in sounds it still have that effect which is very very annoying for me:mad:
[E 2015 Original Android Development] Nirbhay2:
Recent key is working or not after restart..?
[E 2015 Original Android Development] raghavarora1997:
Minimal package works when you completely wipe everything (data, cache, system, dalvik cache) and then flash the ROM.
[E 2015 Original Android Development] raghavarora1997:
After reboot I'm also encountering those problems, recent tab not working play services FC.
[E 2015 Original Android Development] santoshvaza:
this release + euroskank gapps

while adding account in accounts option in settings, google option doesnot even shows up

play store doesnot opens, after opening it hides automatically

inshort recommended gapps is not working at all

this release + gapps mentioned on cm;'s wiki

first boot ok, recents, google signin works

reboot, "google play services FC" error at first screen.

recents not working, google authentication failed, sync error(it does not syncs at all it was syncing for 10min then i gave up) in gmail

I have attached log files(for this release + gapps mentioned on cm wiki),
[E 2015 Original Android Development] squid2:
Hmm, I seem to always have bad luck where things work fine on my phone but not for for people in other countries. I'm wondering what is different between your setups and my setup. Do older builds (eg. the first May 2 build) also encounter the gapps issues? I'm wondering if it's something I did or if it is a CM regression in builds from this past weekend.

The main differences between my device and Indian devices is that the Indian ones have dual SIM card slots and different modem software to support dual sim. I've heard of modem differences breaking android in subtle ways, but these kinds of issues are very difficult to debug, since they are usually caused by "black magic". I hope that the modem difference is not the source of trouble.

Another possibility is differences in locale settings. Which language and region are you selecting? English, Hindi, or some other language? If you are using English, which English (US, UK, Canada, etc.)?

I don't really know what is going on here.

[MENTION=5836072]santoshvaza[/MENTION] I'll check your logs when I get home. Maybe I'll get some insight.
[E 2015 Original Android Development] santoshvaza:
[MENTION=6485916]squid2[/MENTION]

English-India,
[E 2015 Original Android Development] sumitps2:
Recent key not working after boot. I tried English UK US & India but no difference. Gesture typing too is not working. But kudos to your awesome work on our Indian variant and I believe you will get everything fix in the very near future..
[E 2015 Original Android Development] squid2:
Thanks for the logs, I see more useful and potentially relevant bits in these logs than what I've seen before. I'll look into the issue over the next few days.
[E 2015 Original Android Development] squid2:
When your device is in the crashy state, do the following files exist on your device?

/system/framework/com.android.media.remotedisplay.jar

/system/framework/com.android.location.provider.jar

Your logs report that these files can't be loaded by ResourceManager, and the lack of these files seems to be causing a chain reaction of crashes.
[E 2015 Original Android Development] santoshvaza:
From where can i get these files if they do not exists,? also in cm12 otus help thread the gapps link points to wrong rom.
[E 2015 Original Android Development] sumitps2:
Left the phone over night and in the morning the recent tab was working again. Then did a soft reboot and the recent tab was still working. Then tried a normal reboot and it's gone..

Hope it helps rectifying the problem..
[E 2015 Original Android Development] squid2:
They should come with the ROM. They are present on my device.
[E 2015 Original Android Development] ShyPixie:
Hey,

Why you don't disable aDSP until this be fixed?

Is much more stable without kernel panics... :silly:
[E 2015 Original Android Development] squid2:
I've fixed the issue in the kernel. The next release will not kernel panic.
[E 2015 Original Android Development] squid2:
May 16 Release

I'm putting out a new release that has had a lot of work put into it. The main focus of this release has been the kernel. Beyond updating it to Linux 3.4.107, I've fixed the FM radio kernel panics, updated the WiFi drivers, further sped up WiFi network detection and connection, added in the FIOPS IO scheduler, and added in a bunch of other fixes for issues that were encountered in my testing. Furthermore, I fixed up the SEPolicy and have set SELinux to enforcing to improve security, and I also updated the vendor APKs with those from the otus stock ROM. Let me know and post your dmesg if you encounter any SELinux denials. Upgrading (dirty flashing, ie. not wiping data) should be fine with this release if everything is working on your current CM install. If something breaks after an upgrade, try a clean install before reporting your issue here.

IMPORTANT: Due to some recent changes in CM, you need to use CM gapps. Euroskank gapps are having issues with CM. The CM gapps have a much smaller download size than the euroskank ones, so that's an added bonus. The CM gapps have a few bugs of their own, but at least they mostly work.

Indian Users: I haven't done anything to fix the gapps crashes that you have been encountering. However, I do encourage you to try this release. Do a clean install, and try the CM gapps with the latest build. Maybe they will work, even after rebooting. Let me know if this new release works for you, or if the gapps issues remain.

Unfortunately, I was not actually able to fix the ADSP crashes when playing YouTube videos. I had it working for a while in my testing, but later more thorough testing found that the issue remained and occurs after a while. I did apply a bunch of cherry-picked Qualcomm patches to the kernel, and they did fix the FM radio and associated ADSP memory corruption issues. However, the crash with YouTube videos seems to now be happening inside the Hexagon ADSP, and to be honest, I know next to nothing about the Hexagon, and I don't have equipment to debug anything going on in there. When the ADSP encounteres a fatal error, it tells the kernel to panic and reboot the entire SoC. The crash is not in the kernel. I could try to modify the kernel to try to restart only the ADSP when it crashes, though I don't know if the ADSP will continue to operate normally after that. I could also look into disabling the ADSP for the problematic usecases, but I don't know if playback performance will be acceptable without the ADSP.

At least the system is pretty stable apart from playing YouTube videos (and maybe other videos). If anyone has any knowledge about debugging ADSP crashes, please share.

EDIT: Disabling FFMPEG offloading does seem to reduce the frequency of, but not eliminate the ADSP crashes. I'll do some more testing and release another build in a couple hours if it appears worthwhile.
[E 2015 Original Android Development] squid2:
May 16 Build 2

I've been fiddling disabling FFMPEG offloading, and it appears to reduce the frequency of (though not eliminate) ADSP crashes. I'm uploading a new build with FFMPEG offload disabled, and I'd suggest using this new build instead of today's earlier build.

IMPORTANT: You MUST wipe the system partition before installing this new build. You can do this through the Wipe->Advanced Wipe menu of TWRP. Upgrading (not wiping data) from an earlier build is fine, but be sure to wipe the system partition before installing this.
[E 2015 Original Android Development] raghavarora1997:
After rebooting both of yesterday's build are showing play services FC error.
[E 2015 Original Android Development] squid2:
Okay, I didn't do anything about the gapps crashes on Indian phones, so I'm not surprised that the issue remains. Could I get a logcat starting at boot and including the gapps crashes? It seems that the majority of the users of this ROM are in India, so I suppose addressing this issue should become my top priority for the next release.
[E 2015 Original Android Development] tarakavinash:
Move Option?

Can we get move option in gallery itself?

If yes how?

Thank You :)
[E 2015 Original Android Development] sinnerz2000:
You should consider learning coding, you might be pretty good at it.
[E 2015 Original Android Development] IronTechmonkey:
The encouragement is appreciated. Although one of my professional areas of expertise is testing & documentation, the memorization of coding language is a challenge for me. This is one of the reasons I'm so hooked on Tasker which I call "programming interface for non-programmers". Perhaps I should consider exploring real coding in the droid-i-verse.
[E 2015 Original Android Development] india_motoe2015:
Play Store crashes

Hello,

as I had meantioned in my previous posts I am still experiencing PlayStore crash every single time I am trying to update an app, as soon as I tap on 'update / update all'.

How do I produce / view log to find the culprit? Any help is welcome.
[E 2015 Original Android Development] india_motoe2015:
How do you find older nightlies?

Is there a way to find older nightlies? The oldest nightly offered by CM - which is actually downloadable - is 22-Oct-2015. I want to know if there's a way to find & download older nightlies - say, 15-Oct-2015 ?
[E 2015 Original Android Development] IronTechmonkey:
Have you tried the CGapps package which no one seems to have had problems with yet instead of the newer gapps packages with which there have been multiple reports of problems?
[E 2015 Original Android Development] Dexter_S:
I think you are running some apps to conserve battery. Which is killing services which are rather important. Once I tried Amplify & mistakenly disabled Google framework. Also check all the background data is enabled.
[E 2015 Original Android Development] IronTechmonkey:
Good point about apps. Has any one actually reproduced this issue:

- In a clean flash of ROM only?

- In a clean flash of ROM with CGapps?

- Before installing apps and tweaking settings?

Although Google Play store requires background data enabled, disabling background data (my default setting) should not a cause FC without additional factors. This does not seem to be ROM issue and, as a Gapps issue would be more appropriately addressed in a Gapps thread. If there is no XDA thread for OpenGapps I recommend that people experiencing these Google Play services issues check out XDA's Deltadroid Gapps thread where others have reported this same issue.

---------- Post added at 11:38 AM ---------- Previous post was at 11:34 AM ----------

You ask in the thread and hope some digital pack-rat geek has an older ROM in their collection. I've got some in the that range including 10/14 and can upload it in a few hours.
[E 2015 Original Android Development] Dexter_S:
I believe this is a self inflicted issue. I try not to go into all that battery saving crap as this only uses my CPU cycle more. I have tested Amplify & Servicely on the first official build of this ROM. But it caused a lot of FC issue. Servicely was stupid enough to terminate the service framework & play services when I was downloading an app & was in foreground. Only greenify is stable enough for my choice.
[E 2015 Original Android Development] IronTechmonkey:
Helpful feedback. Thank you. I don't use any of those apps but based on the popularity of Greenify (which i did test once) it would be my first choice. I have also used DisableService and Autostart Manager BUT one important thing to keep in mind is that some of those apps leave their settings in place after the app is un-installed; this makes testing in clean installations critical.

---------- Post added at 12:10 PM ---------- Previous post was at 12:07 PM ----------

[MENTION=6485916]squid2[/MENTION] Don't bother digging into auto-brightness just yet. A new commit (http://review.cyanogenmod.org/#/c/114987/) in the 10/27/15 nightly that just dropped is the reversion of an old commit from back in July 2015 which may be what broke auto-brightness' initial calibration to ambient light when first enabled. Credit to [MENTION=4418762]CWGSM3VO[/MENTION] for flagging this (somehow slipping in between my nearly hourly checks of commits:)).
[E 2015 Original Android Development] IronTechmonkey:
Clean-Flash Compare Clean-Flash Compare

The fact that something worked before is not a reason to forgo proper testing, in fact that is a very good reason to make sure you do proper testing, for a few particular reasons;

- To identify problems that may have existed previously but only recently surfaced (auto-brightness is a perfect example of this - a commit from 3 months ago broke something in a commit from last week and we just discovered this).

and

- So you can make sure your base material is OK (something you insist is the case without having done reasonable cross testing even though the situation calls for it)

There are 2 things to do at this juncture if you want to properly diagnose and address the Gapps problem you are having:

1) Test in clean flash of ROM/Open Gapps only AND test in clean flash of ROM/CGapps only (yes this is work but that is what goes on here ;)).

2) Take it to a Gapps thread since this is not a ROM issue. Pardon my frustration but troubleshooting even a tidy gapps installation is off topic in this thread, and troubleshooting one where there is a refusal to do clean comparative testing and remove 3rd party factors is even further out of bounds. Occasionally these google services issues do indicate a problem in CM (as was the case when google rearranged the structure of GFS last year and CM had to adjust) but the evidence indicates otherwise this time around and to gain any traction clean testing and proper comparisons are a must.

BTW If you still want the 10/14 nightly here it is, http://www.filedropper.com/cm-121-20151014-nightly-otus, but you may save yourself time and be more useful to the cause of testing CM12 if you use the newest nightly, which I am flashing at this very moment. I'll keep an eye on Gapps although, I clean flash more than once a week and have never had Gapps issues in this ROM at all in any of them.
[E 2015 Original Android Development] IronTechmonkey:
10/27/15 nightly = Auto-brightness working better but new FC when attempting to add QT (confirmed in additional clean flash of ROM only) sent me back to a nandroid backup . Sadly, configuring Quick Tiles is at the end of my initial 2-3 hour install, test and build-out process and I had no time left to log it. Grrr - what a waste. Others can confirm, log, and report the QT FC. It is obvious and easy to reproduce by attempting to add a quick tile, and there is no commit to fix it yet. This is the one case in which CM will let us submit official bug reports since this is a nightly regression (good in previous nightly - bad today) and that can be done here https://jira.cyanogenmod.org/. After someone creates a jira ticket we can vote on it. I do not see the QT FC in 10/21/15 nightly but do see it in 10/27/15 so it would also help if people could confirm it in 10/27/15 and test for it in nightlys between 10/21 and 10/27.
[E 2015 Original Android Development] squid2:
I can confirm your Quick Tiles creation force close. I haven't tried the latest otus nightly, but the same issue is happening on my Moto X Play (lux).
[E 2015 Original Android Development] IronTechmonkey:
Thanks. I did observe the issue it in the latest otus nightly so if it is also happening on the X it surely is a ROM issue. If it is still happening when I test in a few days I'll create a jira ticket, although if it is widespread it might get attention quicker than that

[EDIT] ... and there it is.

https://jira.cyanogenmod.org/browse/NIGHTLIES-1953. I voted for it and added confirmation of 10/21/15 as last known good. It would be great if anyone on an otus nightly between 10/21 and 10/27 could see if if occurs in that nightly and add details, and if anyone who reproduces it votes for the issue at jira.

[EDIT] QT Settigns FC fixed in otus 10/28.

[EDIT] Auto-brighness is working better now. It seems that what was missing was a command to set a first time value for brightness slider with auto-brightness enabled, which is now 50%. From there it can be adjusted and will work around last slider value set with brightness enabled, then when auto-brightness is disabled it will reset to the last brightness slider value used when auto-brighness was disabled...and it is more responsive and useful in general than it was before.