My App has the "Dynamic Services URL" set to true.
This is because we have several Application Servers and, also, the URL might change depending on the network we are connected to.
Android:
The App gets a menu on the AppBar (upper-right corner) with a "Settings" option in it.
The App startup invokes an Authentication procedure, that requires access to the Application Server.
Q1: If the last Application Server is unavailable (eg, device connected to a different network) the App will return a "Error: Connect time out" and will not give the Settings Menu, not allowing me to change the URL.
Even if i go to the device settings and Clear the app data, still, the app will try to reconect to the last / default Services URL.
It seems impossible to use the App again, until the previous Application Server becomes available so I can have access to the Settings Menu.
Is there any other way to change the Service URL?
Q2: I will have to create my own "settings" screen for the App (where user can select a default theme, default nÂș of rows, etc).
Can I add a new option into the menu that genexus creates (so I don't have 2 Settings menus)?
The fist point is officially recognized as a bug. See this SAC
The second point: I have no clue on how to achieve that (unify the 2 settings screens or create a custom edit box for setting the dynamic services URL). If there is a way, it may be programming an external object.
Related
I am trying to make my feedback app to support fully kiosk, I have tried a lot of solutions but Nothing is completely satisfying my need. Here are the things that I found yet.
1. Make my app as Device Admin/Owner App(Lock Task) -
If we follow this link/procedure https://developer.android.com/work/dpc/dedicated-devices/lock-task-mode, some limitations are there as follows -
a. We have to factory reset all the devices where Feedback app is installed, follow some steps to make it as admin app(launcher app).
b. Installation of the app will be possible using the command line, each installation will take some line of code through cmd, which means for installing a person has to go there with the computer and connect the device with USB and then install the app using commands.
c. Update on an app will also follow the same procedure (Couldn't be performed using google play store)
d. In this case, end-user will never be able to exit from our app, restart the device would also launch the same feedback app every single time.
2. Programmatically screen pinning + programmatically volume and power button controlling. (https://github.com/mrugacz95/kiosk)
a. In this, we will make the app in screen pinning mode where all the three bottom buttons(Overview, home, recent) will be hidden/disabled. and same with the power key and volume keys.
b. So As soon user clicks on kiosk mode, a screen pinning system generated prompt would be shown to user But the biggest disadvantage of it is that app would be unpinned/unlocked as soon as the user presses overview+recent buttons together.
3. The third Case is, where all the keys are controlled including power+voulme+back+overview etc.
Only pressing home will make the app to go on the background and within seconds it will again come foreground.
So all I found up until now, is not very satisfiable.
One more Question-
Is this something to be fully controlled by MDM(Mobile Device Management)?
Any help is appreciated.
1. Make my app as Device Admin/Owner App
a. A device owner can only be installed on a newly initialized device (before an account is added). I believe this is by design : A device owner can completely lock the device down, you don't want a malicious app to be able to seize the phone of an unsuspecting user after a few "I agree" popups.
b. You don't need to install it using adb. The simplest provisioning method is via NFC : While the device shows the very first screen of the setup wizard, touch it with a tag (or another device) containing the provisioning configuration, most importantly an URL where the apk can be downloaded and a WiFi config.
Another method is via QR code (Android 7+) : tap 6 times the first setup screen. It is a bit less convenient than NFC because you usually have to provision the WiFi manually.
c. A device owner can be updated like any other app. As it can itself install or update applications without asking the user, you can implement a fully automatized self update mechanism : check for update / download / update.
2. Lock task / screen pinning
Any application can programatically enter lock task mode. How it happens depends on whether the application is white listed by a device owner app (possibly itself) :
If not, the user is prompted and must accept, they can also exit at any time. This is basically the same thing as screen pinning.
If yes, there is no popup : the user can not decline to enter, nor exit, the lock task mode.
Additionally a kiosk application can act as a launcher. A device owner (again, possibly itself) can set it without user intervention
Is this something to be fully controlled by MDM(Mobile Device Management)?
While device owner apps are usually DPC connected to a MDM console of some sort, this is not a technical requirement. How you control it is completely up to you. (I hope I understood correctly the question)
Overall, I think that the only reliable way a device can be locked in kiosk mode is to use a device owner app (separately or included in the kiosk application). The setup via NFC or QR code is actually faster than a normal device setup. It can also protect against safe mode reboot or factory reset. The only real constraint is that you can not deploy this kind of application on existing devices without wiping them first.
Make my app as Device Admin/Owner App(Lock Task) -
a. If you are making it an 'admin app' this means you have signed the device image correct? Therefore you control the full flashing of the device - you can do anything in this scenario.
b. You can actually also do ADB over WiFi after you set it up the first time
c. You can update your apps from the playstore - even launcher applications
d. This fact is the whole point of Kiosk mode. Users should not ever be able to exit the application. Only you can exit, either with a remote command or with a invisible touch combination (for example touching each of the corners of the screen in sequence twice, or other 'secret unlock code')
Programmatically screen pinning + programmatically volume and power button controlling. (https://github.com/mrugacz95/kiosk)
b. This is the opposite of 1d, it is not clear what you want if you want neither.
The third Case is, where all the keys are controlled including power+voulme+back+overview etc.
This is also the opposite of 1d, it is not clear what you want if you want neither.
We need a few more details on your deployment scenario for this app to help you out further.
I made a small Google Home App and my service returns a response with a SimpleMessage + Card.
It works perfectly when running the app in the console.actions.google.com simulator. I get the card all good.
But when I test talking to the Google Home, it only sends the text, no trace of the Cards anywhere.
However If i talk to the Google home app on my phone, it does send the card correctly.
Is there something to enable to be able to receive cards sent by Google Home? Is it possible at all?
There is no way to make cards that were sent while the user is talking via Google Home visible, but there are several techniques that you, as a developer, can use if cards are necessary.
First of all - good design suggests that cards should be use to supplement the conversation, not be the focus of the conversation. Make sure the voice conversation itself is important and use the visual elements only when necessary. If your action is overly visual - it may be better suited as a mobile or web app, rather than an Action.
If your device requires a screen, then you can set this in the Action Console when you configure your question. This will, however, prevent it from being used on a Google Home device.
If you don't want to go this route, and want to allow it to be used on a smart speaker, but still take advantage of a screen where it is available, you have a few options.
First is that you can just send the cards. As you've discovered, they won't show up, but they won't cause any problems.
If you want to act slightly differently if a screen is available, you can check for the surface capabilities that the user's Assistant is capable of at that moment. If you're using the node.js library, you can have a command such as
let hasScreen = app.hasSurfaceCapability(app.SurfaceCapabilities.SCREEN_OUTPUT)
to determine if a screen is available and take action based on the variable hasScreen. If you're using JSON, you need to check the array at surface.capabilities or data.google.surface.capabilities to see if "actions.capability.SCREEN_OUTPUT" is one of the available surfaces.
If not, and you get to a point in the conversation where you feel you need to send a visual result, you can also request to continue the conversation on a device that does support screen output.
First, you'll need to make sure that they have a screen available. You'll do this with the node.js library with something like
const screenAvailable = app.hasAvailableSurfaceCapabilities(app.SurfaceCapabilities.SCREEN_OUTPUT);
or by checking the availableSurfaces.capabilities or data.google.availableSurfaces.capabilities parameters in JSON.
If one is available, you can request to continue the conversation there with something like
app.askForNewSurface(context, notif, [app.SurfaceCapabilities.SCREEN_OUTPUT]);
where context is the message that will be said on the Google Home, and notif is the notification that will appear on their mobile device (for example) to let them continue the conversation. If using JSON, you'll need to use a actions.intent.NEW_SURFACE next intent.
Either way, the user will get a notification on their mobile device. Selecting the notification will start up the Assistant on that device and your Action will be called again with parameters that let you check if they are on the new surface. If so - you can send the card.
I'm writing a code for an application to be used in specific devices, installed from custom firmware not from google play. My client company wants to control the application their workers can use and also want to block the access to Configuration except wifi and bluetooth settings.
I did that and it is working properly, but not in tablets. In smartphones I can get the name of the current application and make my way to allow or block the access.
But, using a Tablet, I get only the main configuration (com.android.settings) but I can't know that fragment is opened.
If the user pull down the notification panel I can block the configuration access, and also allow the wifi settings. In this moment, with the wifi panel opened, he can navigate to any other configuration fragment and I can't control it.
My question is: can I get the name of the right fragment from the configurations activity, from a service?
It is not possible to get the Activity for API > 22 Only the packageName. Befor you can get The activity but not the fragment.
I am working on an app that opens the Network Settings screen, where available networks search takes place (done automatically), after which I would like to read the activity's data.
Meaning, when all the networks that were found, appear as options on the Network Settings Activity's screen, I would like to get a feedback, somehow, and to read the data on the screen.
Listening to the logcat is not possible since 4.1 (if i'm not mistaking), and bottom line, even with the READ_LOGS permission, I can't do it on my Android 4.3 device. (Solved my problem before)
If so, is such a thing possible, and how?
I'm developing a Android application, and I would like that when it first starts it set itself as default action for Home button.
Currently this option is given to the user by the Android system only when he first press the Home button after running my app.
User don't want to click on check box as "Use by default for this action" it should be set by default my apps.
Thanks in advance.
This is not possible, and it is a good thing too.
Android allows users to choose their own defaults to prevent malicious apps from making themselves the default app to deal with an action, and hence protecting the user's data and device. If an app could set itself as the default homescreen or browser or call app etc. then it could steal the user's personal data and also potentially spoil or deny access to the device itself.
Due to the above reasons, this is not possible why the Android SDK, and I sincerely doubt that an unofficial means to do this exists.