Child Class Of Edittext Looks Different Than Normal Edittext On Android 4

This is a 'bug' that I discovered while working on a real app, but I created a blank project to reproduce it. I have the following layout:

A: The widget tinting in AppCompat works by intercepting any layout inflation and inserting a special tint-aware version of the widget in its place. For most people this will work fine, but I can think of a few scenarios where this won’t work, including:

• You have your own custom version of the widget (i.e. you’ve extended EditText)
• You are creating the EditText without a LayoutInflater (i.e., calling new EditText()).

So, the behavior is expected. The AppCompat backport provides some lightweight backporting of tinting, but it's not going to handle all cases.

how can I prevent it?

Off the cuff, either:

• Do not create a subclass of EditText, or

• When running on AppCompat, look up the tint and figure out how to apply it yourself, perhaps by examining the AppCompat source code (assuming it's available -- I haven't looked for it), or

• Do not use AppCompat, and see if tinting works as expected using Theme.Material on Android 5.0+ devices

It's possible that a future AppCompat could provide some sort of system for subclasses to participate in the tinting process. And there may be other solutions than these -- these are what come to mind.

Solution 2:

Actually the conclusion reached in this accepted answer here is not entirely true (anymore). You SHOULD use AppCompat, but just need to realise that AppCompat will substitute your EditText with AppCompatEditText during layout inflation. The same process happens to a few other UI elements too, like Switch, CheckBoxes, etc. Google did this so that they can push Material design look-n-feel as far and wide with minimal code changes from the users.

If you want to subclass EditText, you should subclass AppCompatEditText (android.support.v7.widget.AppCompatEditText).