Develop Reference

How to disable EditText auto complete when using textEmailAddress

I have an edit text with inputType set to textEmailAddress and I can't stop the keyboard from showing text suggestions. I want to use this flag so that the # sign shows up in the first set of keyboard characters but I don't want suggestions to appear because they consume a lot of space on the screen and mess up the user experience.
This is the code I'm using:
<EditText
android:id="#+id/email"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_gravity="center"
android:hint="#string/common_email"
android:imeOptions="actionDone"
android:inputType="textEmailAddress"
/>
I have tried changing inputType to
android:inputType="textNoSuggestions|textEmailAddress"
and to
android:inputType="textVisiblePassword|textEmailAddress"
but it doesn't work. It seems that when used, textEmailAddress overrides whatever the other flags do.
Is there a way to show to make the keyboard show the # sign but not show suggestions?

There is no way to absolutely assure that a keyboard doesn't show suggestions. Keyboards have total control over what they display, including suggestions. Anything you send it is just a hint as to what it should do, different keyboards interpret or ignore those hints as they please.
textVisiblePassword|textEmailAddress won't work- those are both specifying a major type. The result will be an ORing of their bits and you'll get something really weird. textNoSuggestions is the best bet. If that isn't working, then that keyboard either never honors no suggestions or doesn't for email fields.
As for showing the # sign- same deal. Keyboards control what keys they show. They may change slightly for different modes, but there's no way to force specific keys to show.
As a side note- I'm not certain turning off suggestions for email is the right thing to do. Many keyboards will add all email addresses in contacts into their dictionaries. Many users will add their own email to the dictionary for filling in forms. And many email addresses are combos of common words. Depending on how good the keyboard is with email mode, being able to do autocorrect is a better experience.

Try this, it worked for me.
android:importantForAutofill="no"

android default keyboard layout styling

I am wanting to alter the default (whatever is on your device's) keyboard, so that the colors displayed reflect my apps overarching theme better. for example white background, light blue keys, that go dark blue when pressed.
Using this tutorial I have created a custom Keyboard and am able to change the keybackground.xml to adjust the colors of keys on a KeyboardView etc.
<android.inputmethodservice.KeyboardView
android:id="#+id/keyboardview"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_alignParentBottom="true"
android:layout_centerHorizontal="true"
android:focusable="true"
android:focusableInTouchMode="true"
android:visibility="gone"
android:keyBackground="#drawable/keybackground"/>
what I am looking for is to apply this style to the default keyboard used by the device, failing that i have also looked for a copy of the keyboard layout xml so i can create a fully custom one with default key layout.
one possible method i have contemplated is replacing the following line (explained in the tutorial link).
mKeyboardView.setKeyboard(new Keyboard(mHostActivity, layoutid));
with another method of instantiating/getting default Keyboard.
Edit
I only require this keyboard to be displayed within my application.

You cannot change the colors of any of the installed keyboards (default or not), though some may allow you to create themes for them as a kind of extension but it would be something the user would install separately from your app. Keyboard apps are separate apps from yours and Android doesn't give you direct access to their layouts. You can create your own keyboard app of course, but this wouldn't make sense to do this in your case (as you're only after customizing colors for matching your app).
Additionally, it would be bad UX if each app changed the keyboard colors. Presumably, the user has picked a keyboard and theme that suits his/her visual needs, so it would be annoying if it changed between apps (imagine if you are a color blind user and an app changes the keyboard to colors you can't distinguish so you couldn't see what is on the keys anymore!).

You cannot do what you are planning to do in android, as it would be a massive security hole. Your app cannot change the default keyboard. What you can do is, make a new custom keyboard style and add it as a choice for the user. The user will have to go to settings->keyboard and select your keyboard. You will have to implement InputMethodService. Be warned though, its not a easy task. A lot of effort goes into it.

If you just want to add the keyboard to your application, add the keyboardview to your layout with visibility:gone. When the user clicks on an edittext field, consume the event going to the default keyboard and show your keyboard instead. Keep track of the keys pressed and append them wherever you need. Don't forget to hide your keyboard when the user clicks off the edittext field.

How to set keyboard in password-type mode on start of the Activity?

I'm using the android:windowSoftInputMode="stateVisible" command for drawing keyboard at the beginning of the Activity and it works just as I want it to work with 2 slight problems - swype-typing is enabled and so is the word prediction and I want to prevent it from happening. I thought maybe setting keyboard in passwordText input mode may solve the problem but I cannot find anywhere how to do it. Is there any method that will allow me to show keyboard in passwordText mode on start of the Activity?
Also I should add that I'm looking for the way of doing that in such a way, that the keybord won't show when app is ran on device with physical keyboard (that's why I used XML declaration in the first place).

Add the following to your Edittext in xml:
android:inputType="textPassword|textNoSuggestions"
or in code:
edittext.setInputType(InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS|InputType.TYPE_TEXT_VARIATION_PASSWORD);

Well, for the first question, AFAIK you set the textfield to password mode, not the keyboard, like this:
<EditText
android:id="#+id/password"
android:hint="#string/password_hint"
android:inputType="textPassword"
... />
More info here: https://developer.android.com/training/keyboard-input/style.html
Now, about preventing the keyboard from appearing on a device with physical keyboard, I recomend you check this answer:
How do I prevent the software keyboard from popping up?

Android Edit Text Cursor Doesn't Appear

in my app I disabled the keyboard (I use now my custom keyboard) using this code:
editText.setInputType(InputType.TYPE_NULL);
Now, my problem is that the text cursor does not appear anymore in the edit text. What should I do? Any suggestion would be very appreciated.

There is an Issue opened in bug tracker Issue opened in bug tracker for this.
One of the users suggests the approach which works on "most" devices.
Briefly, all you have to do is call:
editText.setRawInputType(InputType.TYPE_CLASS_TEXT);
for your EditText view (after you called editText.setInputType(InputType.TYPE_NULL);).
You should probably also set:
editText.setTextIsSelectable(true);
in order for text to be selectable (though in does not seem to work properly with Samsung Galaxy SIII). This method is only available starting from HONEYCOMB (api11) so keep that in mind when developing for older Android versions.
Also it is stated that your EditText should not be the first view to receive focus when activity starts (if it is - just requestFocus() from another view). Though I (personally) have not experienced any problems with this.

Rather than just using a custom view for your custom keyboard, why not implement a full-fledged IME? That will solve your cursor problem, and even make your keyboard available outside your app (if you want).
This answer has a couple useful links if you want to do that:
How to develop a soft keyboard for Android?

I really wouldn't suggest this. Writing a good full fledged IME is really hard. In addition, users come to expect functionality from their keyboard (auto-correct, Swyping, next word prediction, the ability to change languages) that you won't have unless you spend months on the keyboard itself. Any app that wouldn't allow me to use Swype would immediately be removed (bias note: I worked on Swype android).
But if you want to integrate fully with the OS as a keyboard, you're going to have to write an InputMethodService. Your keyboard would then be selectable by the user in the keyboard select menu, and usable for any app. That's the only way to get full OS integration, otherwise you'll need to really start from scratch- writing your own EditView. Have fun with that, getting one that looks nice is decidedly non-trivial.
Also, setting input type null won't disable most keyboards. It just puts them into dumb mode and turns off things like prediction.

I tried the below answer and it worked, but take care that
1) EditText must not be focused on initialization
2) when your orientation changes while the user's focus is on the editText, the stock keyboard pops up, which is another "solvable" problem.
This was mentioned in a previous answer but take care that you MUST make sure your editText element do not get focus on instantiation:
https://code.google.com/p/android/issues/detail?id=27609#c7
#7 nyphb...#gmail.com
I have finally found a (for me) working solution to this.
First part (in onCreate):
mText.setInputType(InputType.TYPE_NULL);
if (android.os.Build.VERSION.SDK_INT >= 11 /*android.os.Build.VERSION_CODES.HONEYCOMB*/) {
// this fakes the TextView (which actually handles cursor drawing)
// into drawing the cursor even though you've disabled soft input
// with TYPE_NULL
mText.setRawInputType(InputType.TYPE_CLASS_TEXT);
}
In addition, android:textIsSelectable needs to be set to true (or set in onCreate) and the EditText must not be focused on initialization. If your EditText is the first focusable View (which it was in my case), you can work around this by putting this just above it:
<LinearLayout
android:layout_width="0px"
android:layout_height="0px"
android:focusable="true"
android:focusableInTouchMode="true" >
<requestFocus />
</LinearLayout>

Android EditText with Swype Keyboard typing issues

I have a user that is having problems when she attemps to type in my app. The device she is using is the Motorola Electrify running Gingerbread and she is using the Swype Keyboard on her phone. When she attemps to add text to an existing item it just overtypes unless she uses the Swyping gestures to build the words.
Just to be clear I dont have any listeners coded that are cauing this. I have tested with the other stock keyboard on her phone (Multi Touch) and everything seems to work fine.
An example of what we are seeing: Press A the A appears on the screen then you press n it replaces the A.
Here is the layout for the edit text:
<EditText
android:id="#+id/editor_text"
android:layout_width="fill_parent"
android:layout_height="0dip"
android:layout_marginLeft="10dp"
android:layout_marginRight="10dp"
android:layout_weight="0.72"
android:gravity="top"
android:inputType="textMultiLine|textCapSentences|textAutoCorrect"
android:singleLine="false" >
</EditText>

So I was the lead Android developer for Swype until May of this year. So I'll do my old friends a solid and give some free tech support. What version of Swype is she using? And is she doing anything funny with inserting her own text into the edit text or losing focus from the edit box? If she turns off predictive text does it still happen?
The problem she mentions sounds like a problem I saw with some custom implementations of EditText where they did not properly implement getExtractedText and our predictive text solution expected to be able to retrieve the previously typed text from the editor (to work around a variety of bugs in yet other apps). But if you're using a stock EditText that shouldn't be the case. Let me know the answers to the above and I'll see what I can drag out of year old memories.