Develop Reference

Android TextView.setText() is not changing on recent Samsung phones with SurfaceView Overlay

In my app I have a TextView and an ImageView that I update based on sensor information. This works perfectly on emulators and most of the handsets I have tried it on, however on Samsung handsets from the S7 to the S9 for some reason neither of them changes when they should be updated.
They are part of a Fragment overlaying a SurfaceView with a camera preview in it, there is a second SurfaceView overlay above them:
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context="myApp.CameraViewFragment">
<FrameLayout
android:id="#+id/control"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout_alignParentBottom="true"
android:layout_alignParentStart="true">
<myApp.CameraSurfaceView
android:id="#+id/camera_view"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_alignParentStart="true"
android:layout_alignParentTop="true" />
<TextView
android:id="#+id/direction"
android:layout_width="80dp"
android:layout_height="wrap_content"
android:background="#color/black_overlay"
android:layout_gravity="center_horizontal"
android:gravity="center"
android:layout_centerInParent="true"
android:layout_centerHorizontal="true"
android:layout_marginTop="10dp"
android:textSize="30dp"
android:text="" />
<ImageButton
android:id="#+id/gpsNotification"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:src="#drawable/gps_unfixed"
android:layout_gravity="right"
android:tint="#color/gps_unfixed"
android:background="#null" />
</FrameLayout>
<com.myapp.OverlaySurfaceView
android:id="#+id/overlay_view"
android:layout_width="200dp"
android:layout_height="200dp"
android:gravity="center"
android:layout_gravity="center_horizontal|center_vertical"
android:layout_centerHorizontal="true"
android:layout_centerVertical="true" />
</FrameLayout>
As far as I know, this is the relevant part of the Fragment code:
public class CameraViewFragment extends Fragment
{
private TextView directionView;
private CameraSurfaceView cameraView;
private OverlaySurfaceView overlay;
#Override
public void onViewCreated(final View view, Bundle savedInstanceState) {
cameraView = (CameraSurfaceView) view.findViewById(R.id.camera);
directionView = (TextView) view.findViewById(R.id.direction);
overlay = (OverlaySurfaceview) view.findViewById(R.id.overlay_view);
}
private void setDirection(AccurateDirection direction) {
final String directionString = direction.getDirection();
overlay.update();
Activity activity = getActivity();
if ( activity != null ) {
activity.runOnUiThread(new Runnable() {
public void run() {
directionView.setText(directionString);
directionView.invalidate();
}
});
}
}
}
When I run this on a regular handset, the directionView text updates as new direction data arrives. On a Samsung S7 the value gets set once, maybe updated once right at the start and then it seems to stick and not change any more. If I pause in the debugger and call directionView.getText() from the immediate window, it gives me the result I am expecting, not what I see on the screen. If I call directionView.setText('ABC') in the immediate window, the value returned by directionView.getText() changes but again the value on the screen does not. The ImageView also seems to get stuck in its initial state regardless of changes that should adjust it.
Previous questions on this topic seem to involve updates not being triggered from the UI thread or failures to call invalidate on the view component, so I have fixed both of those already but the problem persists.
I have only seen this on recent Samsung handsets ( my old Samsung S4 appears to be fine ) which makes it hard to troubleshoot. Why are my view components not changing on the Samsung devices and what do I need to do to get them to update?
Edit: Apologies to anyone previously attempting to answer this as I had ommited the OverlaySurfaceView and I now realise that the other components update correctly if the OverlaySurfaceView is removed, so apparently having that second SurfaceView in the view hierarchy is interfering, but only on Samsung. Switching on and off hardware acceleration doesn't seem to make a difference, but there may be a specific place or way that I need to do it. On a working handset hardware acceleration is marked as disabled for the `OverlaySurfaceView.

I had the same issue with Samsung S7 device,
eventually I realized i was not handling the setZOrderOnTop correctly
check out this answer :
Button on top of SurfaceView with setZOrderOnTop set to true in Android

ConstrainLayout ConstraintSet - not working properly with Start/End constrains

Looks like ConstraintSet is finding hard to cope up with Start/End constrains.
This example is taken from Google samples.
Github: android-ConstraintLayoutExamples
When you replace Left & Right constrains with Start & End, ConstraintSet - not working properly, It's working with Left/Right constrains only.
For example replace
layout_constraintStart_toStartOf with layout_constraintLeft_toLeftOf & replace
layout_constraintEnd_toEndOf with layout_constraintRight_toRightOf
in following files:
constraintset_example_main.xml
constraintset_example_big.xml
Behaviour:
onClick of image:
private ConstraintSet mConstraintSetNormal = new ConstraintSet();
private ConstraintSet mConstraintSetBig = new ConstraintSet();
public void toggleMode(View v) {
TransitionManager.beginDelayedTransition(mRootLayout);
mShowBigImage = !mShowBigImage;
applyConfig();
}
private void applyConfig() {
if (mShowBigImage) {
mConstraintSetBig.applyTo(mRootLayout);
} else {
mConstraintSetNormal.applyTo(mRootLayout);
}
}
By default Android studio uses start/ end constrains hence it's I want to know root cause and possible fix.
Or Is this a bug with ConstrainSet itself?

This does look like a problem with ConstraintSet, but let's see. The following analysis is based upon the sample project with the link that you supplied.
In the sample project, I have updated ConstraintLayout to the most recent version:
compile 'com.android.support.constraint:constraint-layout:1.1.0-beta5'
I did this in case we are trying to track down an issue that has already been addressed. I also updated the layout constraintset_example_big and replaced all left/right constraints with start/end constraints as follows:
constraintset_example_big.xml
<android.support.constraint.ConstraintLayout
android:id="#+id/activity_constraintset_example"
android:layout_width="match_parent"
android:layout_height="match_parent" >
<ImageView
android:id="#+id/imageView"
android:layout_width="0dp"
android:layout_height="0dp"
android:layout_marginEnd="24dp"
android:layout_marginStart="24dp"
android:layout_marginTop="24dp"
android:onClick="toggleMode"
android:scaleType="centerCrop"
android:src="#drawable/lake"
app:layout_constraintDimensionRatio="h,16:9"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintTop_toTopOf="parent"
android:contentDescription="#string/lake_tahoe_image" />
<TextView
android:id="#+id/textView9"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="#string/lake_tahoe_title"
android:textSize="30sp"
app:layout_constraintStart_toStartOf="#+id/imageView"
android:layout_marginTop="8dp"
app:layout_constraintTop_toBottomOf="#+id/imageView" />
<TextView
android:id="#+id/textView11"
android:layout_width="0dp"
android:layout_height="0dp"
android:text="#string/lake_discription"
app:layout_constraintStart_toStartOf="#+id/textView9"
android:layout_marginTop="8dp"
app:layout_constraintTop_toBottomOf="#+id/textView9"
app:layout_constraintEnd_toEndOf="#+id/imageView"
app:layout_constraintBottom_toBottomOf="parent"
android:layout_marginBottom="16dp"
app:layout_constraintHorizontal_bias="0.0"
app:layout_constraintVertical_bias="0.0" />
</android.support.constraint.ConstraintLayout>
With these changes in place, this is what we see.
This is clearly not right. It is supposed to look like this after the transition.
After some debugging, I tracked the issue down to this line in ConstraintSetExampleActivity.java:
mConstraintSetBig.load(this, R.layout.constraintset_example_big);
ConstraintSet#load() seems to be straightforward, but if we replace the code above with an explicit inflation of the layout followed by a clone of the ConstraintSet on the inflated layout as follows:
// mConstraintSetBig.load(this, R.layout.constraintset_example_big);
ConstraintLayout cl = (ConstraintLayout) getLayoutInflater().inflate(R.layout.constraintset_example_big,null);
mConstraintSetBig.clone(cl);
We see this behavior in the app which is much better.
So my takeaway is that ConstraintSet#load() has a problem with start/end constraints. The workaround is to inflate the ConstraintLayout then do a clone.
ConstraintSetExampleActivity#onCreate()
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.constraintset_example_main);
mRootLayout = (ConstraintLayout) findViewById(R.id.activity_constraintset_example);
// Note that this can also be achieved by calling
// `mConstraintSetNormal.load(this, R.layout.constraintset_example_main);`
// Since we already have an inflated ConstraintLayout in `mRootLayout`, clone() is
// faster and considered the best practice.
mConstraintSetNormal.clone(mRootLayout);
// Load the constraints from the layout where ImageView is enlarged.
// Toggle the comment status on the following three lines to fix/break.
// mConstraintSetBig.load(this, R.layout.constraintset_example_big);
ConstraintLayout cl = (ConstraintLayout) getLayoutInflater().inflate(R.layout.constraintset_example_big,null);
mConstraintSetBig.clone(cl);
if (savedInstanceState != null) {
boolean previous = savedInstanceState.getBoolean(SHOW_BIG_IMAGE);
if (previous != mShowBigImage) {
mShowBigImage = previous;
applyConfig();
}
}
}

This issue is known and will be fixed in the 1.1 beta 6 release
https://issuetracker.google.com/issues/74253269

For those who faces issues like constraint set clone not working properly, my layout was not updating to new constraints when i called clone and applyTo methods after an api call, turns out it was due to a loading dialog i showed before the change that caused the error.

Snackbar and other animations stopped working on some Android devices

I have a very odd issue that I cannot figure out. I was not an issue until recently but I can't seem to revert back to prevent it. Also the other odd thing is it works on some devices and others it does not.
The issue is animations. One in particular is snack bar. The snackbar should animate up and down but it is not. it just shows then hides. check video below to see issue.
Video of issue
Here is the Android code to animate the snackbar in
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH) {
ViewCompat.setTranslationY(mView, mView.getHeight());
ViewCompat.animate(mView)
.translationY(0f)
.setInterpolator(FAST_OUT_SLOW_IN_INTERPOLATOR)
.setDuration(ANIMATION_DURATION)
.setListener(new ViewPropertyAnimatorListenerAdapter() {
#Override
public void onAnimationStart(View view) {
mView.animateChildrenIn(ANIMATION_DURATION - ANIMATION_FADE_DURATION,
ANIMATION_FADE_DURATION);
}
#Override
public void onAnimationEnd(View view) {
onViewShown();
}
}).start();
}
Its using ViewCompat for the v4 Library. I have other animations working in another activity working fine. Also the issue is not on just one activity its all of them. That makes me think its system wide somehow. But they all use different internal themes but all extend Theme.AppCompat.NoActionBar.
Here is my main layout
<android.support.design.widget.AppBarLayout
android:id="#+id/appbar"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:theme="#style/ThemeOverlay.AppCompat.Dark.ActionBar"
app:elevation="4dp">
<android.support.v7.widget.Toolbar
android:id="#+id/toolbar"
android:layout_width="match_parent"
android:layout_height="?attr/actionBarSize"
android:background="?attr/colorPrimary"
app:titleTextAppearance="#style/ToolbarTitle"
app:popupTheme="#style/ThemeOverlay.AppCompat.Light"
app:layout_scrollFlags="scroll|enterAlways|snap"/>
<android.support.design.widget.TabLayout
android:id="#+id/tabs"
android:layout_width="match_parent"
android:layout_height="wrap_content"
app:tabTextAppearance="#style/TabText"
app:tabMinWidth="#dimen/tab_minwidth"
app:tabMode="fixed"
app:tabGravity="fill"
app:layout_scrollFlags="enterAlways"/>
</android.support.design.widget.AppBarLayout>
<FrameLayout
android:id="#+id/content_frame"
android:layout_width="match_parent"
android:layout_height="match_parent"
app:layout_behavior="#string/appbar_scrolling_view_behavior" >
<android.support.v4.view.ViewPager
android:id="#+id/viewpager"
android:layout_width="match_parent"
android:layout_height="match_parent" />
</FrameLayout>
<fr.castorflex.android.circularprogressbar.CircularProgressBar
android:id="#+id/base_progressSpinner"
android:layout_gravity="center"
android:layout_width="48dp"
android:layout_height="48dp"
android:indeterminate="true"
android:visibility="invisible"
app:cpb_color="#color/spinner"
app:cpb_rotation_speed="1.0"
app:cpb_sweep_speed="1.0"
app:cpb_stroke_width="4dp"
app:cpb_min_sweep_angle="10"
app:cpb_max_sweep_angle="300"/>
<android.support.design.widget.FloatingActionButton
android:id="#+id/fab_upload"
android:visibility="gone"
android:layout_height="wrap_content"
android:layout_width="wrap_content"
app:layout_anchor="#id/content_frame"
app:layout_anchorGravity="bottom|right|end"
app:borderWidth="0dp"
android:src="#drawable/app_fab_upload"
android:layout_margin="#dimen/big_padding"
android:clickable="true"
app:backgroundTint="#color/fab_social"/>
<android.support.design.widget.FloatingActionButton
android:id="#+id/fab_muzei"
android:visibility="gone"
android:layout_height="wrap_content"
android:layout_width="wrap_content"
app:layout_anchor="#id/content_frame"
app:layout_anchorGravity="bottom|right|end"
app:borderWidth="0dp"
android:src="#drawable/app_fab_muzei"
android:layout_margin="#dimen/big_padding"
android:clickable="true"
app:backgroundTint="#color/fab_social"/>
</android.support.design.widget.CoordinatorLayout>
Devices it works on
Nexus 9 (Marshmallow)
Nexus 4 (KitKat)
Galaxy S7 (Marshmallow)
Devices it does not work
Droid Turbo 2 (Marshmallow)
Galaxy S7 (Marshmallow) *my device works, my testers does not
Nexus 6p (Android N)
The other animation issues are with Switches. I have 2 in same layout and one stutters when switched and the other just switches with no animation.
I also have a LayoutTransition set to my AppBarLayout to animation the hiding/showing of my TabLayout and it works fine and all devices

I found the reason why this is happening, but not how to fix yet.
/**
* Returns true if we should animate the Snackbar view in/out.
*/
private boolean shouldAnimate() {
return !mAccessibilityManager.isEnabled();
}
That is called by Snackbar class and is false on working devices, and true on devices not working. Does anyone know about this?
So after i disabled lastpass in my system settings, accessibility the snackbar now animates as it should. That is crazy how that works. Nova launcher has the same affect. I guess any service in accessibility that is enabled will cause the snackbar animation to not work.

As Bignadad mentioned, the problem is that any accessibility feature, including things like password managers, disables the snackbar animations. Google, as of this edit, has fixed this for AndroidX but not the Design support library
Because Snackbar's base class, BaseTransientBottomBar, handles the animation, with package private, final methods, you have two choices if you want to fix it: roll your own snackbar from scratch, or use a more hacky solution with reflection:
Kotlin example:
// Only force when necessary, and don't animate when TalkBack or similar services are enabled
val shouldForceAnimate = !accessibilityManager.isEnabled && accessibilityManager.getEnabledAccessibilityServiceList(AccessibilityServiceInfo.FEEDBACK_SPOKEN).isEmpty()
Snackbar.make(coordinatorLayout, text, duration).apply {
if (shouldForceAnimate) {
try {
val accManagerField = BaseTransientBottomBar::class.java.getDeclaredField("mAccessibilityManager")
accManagerField.isAccessible = true
val accManager = accManagerField.get(this)
AccessibilityManager::class.java.getDeclaredField("mIsEnabled").apply {
isAccessible = true
setBoolean(accManager, false)
}
accManagerField.set(this, accManager)
} catch (e: Exception) {
Log.d("Snackbar", "Reflection error: $e")
}
}
}.show()
Java example:
// Only force when necessary, and don't animate when TalkBack or similar services are enabled
boolean shouldForceAnimate = !accessibilityManager.isEnabled() && accessibilityManager.getEnabledAccessibilityServiceList(AccessibilityServiceInfo.FEEDBACK_SPOKEN).size == 0;
Snackbar snackbar = Snackbar.make(coordinatorLayout, text, duration);
if(shouldForceAnimate){
try {
Field accManagerField = BaseTransientBottomBar.class.getDeclaredField("mAccessibilityManager");
accManagerField.setAccessible(true);
AccessibilityManager accManager = (AccessibilityManager) accManagerField.get(snackbar);
Field isEnabledField = AccessibilityManager.class.getDeclaredField("mIsEnabled");
isEnabledField.setAccessible(true);
isEnabledField.setBoolean(accManager, false);
accManagerField.set(snackbar, accManager);
} catch (Exception e) {
Log.d("Snackbar", "Reflection error: " + e.toString());
}
}
snackbar.show();
I'd love a third option here, but I'm not aware of one, at least until AndroidX gets out of beta with the proper fix.

This has been fixed since Material Components for Android 1.0.0-alpha3 with this commit.
Use it instead of the Design Library (which is the way to go if you're using AndroidX):
implementation "com.google.android.material:material:$material_components_version"

Android: requestLayout() improperly called

The following error occurs when I attempt to inflate a layout within a ListView:
requestLayout() improperly called by android.widget.TextView{...} during layout: running second layout pass
I am attempting to inflate a layout within a ListView as follows:
#Override
public View getView(int position, View convertView, ViewGroup parent) {
if(convertView == null){
LayoutInflater inflater = (LayoutInflater) musicActivity.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
convertView = inflater.inflate(R.layout.list_item, parent, false);
...
}else{...}
}
The layout being inflated can look as simple as the following, and will still produce the error
<TextView
android:id="#+id/txt"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:textSize="#dimen/txt_size"/>
I have looked into similar questions, and no solutions found seem to work Question 1, Question 2, Question 3.
Does anyone know what causes this type of error? Any troubleshooting advice? For more context, this ListView is displayed within a Fragment within a ViewPager
UPDATE
Here is the full XML Layout (minus a bunch of attributes), that still results in the problem
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent">
<TextView
android:id="#+id/txt1"
android:layout_width="wrap_content"
android:layout_height="wrap_content" />
<TextView
android:id="#+id/txt2"
android:layout_width="wrap_content"
android:layout_height="wrap_content" />
<TextView
android:id="#+id/txt3"
android:layout_width="wrap_content"
android:layout_height="wrap_content" />
<TextView
android:id="#+id/txt4"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
</RelativeLayout>
Based on this, I would think the XML itself is not a problem, unless it has to do with the fact that I am using a ViewPager and Fragments

This issue seems to be a bug in the android implementation, please see: https://code.google.com/p/android/issues/detail?id=75516
Activating the fast scroll feature of a ListView in your code via ListView.setFastScrollEnabled(true) will trigger this bug and you'll start seeing the
requestLayout() improperly called by android.widget.TextView{...}
during layout: running second layout pass
message in your console.
This bug must have been introduced in one of the KitKat (4.4.x) updates, as I've not seen it with the initial KitKat (4.4.0) release. Apart from the ugly console spamming with the debug message from above, there seem to be no other impacts (maybe performance in some cases, which I haven't tested).
Cheers
PS: it's not the first time that the fast scroll feature is bugged, e.g. https://code.google.com/p/android/issues/detail?id=63545, 63545 was fixed in KitKat 4.4.3 but 75516 poped up thereafter --> seems to be a vexed subject for google ;-)
EDIT May 12 2015:
I updated my Nexus 7 to Android 5.1 some minutes ago (was Running 5.0 before) and stopped seeing this issue in this new version. As the appearance of the FastScroll indicator also changed in 5.1, I assume that google fixed this issue or at least commented out those ugly lines that spammed the console...
75516 & 82461 are still 'unresolved', but I guess that those refer to the same issue, that's now resolved in 5.1.

The problem is that while the method getView() of your adapter is displaying your layout some other code is trying to access this view to display it, resulting in a collision.
Note that some methods, that maybe you don't take care of (like setScale(), setTypeFace()) indeed call requestLayout(), so it would be interesting what you are doing after your inflate statement.

For me this issue was occurring upon a setLayoutParams() call. The solution was posting a runnable on the looper:
// java
imageView.post(new Runnable() {
#Override public void run() {
imageView.setLayoutParams(params);
}
});
// kotlin
post(Runnable { imageView.setLayoutParams(params) })

I fixed this issue by disabling fastScroll on the ListView in the XML.
<ListView
android:id="#+id/mListview"
android:layout_width="wrap_content"
android:layout_height="match_parent"
android:fastScrollEnabled="false"
/>

In my case (Samsung Galaxy S4, API 21) this happened in ListView with EditTexts. I have a listener for field validation. Something like:
edit.setOnFocusChangeListener(new View.OnFocusChangeListener() {
public void onFocusChange(View v, boolean hasFocus) {
if (hasFocus) {
error.setVisibility(View.INVISIBLE);
error.setText("");
} else {
String s = edit.getText().toString();
if (s.isEmpty()) {
error.setText("Error 1");
} else if (s.length() < 2 || s.length() > 100) {
error.setText("Error 2");
}
error.setVisibility(View.VISIBLE);
}
}
});
After settinging focus in one of these EditTexts an above check is called. After that a TextView will change (the TextView contains an error message and lies over the EditText).
Setting focus to the second or the third EditText led to permanent request of the first EditText and return to current. An applications runs in infinite loop of requests (focus edittext 1, unfocus edittext 1, focus 3, unfocus 3, focus 1, etc).
I tried to set listView.setFastScrollEnabled(false). Also I tried a requestLayout() of some elements like in https://github.com/sephiroth74/HorizontalVariableListView/issues/93 with no chances.
Currently I made that TextView of fixed width and height in XML:
<TextView
android:id="#+id/error"
android:layout_width="match_parent" (or "200dp", but not "wrap_content")
android:layout_height="20dp"
.../>
After some experiments I noticed that a height of 20dp can be replaced with "wrap_content". But if a text is too long that divides into 2 lines, the application again catches in the infinite loop. So, android:singleLine="true" will help. It is deprecated, but amazingly android:maxLines="1" with android:lines="1" don't help as they again request layout.
Eventually we have:
<TextView
android:id="#+id/error"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:singleLine="true"
android:textColor="#f00"
android:textSize="20sp"
tools:text="Error message"/>
That's not a good solution, but at least it breaks the infinite loop.

This might happen if you are using some 3rd party extension of ListView. Replace that with standard ListView and check if it still throws the error.
I had similar problem. Please check Android layout: running second layout pass and my answer.

I had the same issue with Kitkat 4.4.4 on Motorola X with Genymotion. In my case the list item is a simple CheckedTextView and the error occurred in AppCompatCheckedTextView.
As a normal implementation I inflated the item from XML layout file like below:
if (convertView == null) {
convertView = inflater.inflate(R.layout.checkable_list_entry, parent, false);
}
After some trying I found out that this has something to do with XML inflation. I don't know the root cause, but as a solution I decided to inflate the list item by code and set all the properties by code too.
It ended up like this:
CheckedTextView view;
if (convertView == null) {
view = new CheckedTextView(parent.getContext());
view.setMinHeight(getResources().getDimensionPixelSize(R.dimen.default_touch_height));
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
view.setTextAppearance(R.style.SectionEntry);
} else {
view.setTextAppearance(parent.getContext(), R.style.SectionEntry);
}
view.setBackgroundResource(R.drawable.form_element);
view.setGravity(Gravity.LEFT | Gravity.CENTER_VERTICAL);
view.setLayoutParams(new AbsListView.LayoutParams(AbsListView.LayoutParams.MATCH_PARENT, AbsListView.LayoutParams.WRAP_CONTENT));
} else {
view = (CheckedTextView) convertView;
}

I had a problem with the same warning log :
requestLayout() improperly called by android.support.v7.widget.AppCompatTextView {...} during layout: running second layout pass
I was working with recylcerview and going to update it with new data.
The only solution that worked for me is as below :
Step(1). Remove current data :
public void removeAll() {
items.clear(); //clear list
notifyDataSetChanged();
}
Step(2). When you want to populate the recyclerview with new data, first set a new LayoutManager to recyclerview again:
private void initRecycleView() {
recyclerView.setHasFixedSize(true);
recyclerView.setLayoutManager(new LinearLayoutManager(activity, LinearLayoutManager.VERTICAL, false));
}
Step(3). Update the recyclerview with new data. for example :
public void refreshData(List newItems) {
this.items = newItems;
notifyItemRangeChanged(0, items.size());
}

Try taking off the textSize from the xml and setting it in Java code. I think that's causing it to be laid out twice.

In my case this warning prevented a button from showing up in API 21 devices. The button visibility was previously set to GONE.
The only workaround I got it was setting to INVISIBLE instead of GONE for API 21. It wasn't a real solution but it was acceptable for me.
I only post this because it can be useful from somebody.
if (Build.VERSION.SDK_INT == Build.VERSION_CODES.LOLLIPOP) {
theButton.setVisibility(View.INVISIBLE);
}
else {
theButton.setVisibility(View.GONE);
}

Sometimes you maybe already fixed the issue but it still keeps same error, so you need to close visual studio then delete all bin and obj folders from your projects, then uninstall the app from the emulator. then walah!! everything will works fine

I solved the problem like this:
mHolder.txt_fword.setTextSize(22);
mHolder.txt_farth.setTextSize(22);
mHolder.txt_fdef.setTextSize(22);
mHolder.txt_fdef2.setTextSize(22);
mHolder.txt_frem.setTextSize(22);
//if (fdef2.get(pos).equals("")) mHolder.txt_fdef2.setVisibility(View.GONE);
//if (frem.get(pos).equals("")) mHolder.txt_frem.setVisibility(View.GONE);
issue is .setVisibility(View.GONE); , change to .setVisibility(View.VISIBLE);

Strange XML layout bug when targeting Android 4.3

I'm experiencing a really peculiar bug with an XML layout file when building my application while targeting API level 18. It doesn't happen with API level 17. I'm running the application on Android 4.3 devices, and the bug persists on all three devices.
Here's what it looks like:
API 17 (correct):
API 18 (incorrect):
I'm using the StickyGridHeaders library, and the following is my getHeaderView() method:
#Override
public View getHeaderView(int position, View convertView, ViewGroup parent) {
RowItem holder;
if (convertView == null) {
convertView = inflater.inflate(R.layout.seasons_row_header, parent, false);
holder = new RowItem();
holder.title = (TextView) convertView.findViewById(R.id.seasonTitle);
holder.episodeCount = (TextView) convertView.findViewById(R.id.episodeCount);
convertView.setTag(holder);
} else {
holder = (RowItem) convertView.getTag();
}
if (seasons.get(position).equals("00")) {
holder.title.setText(R.string.stringSpecials);
} else {
holder.title.setText(getString(R.string.showSeason) + " " + seasons.get(position));
}
int size = seasonEpisodeCount.get(Integer.valueOf(seasons.get(position)));
holder.episodeCount.setText(size + " " + getResources().getQuantityString(R.plurals.episodes, size, size));
convertView.setClickable(false);
convertView.setFocusable(false);
return convertView;
}
Here's the layout XML file:
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:background="#80000000"
android:padding="#dimen/list_padding" >
<TextView
android:id="#+id/seasonTitle"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_alignParentLeft="true"
android:layout_marginRight="#dimen/list_padding"
android:layout_toLeftOf="#+id/episodeCount"
android:textAppearance="?android:attr/textAppearanceMedium"
android:textIsSelectable="false"
android:textStyle="bold" />
<TextView
android:id="#+id/episodeCount"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_alignBottom="#+id/seasonTitle"
android:layout_alignParentRight="true"
android:layout_alignTop="#+id/seasonTitle"
android:gravity="bottom"
android:textAppearance="?android:attr/textAppearanceSmall"
android:textIsSelectable="false" />
</RelativeLayout>
Does anyone else have a clue as to what's going on here? I find it really strange that it's working when targeting API level 17 and not working when targeting the latest API level (18).
Update:
This is what it looks like in the visual layout editor with Android 4.3 as the target:

I managed to solve the issue myself.
Like I said, I am using the StickyGridHeaders library and referencing it in my application. It appears that the library was targeting API level 17. I changed it to level 18, compiled and ran the application - great success!
In conclusion: Make sure your application and libraries target the same API level.

I have the same issue, too.
My experiences have shown that crossed alignments are the reason of the problem (TextView #+id/seasonTitle has the property android:layout_toLeftOf="#+id/episodeCount"; TextView #+id/episodeCount has the properties android:layout_alignBottom="#+id/seasonTitle" and layout_alignTop="#+id/seasonTitle". One of the Layouts won't refresh its childs correct.
Changing the Layout-XML that crossed alignments are prevented, you no longer have this problem.

I have the same issue :
a ListView with a white background
each child has a View with a gray background and width and height to match_parent, within a RelativeLayout
on API 17, every is OK
on API 18+, the ListView is white
instead of setting a fixed height, I put a min_height to the View, and the problem is (temporary) solved!
hope it helps