I'm looking for a way to grab trackball events while the screen is off, preferrably on a N1. I'm building my own music player and would love to add the feature to skip songs by trackball press, without having to unlock my device everytime.
I've found TrackBallSkip, however the source code has been taken down and integrated into CyanogenMod. I fear that I may need to do something exotic to my phone (root it, mod it, whatever). While this isn't a problem, I would be happier if I could freely share my Music player.
Can anyone confirm that I'll need to mod the home to get access to this functionality? Or can I just straight code it (if so, any pointers in the right direction would be amazing).
Thanks!
I found where Cyanogen put TrackBallSkip into their source base (this commit). It appears to reside in phone/com/android/internal/policy/impl/PhoneWindowManager.java which means it can't be implemented without modding the firmware (since the related package resides in /system).
Related
I do have a problem and have very little to go on. I'm about to release an App (created with Air for Android As3) on the Samsung App Store and just got a list of issues that have to be resolved after the app has been tested by samsung staff before the app could be released.
I did manage to solve almost all of the issues, but 1 very important one is beyond me. They say the screen turns/stays black, when returning after the device alarm interrupted the app. This issue practivally happend on all their devices, including a group including the phones I own (e.g. Galaxy S3).
I do have "OnDeActivate" and "OnActivate" listeners in place that are there to pause the app, disable sound etc. if it loses focus, gets minimized etc., yet I checked on my devices and I can't reproduce this error. Meaning if the app gets interrupted on my device by the alarm, I can resume it without any problems. no black screens.
So the question is: Is there any way for me to fix that at all? I do have to work within AirForAndroid AS3 so I guess possibilities are limited. Any clues where I can look? Any listeners to set, or is there a way to maybe "force" the app to reinitialize or refresh the display? Or to listen for the system alarm? Help would be much appreciated. Thanks in advance!
I am trying to overcome the same issue, I read somewhere that setting the stage quality to something else on both the activate and deactivate events might solve the issue.
So just set your stage quality to medium or whatever different in the deactivate and set it back to what it needs to be in the activate.
This should make AIR snap out of that black screen for the alarm (I hope)
An app of mine is with this fix is currently undergoing testing on the Samsung App Store.
I hope it fixes it.
Good news, the dirty fix of toggling the stage quality seems to have worked for Samsung, it has not shown up in their latest certification report of my app.
by the way, this is not for a stage3D app, that's different
It's for a GPU app
When the app loses focus on Android (goes into background) it will lose the context, which among other things mean that you lose all the created graphics, cached objects and like.
You didn't specify what kind of app it is. If you're using Stage3D, that means you'll have to recreate all your textures, and if you're on plain old displaylist, you'll have to recreate any bitmaps that were created at runtime, and redraw your screen at least once (so the vector graphics get redrawn too).
Now, if you're using Starling, for example, it can take care of recreating context for you (there's a flag for enabling that), although you'll still have to recreate dynamically created bitmaps.
We’re porting to Android some interactive iOS apps used to teach young children with learning disabilities. We have hit a major usability issue, because we can't figure out how to disable physical or on-screen navigation buttons (Home and Recent Apps).
Before anyone says “you don’t want to do that”, we fully understand why you would always want these buttons enabled for an able-bodied adult, but these children pose a unique set of accessibility issues. Specifically:
Their fine motor control may be poor - they may inadvertently touch a different area of the screen to the area they intend, or accidentally use more than one finger at once.
They may have weak muscle tone and poor physical strength – so e.g. the bottom of the palm of their hand may drop and touch the screen while trying to just use a finger.
They struggle to achieve and easily become disheartened or disruptive if they fail.
For instance, a typical 5 year old child with Down syndrome will accidentally drop out of the app they are using as a result of inadvertently touching the Home button: when this happens repeatedly, and the adult teacher or parent has to go back into the app for them repeatedly, the child loses interest and focus. Another typical scenario is a young child with Autism, who may freak out completely and need physically restraining if this happens while using their favourite app. Also, many disabled children will try to poke any other button they can find, in search of a response. In any of these situations, a potentially valuable educational session may have to be completely abandoned.
We're aware of SYSTEM_UI_FLAG_HIDE_NAVIGATION and SYSTEM_UI_FLAG_LOW_PROFILE, but these only reduce the visibility of the on-screen buttons until the child touches some other part of the screen, and then they re-appear in a way that’s more distracting than if they were visible all the time.
On iOS there is the “Guided Access” feature that solves this problem trivially. Can we emulate anything similar on Android?
On iOS there is the “Guided Access” feature that solves this problem trivially.
Guided access appears to be a device setting, not something that developers enable unilaterally themselves, thank heavens.
Can we emulate anything similar on Android?
There is no similar device setting in stock Android.
You can download the Android source code, modify it as you see fit, build the results into a ROM mod, and install that ROM mod on devices as you see fit.
Or, you can perhaps work with a device manufacturer creating tablets aimed at children to see if either they have already added this capability to their devices, or would be willing to work with you to add such a capability in a future iteration of their devices.
I want to write an app that needs accelerometer data while the user has the device in his pocket. However, at least on my phone (Motorola Defy with a nightly CM9 build), a dim-wakelock is needed because the accelerometer somehow turns off together with the screen. But if the screen stays turned on, the user might trigger random touch actions with his body movements. I could just display a black area, but that won't protect the menu keys. So, what should I do to protect the device from accidential user interaction? Things that come to my mind:
use root access to somehow hook deep into the system and require an unlock pattern or so - but I as a user would hesitate to give an app root just because it wants to block my input, and if I as coder make a mistake, I might lock out users -> might work, but probably the worst possible solution
somehow use the lock screen for this - but I don't know how I can safely, whatever the settings on the device may be, activate that lock screen without needing root
Gah, this all just looks bad to me. Is there any way to solve this that doesn't suck?
I am driving some experiments with a pair of a-JAYS Four headphones (having 3 buttons on its wired remote/mic) plugged onto a Galaxy Nexus (ICS 4.0.2).
My issue is that only the middle button is 'recognised' by a test app I have written, i.e. triggering both Intent.ACTION_MEDIA_BUTTON and/or Activity.onKeyDown callback with KeyCode 79 when it is pressed.
Pressing the two other buttons don't trigger any of the previous methods. For info, those headphones and its 3 buttons work on Apple iPhones and Apple computers (at least a MacBookPro 2011), as advertised on the box...
Firstly I thought Android or my device could simply not handle more than one button on a wired jack remote (even if that sounds weird...) but then I had a try with a pair of headphones from HTC (the ones coming with one of their Desire device) having 3 buttons. Middle button would react the same way as my a-JAYS, but the two other buttons are also recognised with KeyCodes 87 and 88, respectively Play Previous and Play Next media keys.
So it seems that either the device or the low levels layers of Android are simply not able to catch certain headphones buttons signals :/ (at least those which are not 87 and 88)
Any idea anyone about how to make Android able to recognise other buttons/signals from such headphones as Apple compatible ones? Would it imply low levels drivers writing for ICS or am I missing something really obvious?
Any help would be much appreciated. Can post my test-app code if needed.
Cheers
The signals/ resistance from the volume control buttons (1.525-1.495 V for volume down, and 1.619-1.587 V for volume up) are currently unable to be recognized through the android framework's software. I believe this has to do with Apple having a patent on the designated volume controls and so Google won't release to developers how the framework recognizes particular signals through the fourth connector on the headphone jack. The center/mic/action buttons on headsets generally work, it shorts the path from ~2V to ~0V and Apple does not own the patent for that. If someone could figure out how to interact with the inputs on their own that would be huge. I am tempted to learn app development and find a workaround.
The problem is more complicated that it seems: http://david.carne.ca/shuffle_hax/shuffle_remote.html .
I have to emphasize that I am no expert on this topic, but from what I have read and tried so far I conclude that it is not impossible to have an Android phone respond to an iPhone headphone's volume buttons, but for some reason the performance is poor/lagging.
There are some apps trying to do the magic, but they are too unreliable for everyday use. I suppose the problem is that triggering the signal may have to be implemented at a lower OS level than most regular apps have access too.
The solution could probably be some kind of a ROM mod...
If you can implement this, I am sure it would be a big deal for the Android community, and maybe a good biz for you.
Kind Regards, your fellow Hungarian
Gergő
You have to press and hold the middle button while plugging the headphones to the jack. That will make the microphone work on an Android. It works on my HTC Thunderbolt.
I believe it's a hardware issue (at least in regards to Apple headphones). If you look at the plug on those they have four contacts instead of the normal three. I'm willing to bet they run their button signals through that extra contact. AFAIK, there is no Android equipment wth jacks to match that.
So, ultimately I don't believe you can make apple earphones with buttons work for android (as far as button functions go).
You have to hold the middle the whole time for it to work. If you let go and not playin music it says accsessary not supported but if u play music and let go it simply stops the music until you hold it again. Maybe tape the middle button shut really tight?
If you look at the four contacts, tip-ring-ring-sleeve (TRRS), and know that MOST headphone sets are:
tip: left
ring 1: right
ring 2: ground
sleeve: mic
(1/4 inch pro audio stereo plugs are known as TRS - tip-ring-sleeve)
although some reverse the ground and mic contacts, what you need to know as far as how the device recognizes the different buttons you have, is that those buttons are making a short between the ground and mic contacts.
(before IR, old school WIRED remotes for VCRs used resistance for different functions)
Now your homework to find out what is going on is:
measure the resistance between ring 2 and the sleeve for each one of your buttons
find out if it is a momentary short, or constant
if you have some other headphone/mic device that works correctly, measure those impedance (resistance) too
I don't know how into this you want to get, but you can buy resistors with the correct impedance to get the functions you want out of the Android device, the question is, do you know what functions the device is capable of, and what those impedances are that trigger that function.
daniel#destinypatrolsoftware.com
I looked around and although there are many related questions I didn't see one that answers my exact question:
I would like to create an app that runs in the background that provides the exact same functionality as the hard coded 'Back' button in all cases.
The reason? I (for example) have a Droid X, and it is BIG. it makes it extremely hard to use one-handed and having a swipe gesture function as a back button (like in Palm Pre for example) would greatly increase the ease of use.
as far as I'm concerned the app could just be one simple class that contains:
1) a listener for the 'back' swipe
2) a call to the physical hard button itself
Is this possible? are there built in APIs for the hard coded buttons that would allow me to call them without actually pressing them?
Again - I'm not interested in overriding the button, I'm interested in making a software call to it - or failing that, in emulating it's behavior in any and all states and other apps!
Please forgive the naivete of this post. I am a very novice programmer and really I just want to know whether this is possible before I start to devote myself to trying to build it.
Thank you,
b
Is this possible?
By writing your own firmware, yes. Via an Android SDK application, no.