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.
Related
I'm a junior software developer and I need to develop an app for wear OS with the following key feature; to detect a long press of physical button on a smartwatch while the app is running in background. Is this even possible? If yes, I would truly appreciate for any links to samples and documentation.
thank you
As far as I know this is not possible. The multifunctional buttons can be mapped to custom actions, but only when an application is running in the foreground. Otherwise they are controlled by the system (to e.g. act as a shortcut to Google Pay).
Even if it was possible, your app would only work on some devices since not all models have a multifunctional button. The only button that is guaranteed to exist on all devices is the power button, and this one you can definitely not get any events from in your app.
You've probably seen this already but I'm attaching it in case it's helpful to someone:
Design guidelines plus recommended use cases and behavior can be found here
Implementation reference for the multifunctional buttons is here
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm looking for a reliable way to let the Android user show a web site on the lock screen.
This could be done in principle in 3 ways:
Showing it on the native Android lock screen, but then they should be able to remove the native clock because my site is a world clock (you can see it at intelnav.50webs.com/world_time.html if you're interested). For all I know this can't be done.
Using a 3rd party custom lock screen that allows this. Unfortunately I couldn't find a good one, and I did some searching.
Writing a custom lock screen myself.
There are some suggestions and even sample projects for doing this, even some questions here on StackOverflow. But I'm not sure how reliable they are. There is no standard way of doing it, from what I found, since lock screen widgets were removed. But the proposed ways of building custom lock screens don't seem very reliable to me, from what I could judge from the comments I could find. So, one of my questions (sorry but the problem is somewhat complex), does anybody know of a sample project for a custom lock screen that actually has an app built by it and offered on Google Play and which actually works well on a wide range of devices ?
Could anybody help me with a suggestion for a reliable way to do what I want? Along the lines above?
Looks like I'm going to answer my own question. I'm not sure how many will be interested but you can never know.
Update sep 18: Now there is a short answer that wasn't available a year ago when I first answered it. Namely, my own WebLock app:
https://play.google.com/store/apps/details?id=com.simionescu.vlad.weblock
Below is my original answer that gives a general idea of how this can be done programmatically.
So I went into digging and looks like it can be done. It wasn't even as difficult as I feared it would be, though I wouldn't say it was very easy either.
The main points are as follows:
I wrote an app that basically puts the site on the native Android lock screen. (Actually, I already had an app and I added this functionality to it, but that's less important. The main thing is that my method requires writing an app.)
So I guess this falls somewhere between the cases 1 and 3 above. I do need an app, but it's not a full-fledged custom lock screen, as detailed below.
This of course means that the method is more general, it works with any app, not just for displaying a site.
Set FLAG_SHOW_WHEN_LOCKED for the Activity window, as shown for instance here:
How to make our own lock screen in android instead of default lock screen
But I only used this flag, the other 3 mentioned in the link I didn't need.
Launch the Activity (if it's not running already) and set it on top before the device screen goes off, that is on receipt of the ACTION_SCREEN_OFF event. This way, the app is always visible when the screen goes off so next time it starts, Android will put it in front of the lock screen. (At least if it's the standard one; from the documentation it looks like it should be working with a custom lock screen too but I didn't test it. I guess it depends on how that custom lock screen is written. Anyway, I don't necessarily want my site on a custom lock screen, if the user has one he probably won't want to see my site in front of it).
This also means that the site will appear in front if the device is switched off then on, even if it's not locked. Which is what I intended.
Automatically start the app at startup via the BOOT_COMPLETED event
Capture the standard back key (which is allowed, unlike for the home key) and make it act like the home key when it would otherwise terminate the app.
I intentionally let the home key act normally. This of course means that after pressing it (which is the way the user exits the app and enters the device) the lock screen underneath is shown. Otherwise I would have had to deal myself with password-protecting the device, which is in no way something I want to do. There are a few drawbacks with this approach but IMO they're small. For simplicity's sake I chose to do it like this.
Besides, this way my app remains reliable, which it wouldn't have if I had hijacked the home key, no matter which way.
As said, this means that this is no full-fledged custom lock screen, just a way of putting the site over the default lock screen.
(update nov. 18) There's one more important point. As described so far, such an app could have a security issue. I'm not an expert so I'm not sure if it really does, and if so how important it is, but you can never be too safe. If the user can go unchecked to any site, when on the lock screen, it means that if the phone is lost and a bad guy finds it, he could go to a site that has dangerous code that could unlock the device. I'm not sure if it really could be done but I wouldn't be surprised. So, one good advice for anybody who writes such an app would be to severely (but reasonably) restrict Web navigation while on the lock screen.
These are the main points, there are a few other implementation details but I'll leave them out for the moment.
All this looks pretty standard and reliable to me, given that it's all in the official Android documentation.
I tested it on my KitKat device, plus on 2 emulators, one also with KitKat on it, the other one with the latest and greatest. Everything seems to work fine. Including the case when the device / emulator is password protected.
So I just wrote the app and published it on Google play. It's here:
https://play.google.com/store/apps/details?id=com.a50webs.intelnav.worldtime
Which means that now there is at least an app on Google Play which has this feature. It remains to be seen how well it will behave. I'll probably have to make minor corrections in the coming weeks, but other than that it should be fine.
Also in the coming weeks, maybe a month or so, I plan to put another app that will do this generally with any site, at the user's request.
(update nov. 18) I finally wrote the app and put it on Google play. It took a little longer than planned but it's ready. It's here:
https://play.google.com/store/apps/details?id=com.simionescu.vlad.weblock&hl=en
As noted above, when on the lock screen, navigation is restricted to the same domain, so that if a bad guy finds the phone he cannot go to some malware site and unlock it.
My android watch has a single hardware (physical) button on the side. Is it possible to program a listener for this button, so that it can be used as an additional control in my program?
I don't believe this is possible. The usual way to detect a standard button press (like Back) in Android is with an onKeyDown listener, and this doesn't fire in an Activity on Wear when the stem button is pressed (tested on both Wear 1.5 and the 2.0 dev preview).
It's always iffy to assert something is categorically not possible, because there's always the chance that someone will find a clever hack to make it happen. And I wouldn't mind being proved wrong. But until such a hack comes along, I'm going to say no, it's not.
This question already has answers here:
Are the 4 Android buttons standard? Ex. back button, menu button
(4 answers)
Closed 5 years ago.
Do all Android devices have "option" and "back" buttons? Or should my design have "back" and "option" buttons for making it more versatile?
The Android 4.1 CDD section 7.2.3 contains information on this:
The Home, Menu and Back functions are essential to the Android
navigation paradigm. Device implementations MUST make these functions
available to the user at all times when running applications. These
functions MAY be implemented via dedicated physical buttons (such as
mechanical or capacitive touch buttons), or MAY be implemented using
dedicated software keys, gestures, touch panel, etc. Android 4.1
supports both implementations.
The back button is going to bring back the previous screen on the stack regardless, much like the home button will pretty much always take you to the home screen. As for the option button, it's generally good practice to implement something for it if there are some settings to be changed or something like that, but that really depends on your application. Many apps don't utilize it and do just fine.
No, not every device comes with a back button. Amazon Fire phone do not have a back key.
On Android platform it is always better to be cautious as device manufacturer always do customization.
I have two buttons that both have onTouchListeners and perform an action when pressed down. Why do they not work if you try to click both at the same time? I'm building for Android 1.6. I don't have a real device to test on, and you can't test clicking two things at the same time in the emulator. Thanks for any help.
I'm no expert, but my guess would be the following,
All gui-interaction is done through the UI-thread. Unless you do some special treatment of the buttons, you'll end up processing "click 1" with the UI-thread, while the user does "click 2" (at a time when the UI-thread is busy somewhere else). That is, the UI will not be responsive during the second click.
Multitouch was only introduced in Android 2.x, so on 1.6 you're out of luck - not possible. Even with 2.x the default UI behavior is to be singletouch only for such events (ie button press).
I suppose it is possible to somehow extend the container view of those buttons to become multitouch friendly and actually pass the correct events to the buttons, but that would be quite hackish.
You can read more about multitouch here. And on page 3 you can see why the multitouch fails on the GUI: first touch event is ACTION_DOWN which is handled like it should be, and the second one is ACTION_POINTER_DOWN which the UI doesn't know how to handle.
As Roosma already mention, multitouch is available from 2.x version.
According downloading statistics from my app published at android market (already downloaded more then 16k persons) it looks like there are only a few dozens people that using Android 1.6 on their devices. So i think you should mouve to version 2.1 at least.
I hope it helps :)