yashsingh1/xdaforums huggingface dataset:
[Moto G Original Android Development] tlwhitec:
Take a breath :) I'd rather suggest before you go all the way building/flashing a modified kernel, you could probably decode what the 'androidboot.powerup_reason' value means. It should be greppable in the kernel source. I really doubt it makes the difference (but then again, it's interesting what it means). Same with the 'bootreason', this is probably affected by the way guys turned off / rebooted their phones. I don't know how [MENTION=3816475]matmutant[/MENTION] induced a "hardware_reset", but he surely can tell ;)
[Moto G Original Android Development] knizmi:
[MENTION=3101826]wskelly[/MENTION]

I´ve got androidboot.powerup_reason=0x00004000 and bootreason=reboot on 4118. It´s just a way how and why the phone was turned on, nothing more. And I highly doubt you can change those parameters in the kernel manually...

Matmutant´s phone likely crashed before he checked the cmdline, others have just rebooted. When I turn the phone off and then turn it on (no reboot, but actual off and on), I get androidboot.powerup_reason=0x00000080 and bootreason=power_key_press.

As [MENTION=5290873]tlwhitec[/MENTION] said, no way you´re gonna fix the ripple this way. Just update your bootloader finally...
[Moto G Original Android Development] matmutant:
Sure, i had forced rebooted right before :)

here is the argument after a reboot :

bootreason=reboot
[Moto G Original Android Development] wskelly:
[MENTION=5354072]knizmi[/MENTION] Oh my god. No, [MENTION=5290873]tlwhitec[/MENTION] didn't say that, he said I needed more info before drawing a conclusion -- and he was right.

The ripple actually doesn't bother me (it goes away), the assert that doesn't let me update without a workaround bothers me. Total chaos in multiple other threads bothers me. Bricked phones bothers me.

I'm not doing it, (and nobody else should) until there is a clear explanation why. The ripple never happened in production so it doesn't come from the BL. It comes from somewhere else, almost assuredly the kernel. This isn't magic, this is software, and there IS an answer. I would even accept "I DON'T KNOW" as an answer but then the assert would need to come out. As an embedded programmer myself with 16 years of professional experience, I won't accept general statements like "causes bugs" from other developers. Which bugs? Does anyone in this 'development' thread actually want to talk about s/w and root cause? This was a popular phone and there are a still a lot of people out there with the old BL who didn't update. That phone will probably wind up here asking a question OR in one of the brick threads.

I thought I saw a mention of there being a ripple in TWRP even after the bootloader update? True? Or did this get resolved?

Guys, I'm just too old and I've worked for a German company for too long to just accept generic answers. And know I've been asking this question since ... I dunno, March? Or just ignore my posts, I couldn't care less. I've already had one PM from a guy who thanked me for continuing to try and get an answer so -- [MENTION=3101826]wskelly[/MENTION] (2) vs. everyone else, I'm okay with it. :cool:
[Moto G Original Android Development] JoaoMarcos:
Guys I'm having FC in Settings app when I try to do a factory reset. It happen when I touch in 'Factory data reset' option.

Error:

java.lang.RuntimeException: Unable to start activity ComponentInfo{com.android.settings/com.android.settings.SubSettings}: java.lang.IllegalArgumentException: Failed to find storage device at /storage/sdcard1

at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2356)

at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2418)

at android.app.ActivityThread.access$900(ActivityThread.java:154)

at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1321)

at android.os.Handler.dispatchMessage(Handler.java:102)

at android.os.Looper.loop(Looper.java:135)

at android.app.ActivityThread.main(ActivityThread.java:5289)

at java.lang.reflect.Method.invoke(Native Method)

at java.lang.reflect.Method.invoke(Method.java:372)

at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:904)

at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:699)

Caused by: java.lang.IllegalArgumentException: Failed to find storage device at /storage/sdcard1

at android.os.Environment.isExternalStorageRemovable(Environment.java:831)

at com.android.settings.MasterClear.establishInitialState(MasterClear.java:183)

at com.android.settings.MasterClear.onCreateView(MasterClear.java:225)

at android.app.Fragment.performCreateView(Fragment.java:2053)

at android.app.FragmentManagerImpl.moveToState(FragmentManager.java:894)

at android.app.FragmentManagerImpl.moveToState(FragmentManager.java:1067)

at android.app.FragmentManagerImpl.moveToState(FragmentManager.java:1049)

at android.app.FragmentManagerImpl.dispatchActivityCreated(FragmentManager.java:1869)

at android.app.Activity.performCreateCommon(Activity.java:5985)

at android.app.Activity.performCreate(Activity.java:5992)

at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1106)

at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2309)

... 10 more

Someone too?
[Moto G Original Android Development] Tridon:
[MENTION=3101826]wskelly[/MENTION]

I've been following this thread for a while now and you seem to know your way around some of this stuff. The good part about posting publicly is that the community can test and debate opinions. I'm willing to test a few things for you, I'm using a XT1033 (Asia Retail / Dual SIM) with CM12.1 and yes, an updated bootloader, 41.18. How can I help resolve your query ?
[Moto G Original Android Development] tlwhitec:
Can't talk entirely on [MENTION=3101826]wskelly[/MENTION]'s behalf, but since I interfered already.. I think he won't object.

What would really help this cause would be a good deal of archaeology/forensics. We need to identify the exact boundary between firmwares, where the flickering started on 41.13 and stopped with the upgrade to 41.18.

From what I read earlier, it seems there was a single point in time, where this got switched. I remember reading that early adopters, who got the new BL before CM adapted, started to flicker on it, while those on 41.13 were still OK. And then flip - and it was the other way around. We need to identity this flip and the information could be even in this thread's history.

My secret bet is the time when Motorola released the 5.0(?) source and CM has been rebased on it. I can imagine finding out what got changed for the kernel between KK and LP can be really tricky (potentially a lot of changes) and that the one doing the merge/rebase simply didn't bother. You know how it goes, if there were no conflicts and it builds fine, I declare it "magic" and move on. There's no time/reason to dig in it and I perfectly understand it. This would also explain why none of the devs is able to clarify the flickering issue (Should they know, they would hardly resist [MENTION=3101826]wskelly[/MENTION]'s rant :D No offense, man!) I bet someone already knows when this happened. Most likely the dev doing the merge, but I don't have a clue who might that be (and I'm yet not totally friends with gerrit and github to find out myself).
[Moto G Original Android Development] wskelly:
Okay, I have more info from [MENTION=4792450]h2o64[/MENTION], who is trying to get Ubuntu to boot (look for his progress in another thread, we're I not on my phone I would link here).

Basically he says that the flicker is caused by a change in the bootloader to "dts" values which were not the same as the original production values. This is compensated in the kernel, so if both match, you don't see the problem. I suspect it could easily be fixed on the kernel side to support BOTH bootloaders.

So when people got the OTA with updated bootloader, they probably noticed this flicker and compensated for it with a kernel change. There was no effort made to fix this flicker issue for the old bootloader and instead just force a specific bootloader with assert(). If this is the only reason, this is pure laziness (sorry) and has caused an extraordinary amount of chaos and bricked Falcon.

But there's more. [MENTION=4792450]h2o64[/MENTION] also tells me that there is a MDSS Quickdraw feature in the LP kernel that requires some info from the updated BL. He seemed surprised that the LP kernel works without this additional info, so I asked him if there is a way to check if the MDSS Quickdraw feature is enabled for me.

So stay tuned and thanks for the friendly discussion. ;)

[MENTION=5399566]Tridon[/MENTION] [MENTION=5290873]tlwhitec[/MENTION]
[Moto G Original Android Development] vik@ram:
Yeah I am having the same !!
[Moto G Original Android Development] tzzeri:
Try stock theme
[Moto G Original Android Development] matmutant:
I'm sorry to say that, but Device brick isn't caused by dev's lazyness but by end-user dumbness. Why is that? because people flash things without reading tutorials, without cheking the integrity of files they download... [see here]

So EVEN if for some reason the bootloader is not mandatory and get reverted there will be bricks... ALWAYS. I'm over here for enough time to see people bricking their devices in ways i wouldn't even imagine!

I don't have much time to spent on this issue right now (still trying to debug my Charge Current and pm8226 overheat issue : http://xdaforums.com/showpost.php?p=61508750&postcount=576)

edit : to be honest i don't exactly disagree with you, it's always good to understand the root of things ;)
[Moto G Original Android Development] vik@ram:
I am in stock theme only..
[Moto G Original Android Development] tzzeri:
For a workaround, factory reset in a custom recovery
[Moto G Original Android Development] JoaoMarcos:
Yeah, but we have bug with factory reset option in CM. ( Failed to find storage device at /storage/sdcard1)

Can anybody report in JIRA?

java.lang.RuntimeException: Unable to start activity ComponentInfo{com.android.settings/com.android.settings.SubSettings}: java.lang.IllegalArgumentException: Failed to find storage device at /storage/sdcard1

at android.app.ActivityThread.performLaunchActivity(A ctivityThread.java:2356)

at android.app.ActivityThread.handleLaunchActivity(Ac tivityThread.java:2418)

at android.app.ActivityThread.access$900(ActivityThre ad.java:154)

at android.app.ActivityThread$H.handleMessage(Activit yThread.java:1321)

at android.os.Handler.dispatchMessage(Handler.java:10 2)

at android.os.Looper.loop(Looper.java:135)

at android.app.ActivityThread.main(ActivityThread.jav a:5289)

at java.lang.reflect.Method.invoke(Native Method)

at java.lang.reflect.Method.invoke(Method.java:372)

at com.android.internal.os.ZygoteInit$MethodAndArgsCa ller.run(ZygoteInit.java:904)

at com.android.internal.os.ZygoteInit.main(ZygoteInit .java:699)

Caused by: java.lang.IllegalArgumentException: Failed to find storage device at /storage/sdcard1

at android.os.Environment.isExternalStorageRemovable( Environment.java:831)

at com.android.settings.MasterClear.establishInitialS tate(MasterClear.java:183)

at com.android.settings.MasterClear.onCreateView(Mast erClear.java:225)

at android.app.Fragment.performCreateView(Fragment.ja va:2053)

at android.app.FragmentManagerImpl.moveToState(Fragme ntManager.java:894)

at android.app.FragmentManagerImpl.moveToState(Fragme ntManager.java:1067)

at android.app.FragmentManagerImpl.moveToState(Fragme ntManager.java:1049)

at android.app.FragmentManagerImpl.dispatchActivityCr eated(FragmentManager.java:1869)

at android.app.Activity.performCreateCommon(Activity. java:5985)

at android.app.Activity.performCreate(Activity.java:5 992)

at android.app.Instrumentation.callActivityOnCreate(I nstrumentation.java:1106)

at android.app.ActivityThread.performLaunchActivity(A ctivityThread.java:2309)

... 10 more
[Moto G Original Android Development] wskelly:
It is just a philosophy thing. Toyota, for example, believes that quality should be part of the process. Meaning, even a complete idiot couldn't screw it up if they tried. The assert() is trying to, I guess, ensure that people never experience the horror of a flickering screen at first boot, but it *forces* people with no experience to start messing with the single most dangerous piece of software on the phone. And, like you pointed out, download and flash this file (11k times!!!) without checking the md5, because they probably don't know what md5 is.

Now there may be some kernel feature which is disabled on my phone right now, I hope I can find that out and then I would have a reason to update... But if this is really a screen flicker thing, it can be fixed in the kernel as I originally (March or so?) suspected.

Just to reiterate, the bootloader does not care if it boots KK or LP or Ubuntu or Firefox OS. It sets up some hardware (which hasn't changed) and loads the kernel. If there is some nuance, like the new BL makes information available to the kernel that wasn't available before, and without it some other feature in the kernel won't work... This is all I want to know and a bigger deal than the flicker.

But still if it works decently with 4113 as I am typing on it now, there should be a warning that the BL may cause issue "X" and "Y" instead of preventing the flash and forcing people to seek out and flash a bootloader, when there is no need to. This would not be a "quality concern" for an aftermarket ROM (you were warned this isn't supported) and we would have fewer bricks, and perhaps better educated users (they (>11k people!) understand *why* they are updating the BL). They can try CM and go back to KK if they want (cannot downgrade BL after update).

Anyway I'm still happy to have CM and I said so in my post to luca a few days ago... But a bootloader update should be approached with absolute caution and only if absolutely necessary.
[Moto G Original Android Development] matmutant:
[MENTION=3101826]wskelly[/MENTION], the problem with allowing an old bootloader is the amount of complaints. EVEN with the BIGGEST WARN like :

We'll still see a large amount of "my screen is flickering, pls fix it asap!!!!!!!"

So the assert is the simplest way to prevent complaints ==> Wrong BL = No update = No complains ;)
[Moto G Original Android Development] fonz93:
Updating the bootloader is not risky! it's just a command in fastboot, and for people that are scared about this update, they can just flash STOCK LOLLIPOP by Motorola by OTA or with RSD LITE that will do all automatically (including updating the bootloader), brick it's only for people that don't read and do things random.

I think you can upgrade the bootloader easily and without any problem, if Motorola updated the bootloader there's a reason, as i said previously, it's not an unofficial thing.

Regarding peoples that bricked their device, i am sorry for you but it's your fault, probably you didn't follow the right procedure, because there is nothing that could mess your bootloader if you've done things right.

And anyway, you can back to Kitkat even using the new bootloader, having the same screen flicker you're having now on CM12.1.

The point in this discussion is, you (and all the peoples with 41.13) are not scared about bricking your device updating the bootloader (because it's really too easy), but you just want to have a stable ROM (stock 4.44) to go back without ANY bug (screen flicker included) if CM12.1 (or stock Motorola 5.0) won't be stable for you; If i am wrong, then you should consider to end this discussion, as you are perfectly able to update your bootloader without bricking your phone, and i repeat, the peoples that bricked their device should read more before doing things.
[Moto G Original Android Development] matmutant:
Come on my friend, you admitted yourself you didn't read my FAQ before installing CM, don't expect end-user to read tutorials ;)

I agree with [MENTION=3101826]wskelly[/MENTION] in the way it's always to understand why upgrading, but most people don't care and flash. I don't think the issue is in the assert or the update or anything : the issue is End-user, the dumb one, that download, flash, complains and only then reads the FAQs.... :rolleyes:
[Moto G Original Android Development] fonz93:
I didn't read the FAQ (there's not such a thing on MoDaCo) because i didn't know there was one.. I just flashed recovery and CM because i knew it was the right procedure (well, official TWRP is made for 41.13 bootloader and i didn't know why the screen was flickering), anyway once i discovered there was a FAQ section, i read that and i also read all the bootloader updates and bug related stuffs. Anyway, when a procedure is risky, i don't do things random... When i took this device my bootloader was 41.18 already, also we all know that with a fastboot working you can always restore your phone.
[Moto G Original Android Development] chirag03:
I m facing issue ... With screen Wake up delay at the time of incoming call.? Wt abt this?
[Moto G Original Android Development] UltraMaks:
Confirm. Sometimes it takes 3-4 seconds before the screen wakes up and shows who is calling
[Moto G Original Android Development] tzzeri:
This discussion is stupid. Personally, if I was making the ROM, I would allow it for older bootloabout, but cm has the right not to, especially when there's a bug (like the screen bug [no, not screen flicker, because no one has a problem of the screen flickering. Unless you don't know English]). And about updating the bootloader, most people using the moto g have updated it. Even people who have no idea what a bootloader is. How? Well, there's something called ota...

And it's actually quite hard to permanently brick your phone, even with messing with the BL.
[Moto G Original Android Development] wskelly:
I fell asleep reading this reply.

"Something called OTA" will only happen if you are on stock firmware.

Some phones did not get an OTA to LP (US retail, the model I have, was specifically one that did not)

ELEVEN THOUSAND PEOPLE downloaded the [MENTION=3816475]matmutant[/MENTION]'s bootloader (and he is not the only one who posted it), so all of those people missed "something called OTA"

Messing with the BL is basically the only way to brick your phone.

Please tell everyone in the multiple threads of bricked Moto Gs how difficult it is to brick their phone.
[Moto G Original Android Development] :
Can anyone else not install an OTA update through the phone? Whenever I go to Settings -> About phone -> CyanogenMod updates, I can download the latest nightly, however whenever I try to install it by tapping the install button, my phone reboots and CWM shows for a split second, and then my phone turns on as normal without the newly installed update. It works fine if I flash it manually however.
[Moto G Original Android Development] bloodhound42:
Flash twrp recovery as the developer recommended it and it updates automatically :)
[Moto G Original Android Development] :
I tried TWRP but I have a similar problem. TWRP just starts as normal and does nothing.

EDIT: I was probably using the wrong version of TWRP. I just installed the recommended version and I will try it next time there is an update. Thanks.
[Moto G Original Android Development] chirag03:
Cant b it fix...?
[Moto G Original Android Development] :
I've come straight from stock lollipop to CM 12.1 and my GPS is no longer working. Is there a way to fix this or is this simply not implemented yet?
[Moto G Original Android Development] bogante:
Use this commands

mfastboot erase modemst1

mfastboot erase modemst2

Enviado desde mi XT1032 mediante Tapatalk
[Moto G Original Android Development] :
Thanks, I should have read the FAQ. :angel:
[Moto G Original Android Development] tzzeri:
I fell asleep reading this reply.-Do a sleep study test, unless it's late at night by you

* "Something called OTA" will only happen if you are on stock firmware.-so flash stock firmware and then upgrade

* Some phones did not get an OTA to LP (US retail, the model I have, was specifically one that did not)-that's the only one that didn't get it yet, a small fraction of all users. But they still can flash firmware from a different country and upgrade.

* ELEVEN THOUSAND PEOPLE downloaded the [MENTION=3816475]matmutant[/MENTION]'s bootloader (and he is not the only one who posted it), so all of those people missed "something called OTA"-so what? That's a tiny fraction of the amount of people who use moto g. And it's people who feel confident they know how to flash something (I.e. not you)

* Messing with the BL is basically the only way to brick your phone.-I have upgraded, tried to downgrade (yes, I know that was stupid, but the instructions on a thread weren't clear), flashed different firmwares from different variants with the BL. I've never been bricked.

* Please tell everyone in the multiple threads of bricked Moto Gs how difficult it is to brick their phone.-I just went through the q&a thread, quite a bit of it.I just went through the q&a thread, quite a bit of it. I found several threads saying how to unbrick the phone, but I didn't see threads about people bricking their phones with the BL.
[Moto G Original Android Development] Droidriven:
Hey guys, what's up with all the nit-picking about the bootloader?

Regardless of personal experiences, who posted what where, individual opinions or anything else, if you brick YOUR device then its YOUR fault, there are no guides that will lead you into a brick if every detail is properly read, understood and followed, if you don't understand it then read and research, if you have doubts(whether in the dev that makes a mod, the OP that posts it or in your own understanding and skill), then DONT FLASH IT.
[Moto G Original Android Development] bloodhound42:
hmm android updated to 5.1.1 r5 :p

here's the changelog

http://aosp.changelog.to/android-5.1.1_r4-to-android-5.1.1_r5.html
[Moto G Original Android Development] Orjakone:
Because the system in CM consumes so much memory?

In stock consumption is around 100 MB, while the CM is around 300MB.
[Moto G Original Android Development] luca020400:
Because Motorola settings reports wrong values ( I don't this is a bug , probably Motorola choice ... )

I diffed ram usage in stock & cm and cm is better then stock

---------- Post added at 07:26 AM ---------- Previous post was at 07:25 AM ----------

Wow

Looks like r5 is a "big" release
[Moto G Original Android Development] bloodhound42:
yeah i hope soon cyanogenmod will merge it :)
[Moto G Original Android Development] Halogoop:
BUG

Great ROM but I found a bug. I think Its a Cyanogenmod issue where if you are in full screen mode for example (Clash of Clans,Boom Beach, Etc.) it is VERY hard to pull down status bar.

Only way is to drag the softkeys from the side but it is a bit annoying to keep doing that as it is a habit for me to drag it from the top to check the time or so.

I have heard you can disable the interactions between apps and status bar in developer options but never found it. Also the expanded desktop setting is set

to none so I have no idea why this is happening! If you have a solution please do not hesitate to reply.

Overall if you do not mind this issue the ROM is very smooth and stable, battery life is ok and performance is great. I love the theme for the Messaging app!
[Moto G Original Android Development] michalurban:
I see the LED blinking problem is still present. It blinks for some notifications and then stay on.
[Moto G Original Android Development] Alberto97:
That changelog lists more changes than they are because Google didn't start from android-5.1.1_r4 but before; so actually most of those changes were already there before this release.

The most important feature of this update is the WiFi Calling (http://www.androidpolice.com/2015/0...ndroid-5-1-1-update-lyz28e-with-wi-fi-calling) which probably isn't supported by Moto G (/my carrier/here in Italy?) since I can't see new fields on AOSP...