I want to know if there's some way to maintain an Android activity always on top regardless of any other apps present in the phone device that might put on top on it, except for home screen via home button, which cannot be helped.
I've checked that if a whatsapp popup displays over my activity, that activity starts showing a strange behavior.
Maybe this can be controlled by some events, but I think it's much easier to avoid anything that might put on top of app, so no strange behavior appears.
Is there any way to do that?
It depends on the level of control that you have over the device. If your app is going to be publicly available you cannot (and should not) do much to prevent other components from coming on top of the stack.
Apart from that, one thing you can do is check for UI changes through this: https://developer.android.com/reference/android/view/View.OnSystemUiVisibilityChangeListener or/and activity lifecycle events (like onPause) and prevent whatever this "strange behaviour" is.
The inverse way to deal with this is to prevent any app from having the "Draw Over Other Apps" permission, but as I said it depends on the environment of your deployment.
Related
There are plenty of answers explaining how to close Android's soft keyboard (such as this one), but they all assume that the keyboard was opened from within your own app, or that you already have views which can obtain focus, thereby trumping the needs of the previous app. Within Android's InputMethodManager class, requests to close a keyboard opened by another app are rejected, and the call to hideSoftInputFromWindow() returns false.
A developer on my team created an extension method on Activity that calls a block of code whenever keyboard state changes. Because Android doesn't fire keyboard show/hide events on its own (which is ridiculous), it's common practice to detect a reduction in the height of the Activity root layout, and assume this means the keyboard was opened. (Note: this only works with windowSoftInputMode="adjustResize".) This extension method, which is meant to be called in onCreate(), notes the height of the root layout at the time it's called, and watches for subsequent changes in height. If the height of the layout has become smaller, it's assumed that the keyboard has been shown. If it then gets bigger, it's assumed the keyboard was hidden. While this sort of non-deterministic hack is unfortunate, it can be useful, as long as you aren't depending on 100% accuracy.
Unfortunately, it doesn't work in this scenario:
User start in another app, with the keyboard open
User taps a notification from my app
My app opens (cold start), with the keyboard still open from the other app
When the extension method is called from onCreate(), the height of my Activity's root layout already reflects the fact that the keyboard is open, which breaks the concept of watching for it to get shorter when the keyboard is open
While there are potentially some ways to refine the logic to make it more robust, what I really want to do is reliably close the "foreign" keyboard that's throwing off my baseline measurement of the app's height. But I've tried setting windowSoftInputMode="stateHidden" in my AndroidManifest.xml file for the Activity in question, and I've tried calling InputMethodManager.hideSoftInputFromWindow(view.getWindowToken(), 0). Neither approach works; if the keyboard was opened by another app, and I don't yet have a view that has focus, InputMethodManager rejects my attempts to close the keyboard, presumably as a way to prevent my gaining control over the visibility of a keyboard owned by another app.
Is there a way to immediately close a lingering keyboard from another app when starting your own Activity, such that the keyboard is gone by the time your first layout occurs? In my opinion, the fact that stateHidden doesn't do this for you is a bug.
The fact that the keyboard is still up is a bug. But there's no way to fix this programatically that I know of. The problem is that the keyboard works on a connection basis, and the connection is with the previous app. So there's no way to talk to it until you have a connection.
The size hack you mentioned is really something that should be avoided because its nowhere near 100%. There's other things that break it such as split screen, picture in picture modes, and most likely the new foldable phones. Also connecting it to any monitor. It's "common" practice only by people who don't know better and don't test their code. Basically one of those broken pieces of code that floats around because it kind of works and people don't look deeper.
You can forcably set focus to a view in your window that accepts text input. That would force a connection. But then in closing it you'd have jank, and it would occur in cases where this isn't a problem.
In the end, the solution is to write your app such that it doesn't care about keyboard state and not attempt to change behavior or look of your app when the keyboard opens/closes, the OS isn't meant for it.
Totally agree with you that this should be supported by the OS. But I've been saying that since 2010 when I wrote keyboards. It hasn't changed yet, I wouldn't expect it... really ever. Google has never shown much interest in improving the keyboard API, even when I worked at the biggest 3rd party keyboard app in the world they didn't want feedback or put resources into it.
I want to move from current page to login page in my app when clicking the Home Button (not recent button).
It is controlled by the option in iOS (application does not run in background to 'YES').
I don't know how to control it in Android.
I try this:
onDownKey (not working when clicking Home & Recent, but back button works well.)
onPause or onUserLeaveHint (I already controlled others in these methods, so I can't use it)
dispatchKeyEvent (also not working)
No, there is no direct equivalent functionality. ANd you can't detect the home and recents button, the system handles them directly without ever passing them to your app. Tell us why you want this behavior, and we may be able to help you. But this would be extremely unusual behavior for Android. In fact the exact opposite is what's usually the problem- making sure you relaunch correctly if you're killed and relaunched via recents.
I'm working on an existing Android application for medical purposes.
The back button and home button should be disabled.
With the existing code, the back button is disabled.
For disabling the home button they used onAttachedWindow with LayoutParams TYPE KEYGUARD,
but this security hole is fixed since 4.0.
I tried a lot of similar questions, but none worked out for me.
What is the way to get this done these days?
Also, hiding the status bar on tablet (where the home & back button live) would do the trick,
so any suggestions there are equally helpful!
Update: also, free third party apps that do the hiding trick are okay!
This sounds like a kiosk or dedicated use kinda thing, yes? You want your app to "own" the tablet and prevent other usage? I did this for an app whose sole purpose was to act as a remote control for a custom device. Basically I created two apps, a "custom launcher" app and the app that did the remote control. It's probably possible to integrate the two, but I wanted to support both dedicated and non-dedicated use. Note that I gave the launcher app a password-protected way to access settings so that I could recover the tablet at any time.
You can find a number of tutorials that will guide you through creating a custom launcher, just strip out all the stuff that makes it a generic launcher and replace it with an image button or similar that launches the actual app, or replace the launcher activity with your main app activity. Warning: I never figured out how to remove the launcher except by going into the settings.
As for hiding the system bar (notifications and status icons at the top of the screen), you'll want to use a full-screen theme like #android:style/Theme.NoTitleBar.Fullscreen.
As for hiding the home button I took this approach:
View main_layout = this.findViewById(android.R.id.content).getRootView();
main_layout.setSystemUiVisibility(View.STATUS_BAR_HIDDEN);
Unfortunately the STATUS_BAR_HIDDEN flag is deprecated now, but I think some of the other options would have the same effect. Regardless, the best you can achieve within Android's intended use is to temporarily hide the navigation buttons (home and back). A tap on the screen will bring them back.
I was hoping to make an app which dimmed the soft buttons to dots on the Galaxy Nexus, using the code from this answer. For completeness, this is the code:
getWindow().getDecorView().setSystemUiVisibility(View.SYSTEM_UI_FLAG_LOW_PROFILE);
Here's the question, is it possible for the app to make this setting system-wide rather than just while the app has focus? So ideally the app would run in the background and would keep View.SYSTEM_UI_FLAG_LOW_PROFILE as the default as long as it's running, for any and every app that you open (unless that app specifically overrides it, I suppose). Is this possible or does this fall outside the realm of what an Android app has permission to do?
A sample use case is this: I use the "Screen Filter" app to reduce brightness a lot for nighttime ebook reading or misc app usage, but the soft buttons are still very bright and distracting, so I wanted to make an app that would dim the soft buttons system-wide while running (like how "Screen Brightness" reduces screen brightness system-wide while running) so this wouldn't be a problem.
As CommonsWare states, it's not possible for an application to change this setting. It's an Activity based setting, that must be set for every single Activity, if you want to make it fullscreen, hide the soft keys, etc.
It's also worth pointing out that you should probably refrain from using it in all your application activities. It's really only meant for games, video players and other applications that need to enter this "low profile" state.
Feel free to accept CommonsWare's answer - I just thought I'd give you a bit of background info on the subject.
is it possible for the app to make this setting system-wide rather than just while the app has focus?
No.
Please give me feed back whether it's good practice to have a back button in activity, or is it just nonsense? Maybe some android phones don't have back/return key? Or do all models have them?
All android phones will have the back key. Putting a back button is, IMO, ugly and unnecessary; you better use your space with useful stuff. Sometimes your boss will just obligate you to put a Back button, usually because (sadly) most of the android sketchs are based on iPhone's ones... so the only reason why I'd put a back button is to not get fired (well, sometimes it's much better getting fired than becoming a poor programmer).
Piling on. I recently had a debate about this where we talked about design metaphors for android, iPhone, and windows mobile. The bottom line where we agreed is that you should follow the design metaphors for the device you are developing on. For android, the design should not include a back button because users are used to the physical back button. If one is required, the physical button should work as well.
I put a Back menu item in the option menu. The option menu in my apps seem to already contains other navigation-like menu items, so its seems reasonable to have a Back menu item in there. Having the explicitly labelled Back menu item there seems more newbie-friendly and the redundancy seems harmless there unless the option menu has a ton of menu items already.
OTOH, remembering that there is an option menu and remembering how to access it can be a challenge for some Android newbies. Yes Dad - I mean you. :-)
Similarly, on an Add/Edit screen, I provide Save and Cancel buttons, even though the Back button could be (and probably often will be) used to Cancel button. Again, having an explicitly labelled Cancel button seems more newbie-friendly and harmless. (What were you going to do with that empty space beside the Save button anyway?)
All android phones that want to have android market access need to have a menu, back and home button. those are the rules from El Goog. Some models may not have these but I bet that is a small number of devices.
I'm not sure if anything will change with honeycomb, seeing as Motorola Xoom has none of these buttons.
If you have an app that needs the space to exclude a "back" functionality, such as an "undo" functionality in a drawing app where you want to show the whole screen, then it's a great shortcut, but you better have a button as well.