A little late due to the US holiday at the start of the month and some higher than average patches for review and acceptance, but none worse for the wear the M10 release of CM11 is upon us. The M10 code was branched on September 9th, with additional patches merged over the course of the last 6 days to fix identified gaps. A changelog is provided towards the end of this post.
As always, we are not infallible, and there may be items that we have not yet resolved (or know about). To help combat this issue and make things easier for you and us, we’ve introduced a new tool into the CM arsenal, the CM Bug Tracker application. Whenever you crash a system application, you will be prompted with an option to upload a snippet of a log to us – namely the actual crash reported by the system and the stacktrace that accompanies it – similar to what you are already used to by the various app stores you may use.
In addition to the above, we’ve added a field to the ‘take a bug report’ option found in Developer Settings. Upon generation of a bug report through that mechanism, you may optionally send us a scrubbed copy of that bug report via the send action you are presented with. Please note that while we have taken precautions to scrub all the standard identifier data provided in these logs, some third party apps may erroneously dump that info into the logs and may not be caught by our filters. The data you provide via this bug report option will only be used by CM developers to fix the crashes reported, will comply with the Privacy Policy CM operates under, and going one step further, can only be seen by CM team members (ie not publicly visible outside of the examples here) and deleted monthly.
I’m going to harp on this a bit further because this sort of item can always be misconstrued. Here is an example ticket generated by a CM user while I was drafting this blog post:
And here is a snippet of the content we receive: http://pastie.org/private/urfviyajaltbvczhqfquiw
From this information, we can tell what device, build, kernel, and Android runtime the user was using at the time of submission, and the message the user wished to convey (in this case “Dunno” & “nothing”). If this were a true report (versus what appears to be testing), we would use the corresponding log to assist in triaging the bug, and hopefully fixing it. This process, as trialed in the nightlies, has already allowed us to provide patches specifically to address these semi-automated reports.
For the sake of clarity, this scrubbed report is only generated on user action and upload via the ‘take a bug report option’, the crash log stacktrace mentioned above does not have any info beyond the crash itself, and therefore is already a scrubbed copy. For the curious, this is what one of those automated tickets looks like:
M10 Changelog:
* New Devices: Galaxy S5 Sprint (kltespr) * Split out Note 3 into GSM (hlte), Sprint (hltespr) and Verizon (hltevzw) * Refactor moto_msm8960dt as ‘ghost’ for Moto X 2013 * Drop support for obake, toro, toroplus * Theme Engine: Themes support for additional UI elements * Frameworks & Core Apps: CAF and other upstream updates * Settings: Add scramble pin feature * Frameworks: Long press recent apps to switch to last used app * Settings: Add soft reboot option * Add smart cover support * Add glove mode support * Add bug reporter and crash log uploader * Multisim updates * General bug fixes (many many) * ANT+ Support for various hardware * Privacy Guard: Control NFC permissions-The CyanogenMod Team