gsu_golfer
Member
Can I flash this over Apex (and wipe appropriately, of course)?
DroidForums.net | Android Forum & News
This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!
[ROM] [6/6/2012] CM7 for the Droid Pro based on GB
- Thread starter JackpotClavin
- Start date
Battery Drain from Phone Idle and Cell Standby
I have noticed that "phone idle" and "cell standby" have been draining a ton of battery. I don't have anything set for auto-sync, and I have good coverage. Last night I didn't charge my phone to see what would happen, and I lost about 60% over 6 hours. I've searched all over the place, and I've seen a lot of people who have this issue w/ CM, but I haven't seen a fix.
I turned all location services off, and I thought that helped for a while, but it didn't.
I updated my CM7 building to the one from 10.24, but still saw the battery drain.
I don't use my phone heavily, but when I was on Froyo, I could generally get through a day with normal use, and when I first rooted and installed CM7 I was getting a solid 18 hours with 20% battery left, but now it drains 10% every hour without any use at all. Phone idle and cell standby are the culprits.
How do I fix this? What's going on?
I have noticed that "phone idle" and "cell standby" have been draining a ton of battery. I don't have anything set for auto-sync, and I have good coverage. Last night I didn't charge my phone to see what would happen, and I lost about 60% over 6 hours. I've searched all over the place, and I've seen a lot of people who have this issue w/ CM, but I haven't seen a fix.
I turned all location services off, and I thought that helped for a while, but it didn't.
I updated my CM7 building to the one from 10.24, but still saw the battery drain.
I don't use my phone heavily, but when I was on Froyo, I could generally get through a day with normal use, and when I first rooted and installed CM7 I was getting a solid 18 hours with 20% battery left, but now it drains 10% every hour without any use at all. Phone idle and cell standby are the culprits.
How do I fix this? What's going on?
K guys it's been a while since I've done anything on this thread, but I'll give you guys a little bit of an update
1. No, I haven't forgotten about you guys
2. I bricked my phone doing something dumb (flashing files you should will never be flashing so you phones will be fine, I promise
)
3. I'm getting another Droid Pro in a few days
4. Ice Cream Sandwich source code is getting released as we speak, so depending on how quickly it's implemented into CM9 or not, our next build might be Android 4.0 instead of 2.3.7, but if it doesn't look like it will be ready anytime soon, I'll make another few builds of Gingerbread for y'all
1. No, I haven't forgotten about you guys
2. I bricked my phone doing something dumb (flashing files you should will never be flashing so you phones will be fine, I promise
)3. I'm getting another Droid Pro in a few days
4. Ice Cream Sandwich source code is getting released as we speak, so depending on how quickly it's implemented into CM9 or not, our next build might be Android 4.0 instead of 2.3.7, but if it doesn't look like it will be ready anytime soon, I'll make another few builds of Gingerbread for y'all
Freak4Dell
Member
Wow...source code release before the first phone is even released. CM devs are going to have a great night tonight.
Haha there actually hasn't been any talk about it by the devs unless I've missed it completely 
I'm really hoping Verizon is pulling their hair out over the fact that there will be other ICS phones on the market and hopefully they will move their a$$ and release the Nexus already
I'm really hoping Verizon is pulling their hair out over the fact that there will be other ICS phones on the market and hopefully they will move their a$$ and release the Nexus already
Freak4Dell
Member
Haha there actually hasn't been any talk about it by the devs unless I've missed it completely
I'm really hoping Verizon is pulling their hair out over the fact that there will be other ICS phones on the market and hopefully they will move their a$$ and release the Nexus already
Yeah, there's rumors going around that the Nexus might be delayed now. Honestly, I don't think anybody will be able to release an ICS phone before the Nexus even if it is delayed to December, but if Verizon doesn't release it soon, it's HIGHLY possible that we'll have phones running AOSP ROMs before it's out.
Right that's what I meant there's no way a company can make an official ICS build for a phone before the nexus gets released in the next month or so
there's no way a company can make an official ICS build for a phone before the nexus gets released in the next month or soVery glad to hear, Jackpot.
I look forward to your ICS build. I just bought you another beer to compensate for your loss so you can get to a club, sit lonely in a corner and weep ;-)
I hope everybody following this thread is doing the same for jackpot. Bricking a droid pro is seriously some tragic loss.
But in a honesty, thank you for everything that you've done to us the droid pro users community. Without you we would be forever f'cked with the Motorola blur crap.
I look forward to your ICS build. I just bought you another beer to compensate for your loss so you can get to a club, sit lonely in a corner and weep ;-)
I hope everybody following this thread is doing the same for jackpot. Bricking a droid pro is seriously some tragic loss.
But in a honesty, thank you for everything that you've done to us the droid pro users community. Without you we would be forever f'cked with the Motorola blur crap.
Last edited:
hahaha i wouldn't ask for a donation because i made a mistake on my part but thank you for your kindness my good sir : P
I'm so pumped for ICS
I'm so pumped for ICS
Jackpot, I know a thing or two about Android and linux too (but not to the point that I could deal with the 2nd-init stuff). I wonder if there is anything that makes glueing CM9 significantly convenient/easier/better compared to just glueing Vanilla AOSP, or it's just your preference to work with CM9? Or CM9 already have branches that are suitable to D2G/DP and so it's just more convenient to build from CM9 rather than having to do everything from scratch compared to could?
From what I've seen, I think Android 4.0 Vanilla is actually usable now. Other than having the power control in the drop-down menu, I don't see much advantage of having CM9 compared to vanilla 4.0 -- at least to the sense that there are features that I needed in CM but it's not present in Vanialla.
I'm gonna be relatively free on December (graduating yay) so maybe I will jump in and research on this Motorola stuff and will probably churn out ROMs too. If all is well, of course.
From what I've seen, I think Android 4.0 Vanilla is actually usable now. Other than having the power control in the drop-down menu, I don't see much advantage of having CM9 compared to vanilla 4.0 -- at least to the sense that there are features that I needed in CM but it's not present in Vanialla.
I'm gonna be relatively free on December (graduating yay) so maybe I will jump in and research on this Motorola stuff and will probably churn out ROMs too. If all is well, of course.
Last edited:
Freak4Dell
Member
Honestly, I agree with you. I think Google took a long hard look at CM and other custom ROMs, because there are a few things in ICS that originated in custom ROMs. Stock ICS pretty much has every feature that I like about CM7.
If you do end up making a vanilla ICS ROM, I'd be down to give it a try.
I wonder what you have read from the Motorola Droid threads that made you finally able to implement 2nd-init.
By that I meant supposedly I have a rootfs (system image?) that is supposedly run well provided the phone doesn't have a locked bootloader. Now of course it won't run with out motorolas, so what kind of thing that you need to add to it to trick the phone into loading the 2nd init? I see 2ndinit.zip or something like that in /etc/ but I wasn't sure how the boot process works so I don't know how it got called and what makes motorola phones think that the 2nd init is something legit to load at boot.
By that I meant supposedly I have a rootfs (system image?) that is supposedly run well provided the phone doesn't have a locked bootloader. Now of course it won't run with out motorolas, so what kind of thing that you need to add to it to trick the phone into loading the 2nd init? I see 2ndinit.zip or something like that in /etc/ but I wasn't sure how the boot process works so I don't know how it got called and what makes motorola phones think that the 2nd init is something legit to load at boot.
Well, I'm sure if CM9 will not be nearly as modified as much as CM7 was compared to stock 2.3. The cool thing about CM modifying the source is to allow even greater customization (like the ability to change backlight values and thresholds and the ability to change the launcher behaviors and whatnot) then stock allows. Many people don't use these features at all or don't even see them but they offer the choice for those who would like it. The special thing about CM7 compared to stock is that stock as of right now is only meant to build for the Galaxy Nexus which has different hardware than our phones. That, along with how 4.0 source needs to be modified in order to be reverse compatible with 2.3 or even 2.2 files that we take directly from our stock motorola builds (libcamera.so, gps.so, lights.venus2.so) just like how 2.3 source had to be modified for froyo proprietary files
Oh I see, so it means that we can't rebuild things like libcamera.so -- for example -- from source because we simply don't have source. But I guess because I saw kernel sourcecode from Moto on opensource.motorola.com -- everything else that we had source should be buildable, right?
So what it entails is that if we would build AOSP as it is now, modify build.prop for it so it fits the Pro and jam some 2ndinit stuff to convince the Pro to load it, and flash it to our phone we won't be able to use our camera, backlights and gps?
So what it entails is that if we would build AOSP as it is now, modify build.prop for it so it fits the Pro and jam some 2ndinit stuff to convince the Pro to load it, and flash it to our phone we won't be able to use our camera, backlights and gps?
I did not write 2nd init, it was originally made by these genius developers for the Motorola Milestone (first device with locked bootloader, it's the GSM version of the OG Droid) and then the developer CVPCS ported it to the Droid X which also appear to work with all subsequent Motorola phones
What the locked bootloaders do is it has a signature in the boot.img file which contains the kernel (the backbone the system) and something called the ramdisk which contains a bunch of scripts necessary to boot the system and a file called init that Motorola made. Normally with phones that have an unlockable bootloader is they disassemble the boot.img and take the kernel and replace the ramdisk with a custom one for CM and reassemble it and flash it to the phone. However, making a custom boot.img will fail the signature checks and the phone won't boot. So what 2nd init does is it hijacks the boot process and unzips the hijack-boot.zip (which contains our ramdisk that we weren't able to modify) and unzips it after the signature check is completed so we can have a custom ramdisk that allows us to boot CM. It's kinda like a trojan horse but in a good way. Hope this helps : D
What the locked bootloaders do is it has a signature in the boot.img file which contains the kernel (the backbone the system) and something called the ramdisk which contains a bunch of scripts necessary to boot the system and a file called init that Motorola made. Normally with phones that have an unlockable bootloader is they disassemble the boot.img and take the kernel and replace the ramdisk with a custom one for CM and reassemble it and flash it to the phone. However, making a custom boot.img will fail the signature checks and the phone won't boot. So what 2nd init does is it hijacks the boot process and unzips the hijack-boot.zip (which contains our ramdisk that we weren't able to modify) and unzips it after the signature check is completed so we can have a custom ramdisk that allows us to boot CM. It's kinda like a trojan horse but in a good way. Hope this helps : D