My HD2 "Frankenphone" (it's built from no less than 3 other HD2's) has no working hardware keys on the front of the phone. The volume keys, however, do still work. I therefore want to cook a rom based on an existing one that has Volume up/down mapped to HOME/Back.
Furthermore, I was wondering if I could somehow get the MENU button implemented as well. I understand that this is not possible through the SDK, but perhaps it can be done by writing native C code. E.g. a longpress Volume-up could be menu, a long-press Volume-down could be search.
I'm not asking for someone to do this for me, I'd like to do this myself. What I'm looking for are a few quick pointers to how to start this endeavor. I have previous experience cooking custom roms using toolchains under linux, and also experience writing C (non-gui) code under linux. So useful pointers would be :
* Where can I find the key mappings? I suppose this is part of the kernel/user space?
* How would I go about implementing the long-press feature? Or can you hint towards another possible solution that does not involve the front hardware keys (touchscreen snooping for gestures? accellerometer? Any other sensor?)
Take a look here:
http://source.android.com/porting/keymaps_keyboard_input.html
Hope that helps.
One thing I do in most builds is change my call key to a search key.
Hi!
Take a look at the following thread! http://forum.xda-developers.com/showthread.php?t=740629
paalkr said:
Hi!
Take a look at the following thread! http://forum.xda-developers.com/showthread.php?t=740629
Click to expand...
Click to collapse
Awesome, thanks! That worked like a charm. Mounted the system.ext2 loopback, patched the keys, and tadaah, working home + back. That at least makes the phone usable again.
Can anyone recommend a solution to get a working MENU action? It looks like long-press back is handled by apps individually (e.g. in the browser it will show a history), while long-press home displays a task switcher. I could live with long-press back being handled by android itself to implement the menu function.
(edit) looks like this is possible, e.g. here it mentions "including some special features to support the virtual hard keys that are appearing on recent devices such as Droid." Now how did they do that?
Just wondering about the feasibility of (someone with the know-how) creating a background app/service that could monitor and intercept the Nook's Vol+ and Vol- buttons, and if held down for a certain amount of time, perform Menu or Back actions as well.
I would think this possible, based on CM ROMs' ability to skip forwards/backwards from the lockscreen when music is playing, as well as the official XBMC Remote's abililty to change the volume for media playing on an XBMC box without interfering with the volume on the actual Android device.
Under the stock BN ROM I had remapped the Vol buttons, which wasn't a problem since the speaker was barely audible in the first place, but since flashing Dalingrin's OC kernel with the increased volume, I (happily) find the need to be able to change the volume levels easily.
I can't be the only one who's pondered this, but I've read through most of the threads and don't recall seeing this anywhere... If I've missed it, please point me in the right direction.
Thoughts? Takers?
Thanks.
You mean like this easily flashable script in the development forum (page 2).
http://forum.xda-developers.com/showthread.php?t=965023
I am talking an app which would retain volume functionality if the buttons are pressed briefly, as well as implement menu / back functions if held.
Unfortunately it looks like that script you linked to simply remaps the volume keys to menu and back -- without retaining volume functionality:
EpicFail236 said:
[...]
I find that my need for physical menu and back buttons is greater than my need for physical volume buttons.
[...]
This zip is CWM flashable, and simply overwrites the keymap kl files with ones that have the volume buttons remapped.
[...]
Click to expand...
Click to collapse
Not exactly what you want, but a simple solution.
see this, tip #7. Its a simple edit to a text file.
Worked on CM7, heres my edited /system/usr/keylayout/qwerty.kl vol up=menu, down=back
Thanks; unfortunately that is the essentially same as sparhawk's solution, and what I did under the BN ROM.
What I'm looking for is a solution via an application that retains the volume button functionality and augments the buttons with menu/back ability and does not simply remap the volume buttons.
If I had the slightest inkling as to how to do this myself, I would. Unfortunately I've tried and failed (miserably) so far at attempting to learn coding for Android.
I was hoping someone might be familiar with the way CM and XBMC Remote handle these intercepts and be able to adapt code, or create something similar for menu/back functionality.
I get what you are saying, but I don't think it would be possible. Notice how if you hold it down now, it will turn the volume down all the way step by step. When the screen is off, it doesn't do anything. If it was made to be held down to switch function, you would lose the ability to turn down the volume by holding it down. I know what I said is confusing, but just think about it lol. Have you thought about remapping tthe keys totally to menu/back, and then having a sound toggle in the pull down widget for the notification bar? You wouldn't have total control over the levels, but at least its something.
Sent from my ADR6300 using XDA App
Xephik said:
I get what you are saying, but I don't think it would be possible. Notice how if you hold it down now, it will turn the volume down all the way step by step. When the screen is off, it doesn't do anything.
Click to expand...
Click to collapse
I am running CM7 n11 on the nook, and regardless of whether the screen is on or off: if music is playing, when I hit the volume button, the volume level is changed. Not sure what you're referring to.
Xephik said:
If it was made to be held down to switch function, you would lose the ability to turn down the volume by holding it down.
Click to expand...
Click to collapse
I don't necessarily think that's the case.
Example: somehow CM is able to retain volume functionality and add skip next/previous track in music player. When I refer to the ability of CM to skip forward/backwards when music is playing, I am basing this on my experience with CM6.12 on my Droid1.
Xephik said:
Have you thought about remapping tthe keys totally to menu/back, and then having a sound toggle in the pull down widget for the notification bar? You wouldn't have total control over the levels, but at least its something.
Click to expand...
Click to collapse
Yeah, done that and didn't love it. I believe a solution such as I'm suggesting would be much more "integrated," elegant, and convenient.
Basically the app would intercept a volume button press:
- brief press: button release < 300ms, app performs volume function
- long press: button held down or release > 300ms, perform back or menu
Are there any experienced devs who provide some insight?
tj!2k7 said:
Thanks; unfortunately that is the essentially same as sparhawk's solution, and what I did under the BN ROM.
What I'm looking for is a solution via an application that retains the volume button functionality and augments the buttons with menu/back ability and does not simply remap the volume buttons.
If I had the slightest inkling as to how to do this myself, I would. Unfortunately I've tried and failed (miserably) so far at attempting to learn coding for Android.
I was hoping someone might be familiar with the way CM and XBMC Remote handle these intercepts and be able to adapt code, or create something similar for menu/back functionality.
Click to expand...
Click to collapse
I've seen this behavior to control the Android music player. And honesty I don't see why it couldn't be adapted to throw a back or home interrupt. But to implement it is beyond me!
Here is a GitHub repo to handle the Android player on long press up and down but also still handle volume changes on short press.
https://github.com/metalhead8816/android_frameworks_policies_base
And I'm pretty sure the specific commit would be
https://github.com/metalhead8816/an...mmit/7504617a9211a65ce767281c59668e8641b8a14d
Mat Sumpter said:
Here is a GitHub repo to handle the Android player on long press up and down but also still handle volume changes on short press.
https://github.com/metalhead8816/android_frameworks_policies_base
And I'm pretty sure the specific commit would be
https://github.com/metalhead8816/an...mmit/7504617a9211a65ce767281c59668e8641b8a14d
Click to expand...
Click to collapse
We're on a better path now. Thank you for posting concrete evidence of the volume buttons serving two simultaneous functions.
Could that code be used as a base for a standalone background app/service to implement the desired functionality? Better yet if it could be built into a ROM such as CM, but a standalone app would be perfect.
As this is really a question for devs, should I have posted this thread in the dev forum?
This code was put in for eclair so it won't apply cleanly to the Froyo code. But I'm sure a DEV with good Java knowledge could hack this into the current policy framework. From the code this appears pretty integral so I doubt this could be an outside apk that we install. This would likely be an alternate framework we'd need to apply to a ROM much like a style. But again I'm not an Android developer so I don't know for sure.
Button remapper works for the simple remapping, but not for the longpress actions.
I have half a mind to attempt writing a simple service for this
long press menu->vol up in 20% increments
long press back->vol down in 20% increments (may interfere with CM7 long press to kill functionality)
http://android-developers.blogspot.com/2009/12/back-and-other-hard-keys-three-stories.html
http://stackoverflow.com/questions/4983605/send-button-volume-button-action-listeners
http://developer.android.com/reference/android/view/KeyEvent.html
A service sounds (to a non-programmer such as myself) like it would be less involved than framework modifications, and portable across ROM updates.
And personally, I don't mind "losing" long-press-kill functionality as I never use it anyway... I'd love to see some progress along these lines... go for it. =)
If you decide to attempt create a service for this, could you be make the long/short actions customizable?
i.e. :
Short press Vol+: Volume up / Long-press Vol+: Menu
Short press Vol-: Volume down / Long-press Vol-: Back
vs.
Short press Vol+: Menu / Long-press Vol+: Volume up
Short press Vol-: Back / Long-press Vol-: Volume down
In most applications, Menu and Back are usable via the status bar; since that functionality would be redundant, it would be nice to retain quick access to volume for short presses. For instances where Menu and Back are not usable in full-screen applications, long-pressing the buttons to perform menu and back actions doesn't seem like much of an issue.
Actually, if the Menu and Back were long-press actions, couldn't you implement functionality to kill the current app if Back was held for a specific amount of time?
Just thought I'd bump this back to the top... any devs out there who might want to take a crack at something like this?
Until we get Honeycomb AOSP this "hack" would be perfect!
I'm on the lookout too. I'd much rather have my vol up and down keys then have them as back and home. Unfortunately I lack the skills to code it so far!
My prayers, answered. Thanks mad-murdock.
http://forum.xda-developers.com/showthread.php?t=1002000&page=23
I love everything about my X2...except for the physical buttons. How hard do you guys think it would be to replace them with captive touch buttons? Would it be as simple as finding some buttons, connecting the wires and making them fit or would software be involved? Any feedback would be appreciated.
TransX2 said:
I love everything about my X2...except for the physical buttons. How hard do you guys think it would be to replace them with captive touch buttons? Would it be as simple as finding some buttons, connecting the wires and making them fit or would software be involved? Any feedback would be appreciated.
Click to expand...
Click to collapse
I had the same question regarding this. My reason being the buttons are too loud at night. All you hear is "clickity click click click". I was looking to see if the Honeycomb style onscreen buttons were available to install (they have them in Cyanogenmod on tablets running Gingerbread). Didn't find them.
BUT I did find a program called "Soft Keys" in the market. It's free and has on screen buttons that can be hidden or shown with a little floating movable button. You can do everything with it without using the hard keys. I strongly suggest it, and it will probably prolong the life of the hard keys.
Make sure to set it to not autohide after clicking on the buttons (it defaults to hide when pressing home).
the amount of physical modding needed would make this entirely too much work. re-wiring, taking a capacitive button section from another phone, etc, maybe even software stuff, that much i don't know.
you're better off finding a way to quiet the buttons
one of the best features of this phone is the fact that it still has some real buttons. itd be nice if it had a d-pad or trackball too just so one could not have to always use the touchscreen to interact with it
ralphwiggum1 said:
I had the same question regarding this. My reason being the buttons are too loud at night. All you hear is "clickity click click click". I was looking to see if the Honeycomb style onscreen buttons were available to install (they have them in Cyanogenmod on tablets running Gingerbread). Didn't find them.
BUT I did find a program called "Soft Keys" in the market. It's free and has on screen buttons that can be hidden or shown with a little floating movable button. You can do everything with it without using the hard keys. I strongly suggest it, and it will probably prolong the life of the hard keys.
Make sure to set it to not autohide after clicking on the buttons (it defaults to hide when pressing home).
Click to expand...
Click to collapse
Try button savior. I like it much more than soft keys.
Is there any way to make the overflow menu button show up in applications that support it?
The best I've found is a method called hasPermanentMenuKey() which I think I could force to "return false;". Problem? I don't know where to dive in to the android.view library.
It shows on my Nexus 7, Galaxy Nexus, and even HTC One X - but not on my SGS3. I assume because the system detects it has a hardware menu key.
Is there a way to trick/tell/force the showing of the overflow menu button in supported applications?
I don't have a SGS3, but from what I've seen from pics on the interwebs, didn't the SGS3 have a capacitative menu button? AFAIK menu button always triggers overflow menu, or does it?
(sorry for off-topic)
Sony Xperia Play - Tapatalk 2
DanielEGVi said:
I don't have a SGS3, but from what I've seen from pics on the interwebs, didn't the SGS3 have a capacitative menu button? AFAIK menu button always triggers overflow menu, or does it?
Click to expand...
Click to collapse
Yeah, it does, I should probably explain my use case...
Half of the reason is because I want some UI consistency between all my devices, my SGS3 is the only one where almost all apps I use on a regular basis behave differently (and sometimes even look differently) because of this lack of overflow menu button.
The other half is because I hate physical buttons and I remapped my sometimes-less-used Menu key to the physical button on the SGS3, and would like it if I could avoid the physical button *most* of the time by just using in-app menu buttons (if I ever figure out how to force them on).
If someone can figure this out and/or help me figure it out I will gladly donate to them. I want this feature badly.
burningembers said:
Yeah, it does, I should probably explain my use case...
Half of the reason is because I want some UI consistency between all my devices, my SGS3 is the only one where almost all apps I use on a regular basis behave differently (and sometimes even look differently) because of this lack of overflow menu button.
The other half is because I hate physical buttons and I remapped my sometimes-less-used Menu key to the physical button on the SGS3, and would like it if I could avoid the physical button *most* of the time by just using in-app menu buttons (if I ever figure out how to force them on).
If someone can figure this out and/or help me figure it out I will gladly donate to them. I want this feature badly.
Click to expand...
Click to collapse
Oh now I get it, I guess I would also do the same in my apps for the sake of consistency. I don't know much about it, so I can't help much
Anyway, good luck on finding an answer
Sony Xperia Play - Tapatalk 2
*bump*
Donating money to someone who can give me a solid lead on how to accomplish this, bigger donation for getting it done.
So I've done a search on Google and Xda about this topic and so far there doesn't seem to be much information on this except to find a thread about the inability of the android system in remapping of keys (or maybe the thread just went out of topic)
Thread; http://forum.xda-developers.com/showthread.php?t=1244702
So I'm wondering whether the remapping of the right click button to give a command 'Open Context Menu' is possible to immitate the function of a real computer (All these taking into consideration that it is also possible to remap buttons of the dock)
If you were to have it mimic the behavior of a real computer it wouldn't work. Android uses a right mouse button as if you were touching and holding on an object.
The only thing i would be interested in is remapping the second button the same as the primary button. Effectively having left click and left click.
Now it shouldn't be *that* hard to make a simple program to accomplish this, simply an extension to remap the buttons to whatever android specific task you want, this is already semi possible with the remapping of soft keys in CM 10.1/AOKP builds, so something like that should be possible.
Unfortunately i have no coding experience. I would love to see this done though
Nexus 4. Paranoid edition.
No, today I search & found a solution - http://forum.xda-developers.com/showpost.php?p=55848773&postcount=7