[MOD] [JB4.1+][AOSP+OTA] Super PowerMenu | Reboot & Recovery | DIY Instructions Avail

[Anthrax]

Yeap brov... wasnt easy though!!!

thanks, will keep tryning & check for another tutorial.

hey you got boot loop when i tried i didn't get any boot loop but the problem was whenever i pressed the power button for long to get the menu it would directly restart.... without any options.....

 

[whalesplaho]

hey you got boot loop when i tried i didn't get any boot loop but the problem was whenever i pressed the power button for long to get the menu it would directly restart.... without any options.....

i experience dat too but dnt know what causes dat..... instead of Power option, it soft reboot!!!

hope will work dis out soon.

 

[Anthrax]

if you get any work around just let me know....

@OP:

if you can help us it will be great....
here's a log cat attached......

 

[bluenile]

@djmcnz any idea how we can switch to this "Power Menu" instead of the Shutdown Confirmation Alert dialog box that we get on some tablets like PiPo M9? Thanks for your time.

 

[Anthrax]

@djmcnz any idea how we can switch to this "Power Menu" instead of the Shutdown Confirmation Alert dialog box that we get on some tablets like PiPo M9? Thanks for your time.

That's what this tut is about.... Follow the tutorial to get the power menu....

Sent from my MT27i using xda app-developers app

 

[bluenile]

That's what this tut is about.... Follow the tutorial to get the power menu....

Sent from my MT27i using xda app-developers app

Thanks for your reply. I compiled the framework-res.apk and android.policy.jar as per the instructions in the tut, still get the old shutdown confirmation box. I will try again. May be I'm missing something?

 

[Anthrax]

Thanks for your reply. I compiled the framework-res.apk and android.policy.jar as per the instructions in the tut, still get the old shutdown confirmation box. I will try again. May be I'm missing something?

provide a logcat.... and also as said by OP this method works confirm on Nexus only....

 

[bluenile]

provide a logcat.... and also as said by OP this method works confirm on Nexus only....

Logcat attached. Thanks for your time.

** Also attached the screenshot of the Shutdown Confirmation Alert dialog box I still get.

 

[djmcnz]

Yes, the problem will be that the OEM who made your device didn't use the standard Google/Android methods for shutdown/reboot. This is quite common and it's not "bad" at all, just different.

The principles in this guide will still apply but the various methods used and messages displayed are probably named differently and, more problematically, located in different places in the smali code. It would be impractical I think for anyone to try and work through that process without the specific device in hand.

Removing the confirmation should be easy, you just need to find that message, skip it and provide a "yes" message to the system automatically. If you can do some basic smali navigation then tracing this is probably quite easy.

Adding in functions (reboot/recovery etc) will require you a) finding the correct location and b) finding suitable code to insert. There may already be useful code in there you can "copy and paste" and change a few values (my guide has an example of this applicable to the Nexus).

Adding long-press will be a pain if it's not already there somewhere by default. If it is then again, it's copy and paste making sure you change some values.

All said and done though, if you can't "read" smali (or convert it to java and read that) then it will be a cumbersome process of trial and error I'm afraid.

Note: a custom rom dev that's building from source could add these features in a matter of minutes, if you have access to a custom rom for your device it may pay to ask the dev if they can add it in.

 

[bluenile]

Yes, the problem will be that the OEM who made your device didn't use the standard Google/Android methods for shutdown/reboot. This is quite common and it's not "bad" at all, just different.

The principles in this guide will still apply but the various methods used and messages displayed are probably named differently and, more problematically, located in different places in the smali code. It would be impractical I think for anyone to try and work through that process without the specific device in hand.

Removing the confirmation should be easy, you just need to find that message, skip it and provide a "yes" message to the system automatically. If you can do some basic smali navigation then tracing this is probably quite easy.

Adding in functions (reboot/recovery etc) will require you a) finding the correct location and b) finding suitable code to insert. There may already be useful code in there you can "copy and paste" and change a few values (my guide has an example of this applicable to the Nexus).

Adding long-press will be a pain if it's not already there somewhere by default. If it is then again, it's copy and paste making sure you change some values.

All said and done though, if you can't "read" smali (or convert it to java and read that) then it will be a cumbersome process of trial and error I'm afraid.

Note: a custom rom dev that's building from source could add these features in a matter of minutes, if you have access to a custom rom for your device it may pay to ask the dev if they can add it in.

Thanks for your reply. I'm totally a n00b here.

But you are correct, upon long pressing the power/lock button the tablet calls the shutdown procedure in services.jar (ShutdownThread.smali). Is there any way I can call the createdialog function in android.policy.jar from within the shutdown function already invoked?

 

[djmcnz]

Thanks for your reply. I'm totally a n00b here.

But you are correct, upon long pressing the power/lock button the tablet calls the shutdown procedure in services.jar (ShutdownThread.smali). Is there any way I can call the createdialog function in android.policy.jar from within the shutdown function already invoked?

In theory yes, in practice it would be difficult unless you had some sample code.

Thinking about it more, if it's anything like my tablet (ASUS) then you may find the stock shutdown code all still in there. You could get lucky with this and if so some small changes would probably allow it to be invoked. Look for the existence of the files and strings in my guide, they'll be a good indicator.

Sorry for the tardy replies...

 

[bluenile]

In theory yes, in practice it would be difficult unless you had some sample code.

Thinking about it more, if it's anything like my tablet (ASUS) then you may find the stock shutdown code all still in there. You could get lucky with this and if so some small changes would probably allow it to be invoked. Look for the existence of the files and strings in my guide, they'll be a good indicator.

Sorry for the tardy replies...

Hi - Thanks for your reply, I appreciate your help. I was able to solve the issue by changing the order of menus invoked in phonewindowmanager2.smali. (credit: kahvitahra for the tip)

 

[Zombeezy]

Nexus 5

Loved your Super PowerMenu that was an integral part of the 4.2.1 MiNCO v6 (Minooch + Franco) Toro ROM for the Galaxy Nexus. I now have a Nexus 5 and am missing your power menu functionality to reboot to recovery, etc.

Since I am using ART instead of Dalvik, is there any chance you might do a Super PowerMenu for Nexus 5 Kit Kat that is not part of Xposed Framework using Dalvik?

Thank you!

 

[LiquidXed]

Maybe look into the xposed module, it has the reboot menu for the GNex

Sent from my Galaxy Nexus using Tapatalk

 

[djmcnz]

Maybe look into the xposed module, it has the reboot menu for the GNex

Z' wants to use the ART compiler so no Xposed...

Loved your Super PowerMenu that was an integral part of the 4.2.1 MiNCO v6 (Minooch + Franco) Toro ROM for the Galaxy Nexus. I now have a Nexus 5 and am missing your power menu functionality to reboot to recovery, etc.

Since I am using ART instead of Dalvik, is there any chance you might do a Super PowerMenu for Nexus 5 Kit Kat that is not part of Xposed Framework using Dalvik?

Thank you!

Sorry for the delay, we had a holiday weekend here and I've been working on my car.

To be honest, since I didn't notice a difference between ART and Dalvik on my N5 I'm using Xposed and GravityBox which is just awesome. I probably won't be making changes to the stock KK ROM this time around but if somebody wants to decompile the code and do the testing I'm happy to assist with any changes... our you could set yourself a challenge and follow the DIY - I'm almost sure the power menu code won't have changed much.

 

[Zombeezy]

Z' wants to use the ART compiler so no Xposed...



Sorry for the delay, we had a holiday weekend here and I've been working on my car.

To be honest, since I didn't notice a difference between ART and Dalvik on my N5 I'm using Xposed and GravityBox which is just awesome. I probably won't be making changes to the stock KK ROM this time around but if somebody wants to decompile the code and do the testing I'm happy to assist with any changes... our you could set yourself a challenge and follow the DIY - I'm almost sure the power menu code won't have changed much.

No problem, appreciate you getting back to me on this.

Not adventurous or smart enough enough to tackle it as a DIY, lol, but you bring up a good point - notable performance difference so far between ART and Dalvik to me also was minimal, mostly while doing scrolling long web pages, it seemed to do it more smoothly.

Good suggestion - I'll head back to Dalvik, Xposed and GravityBox. Definitely awesome, you're right. Thank you!