Is there an intent for sending data for the keyboard to "type"?
This is more theoretical than practical, but is it possible to broadcast an intent that is received by the keyboard. The intent would contain a string which is then "typed" into the active input field. Alternative the intent could include a target field, which the keyboard could use to either select the right field in the view or prevent the data from being output to the wrong field.
Why?
I'm imaging this could useful for data collection applications.
Example 1: Bluetooth scale
Say you have an application for tracking your weight. Every morning you launch the app, weigh yourself, type in your weight. If the scale were paired with an application agnostic service on your phone you could just select the weight field and step up on the scale. The value would be sent to your phone and passed to the default keyboard using this intent.
Example 2: NFC id tags
A service form application requires a 16-digit machine serial number. There is an NFC tag on the machine which contains the serial number. Instead of typing it out manually, the NFC read intent is caught by a service which passes the value to the default keyboard via intent.
Criticisms:
The app could/should integrate with the scale directly.
Counter argument: Does not work with a web app and you are reliant on an app supporting (and maintaining support for) your particular solution (e.g. Bluetooth device).
Replace the input field with a button that launches an intent for result.
Counter argument: Same as above, plus it requires more user interaction; Clicks and time are premium commodities.
If it doesn't exist, would it be the worst idea for keyboards to implement such an intent receiver? Or would it just open the door to bad application design? Security-wise?
Is there an intent for sending data for the keyboard to "type"?
Fortunately, no, for obvious security reasons. One app cannot force input into another app outside of very select situations (e.g., JUnit test apps).
The app could/should integrate with the scale directly.
Correct.
Does not work with a web app
Then write a native app.
you are reliant on an app supporting (and maintaining support for) your particular solution (e.g. Bluetooth device)
You need that anyway, as it is impossible to speak arbitrary Bluetooth and get input suitable for an arbitrary text field in an arbitrary native app or Web app. Otherwise, your proposed soft keyboard will try to grab data from your Bluetooth headset and type it into Twitter, and your music is probably longer than 140 characters.
would it be the worst idea for keyboards to implement such an intent receiver?
That depends on your definition of "worst". I would hope that the implementer of such an input method editor has a very large legal defense fund for the inevitable lawsuits that will result from such a gaping security hole.
Related
I have been recently working on an app which requires to respond to an Automatic attendant (virtual receptionist) which allows callers to be automatically transferred to an extension without the intervention of an operator/receptionist.
My requirement is such that to make a scheduled phone call to a particular number and to respond to the Automatic attendant instructions ("for sales, press 1, for service, press 2," etc)
Is it possible to achieve similar action that i could otherwise achieve by responding to the system manually by pressing an option (say 1 or 2 from above example) programmatically while the call is still active.
Any help is appreciated.
There's no way to do this. There isn't an API, and since the dialer is not part of the OS and can be any app, you can't count on anything working on all devices.
The best chance you have is to assume the dialer will accept USSD input (USSD is an ancient telephony protocol for sending data to phones). In the USSD language, a comma is a pause. SO if you want to dial a number, than 1 at the prompt you could ask it to dial "number,,,,1" and hope that the dialer accepts USSD input and that the pause is long enough to dial the 1 at the right time. But it will work on only a subset of all devices, and be fragile there.
I am new to android and i have developed an app locker.Now,i want that the application,i am locking should be unlocked with nfc tag that is without typing the password manually.How can i perform it?
As you already have the app locker part, I assume that when a user tries to launch an app, your app locker will instead show its unlock activity asking the user for a password.
On that unlock activity, you could now (instead or besides asking for the password) ask the user to scan the NFC tag. Your activity would therefore register for the NFC foreground dispatch system and wait until an NFC tag is scanned (or the user maunally types the password). As soon as your activity receives the NFC tag discovery intent through the foreground dispatch system, you could communicate with the tag and base your access control decision on the result of this communication.
As to what NFC tag/contactless smartcard you should use and what information you should store on it: That's a difficult question! This very much depends on your security requirements. In the easiest case, you could base your decision on the tag's (unique) identifier. However, you have to keep in mind that the identifier is neither unique nor unclonable. As an alternative you could use a (real) NFC tag and store an NDEF message on it. That NDEF message could contain some identifier/password that your app uses as an unlock credential. Again, NFC tags are publicly readable and therefore the NDEF message may be copied/cloned to another tag. Further security can be achived with tags that support cryptographic functionality beyond NFC Forum tag types, but discussion of that is certainly to broad for the StackOverflow format.
As I understand the technology, this isn't possible with the screen completely off. It's a security feature that the secure element only turns on when the screen turns on. So it should be a hardware limitation not a software one.
I've got a unique situation where I have to query the phone to determine which app will be handling incoming phone calls. I realize that in 95% of cases com.android.phone is doing this work, however, I can't only be right 95% of the time, I need to know 100% of the time what app it'll be (user could have installed a custom phone app afterall to handle calls).
Being familiar with intents, I figured I could simply ask PackageManager to identify all apps that could handle these actions: Intent.ACTION_ANSWER and or Intent.ACTION_CALL (the only two Intent actions relevant to phone calls), after all, this approach works for virtually all other phone functions I've tried.
Unfortunately, whenever one tries to query PackageManager, say either using .resolveActivity() or .queryIntentActivities(), the result is always 'null', even when default applications exist for these intents. To further compound my frustration, there's absolutely zero documentation on why these intent actions can't be utilized. The documentation reads as if I am doing everything exactly right to reach my objective.
So, the question is two-fold: is there any reasonable method whatsoever to determine the phone app (hopefully the default app) AND why the heck can't intent actions created for this exact purpose be utilized?
TL;DR There's two intent actions that relate to phone calls, except, you can't use these to query PackageManager to find the underlying apps that facilitate these intent actions. Why not?
I want to make an android service that would let me simulate keypress to fill fields on a web page when receiving an intent. Is this possible in any way or maybe through a different process (Not by simulation keypress?).
For example an example of what I would want to be able to do.
The user is on his tablet and has selected a field on a web page. For any bluetooth device discovered, fill the field with that id.
IS there a way to do it by calling an intent of the web browser or something like that?
Thanks
EDIT : figured my example was pretty bad.
Here is what I really want to do
When a nfc tag is detected on the phone,
read the nfc tag ID,
simulate keypress events of the id tag on whatever the focus is at the moment on the phone
Example : I'm on google focused on the search field and I put a nfc tag on the phone, the phone types the Nfc tag id on the google search field and voila
if you really want to simulate keyevents, you can use system calls:
input keyevent <keycode>
I would advice you to use BroadCast receiver. You have to create a Custom intent class after that, register the receiver when the user select a field. For interaction with web page, its better to use javascript to call native android method.
When you detect a device send your broadcast, if you are registered, you will handle the event.
Let's say i have an android device that has some extra buttons on it, can i register one of those buttons to launch my app? is there a configuration file on the device that controls hardware keys behavior?
Let's say i have an android device that has some extra buttons on it, can i register one of those buttons to launch my app?
You would have to ask the device manufacturer that question. Non-standard buttons, by definition, are non-standard, so the device manufacturer would need to document their use. In particular, you would need to know if there is a broadcast Intent sent out if the button is pushed and is not used by the current activity, as is the case for the camera and media buttons today.