Android N has a new feature - Multi Window Mode. It enables two applications to be active side-by-side (actually one one is active, other one is paused but we can see both simultaneously).
I am looking for an API that I can call to have my application enter multi-window mode. I couldn't find much help in Android N SDK docs. I am trying to have two activities of my app run side by side, but without user having to do manual steps.
MANUALLY ENTERING MUTLI-WINDOW MODE
The user can switch into multi-window mode in the following ways:
If the user opens the Overview screen and performs a long press on an activity title, they can drag that activity to a highlighted portion of the screen to put the activity in multi-window mode.
If the user performs a long press on the Overview button, the device puts the current activity in multi-window mode, and opens the Overview screen to let the user choose another activity to share the screen.
The SDK for API 24 introduced a new constant to toggle split screen mode from an accessibility service:
https://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html#GLOBAL_ACTION_TOGGLE_SPLIT_SCREEN
The constant can be passed to following method:
https://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html#performGlobalAction(int)
Google seems to have missed to document the new constant in the performGlobalAction method. I still consider this to be an official API since Google did not mark the constant as hidden.
You have to implement an accessibility service in your app and let the user manually enable the service in system settings->Accessibility so it might not be a viable option for all apps.
As of Android N, this is not supported.
The only supported way to enter multi-window mode is if the user manually triggers it.
I don't think that an api for the thing you want to do exists, You could try making your app have two fragments on each side of the screen. With a black bar in the middle, make each fragment resize according to the "X" position of the bar. :)
Related
iam developing screenlock app for android using a React Native and a little annoyed with the screen pinned dialog that always appears, is there a way to just get rid of it? so what I really want is no dialogue interaction at all with the user
enter image description here
If you're calling startLockTask() and your device isn't set up as a dedicated device with your app whitelisted, then no you can't prevent it:
Otherwise, the current task will be launched into screen pinning mode. In this case, the system will prompt the user with a dialog requesting permission to use this mode. The user can exit at any time through instructions shown on the request dialog.
The dialog is there to help users understand what's happening, give permission for the app to take over their screen, and know how to get out of it later. It's baked into Android by design, so malicious apps can't cause problems - it's just a limitation you have to deal with, unless you're working with a dedicated device (which can be set up to give apps more control and users less)
Have you thought about immersive mode instead, where you hide the nav bar? The user can get out of that too by swiping to reveal the controls, but it's less intrusive. There's no way to automatically lock the user's screen with no interaction though
I'd like to have kind of a parental control option on my kids' phone that would work like this: the only way to use the phone is by doing a certain (potentially boring) task. The goal would be to discourage frequent phone use. So if the phone is off or the screen is blank/idle and they turn it on they are presented with a lock screen that makes them do a couple of things and they can only access all other normal phone features once they did what they were asked to do.
Now prior to android 4.0 I would implement a lock screen application and I would be done. But with 4.0+ the home button press event can not be caught so the lock screen app will not work, they will simply hit the home button.
With 4.0+ I can still implement a full home screen app or launcher though and I can catch the home button press events. This all looks great but my kids can simply go to the menu where they can choose from all available launchers, they will see my custom launcher and the default one, and they can simply select the default one.
It looks now to me that what I'd like to accomplish is simply not possible with 4.0+. Is this really the case or am I overlooking something?
Instead of implementing home or lock screen you can write an app that will draw on other apps UI so your kids will have to do those boring tasks regardless of whether they lock the phone or what launcher they are using.
In order to do so you will need to implement a service (so that your code will run in the background - as you won't have your own activity running).
You can get reference to the window manager by calling Context.getSystemService:
mWindowManager = (WindowManager) getSystemService(Context.WINDOW_SERVICE);
once you have reference to the window manager, simply create your own view (inflate it from XML or create it in code) and add it to the window by mWindowManger.addView(...)
In recent versions of Android it's possible for devices to either have software or hardware buttons. I'd like to find out which is the case for the device my app is running on.
Some background information: It is possible to hide the softkeys as they are displayed on the screen but if you do this they automatically get shown if the user touches the display which is perfectly fine. Now if you do the same on a device with hardware keys the first touch still gets caught by the system like as if it would show the softkeys again but as there are none, nothing happens and the touch event does not get passed to the app.
You could use ViewConfiguration.hasPermanentMenuKey(), to check for a menu key.
For the Keyboard-question try
getResources().getConfiguration().keyboard
that gives you one of the following:
KEYBOARD_NOKEYS
KEYBOARD_QWERTY
KEYBOARD_12KEY
check for KEYBOARD_NOKEYS.
Is it possible to simulate user input in android ?
For example to have some service or some thread that will work in background and initiate something that will simulate user input so if we are on the home screen and simulated input(let say click) happened than the application should start if the coordinates of the simulated click point to some icon on the home screen , or let say open a clock if the simulated input points to the clock area ...
or maybe if some edittext have focus and the simulated input of keystrokes start then the edittext should be filled with some text . . .
I am sure that this can be done in .Net or java but I do not know if it is possible in android
From documentation on building accesibility services:
Starting with Android 4.0 (API Level 14), accessibility services can act on behalf of users, including changing the input focus and selecting (activating) user interface elements. In Android 4.1 (API Level 16) the range of actions has been expanded to include scrolling lists and interacting with text fields. Accessibility services can also take global actions, such as navigating to the Home screen, pressing the Back button, opening the notifications screen and recent applications list.
(...)
In order to take actions on behalf of users, your accessibility service must register to receive events from a few or many applications and request permission to view the content of applications by setting the android:canRetrieveWindowContent to true in the service configuration file.
See the linked documentation for details.
Is it possible to simulate user input in android ?
Only from a unit test suite. IOW, not in the way that you are thinking, as it would be a massive security hole.
Are the physical buttons that Android phones come with standard? Specifically the back, menu, home, and search button? In my applications I assume everyone has a back button so I don't bother putting in a "soft" button to go back to a previous screen.
For some reason I can't find any official documentation on this.
Looking at http://www.androphones.com/2010-android-phones.php it appears that all of the phones have at least the back, menu and home button.
Should I just assume all phones have a back button or do I have to always code one in my apps?
The CDD describes what is required to be compatible:
http://source.android.com/compatibility/index.html
(See "Current CDD" on the left)
In this case:
7.2.3. Navigation keys
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
I haven't been able to find any definitive answer one way or another. However, the documentation assumes there will always be a Back key that the OS responds to:
As the user moves from activity to activity, across applications, the Android system keeps a linear navigation history of activities the user has visited. This is the activity stack, also known as the back stack. In general, when a user starts a new activity, it is added to the activity stack, so that pressing BACK displays the previous activity on the stack. However, the user cannot use the BACK key to go back further than the last visit to Home. The adding of an activity to the current stack happens whether or not that activity begins a new task (as long as that task was started without going Home), so going back can let the user go back to activities in previous tasks. The user can get to tasks earlier than the most recent Home by selecting its root activity from the application launcher, a shortcut, or the "Recent tasks" screen.
Activities are the only things that can be added to the activity stack — views, windows, menus, and dialogs cannot. That is, when designing the navigation, if you have screen A and you want the user to be able go to a subsequent screen B and then use the BACK key to go back to screen A, then the screen A needs to be implemented as an activity. The one exception to this rule is if your application takes control of the BACK key and manages the navigation itself.
From http://developer.android.com/guide/practices/ui_guidelines/activity_task_design.html
Based on that, I would say it is safe to assume that there will always be a physical Back key.
If you are developing specifically for the android the back button is standard.
The only other thing you could do is within the menu add a 'back' option, but it is redundant at best.
Amazon Fire phone do not have a back key.
On Android platform it is generally wrong to assume that, standard defined by an entity will work everywhere. It is usually depend on device manufacturer.
if your app rely on some specific device feature, make sure that you check and recheck, if that specific feature exist on device. Some time just putting information on AndroidManifest is not enough.