I've seen this question:
Changing the ActionBar hide animation?
But it doesn't say whether it's possible to disable animation altogether.
You can now do this,
getSupportActionBar().setShowHideAnimationEnabled(false);
I fixed using the below method:
public static void disableShowHideAnimation(ActionBar actionBar) {
try
{
actionBar.getClass().getDeclaredMethod("setShowHideAnimationEnabled", boolean.class).invoke(actionBar, false);
}
catch (Exception exception)
{
try {
Field mActionBarField = actionBar.getClass().getSuperclass().getDeclaredField("mActionBar");
mActionBarField.setAccessible(true);
Object icsActionBar = mActionBarField.get(actionBar);
Field mShowHideAnimationEnabledField = icsActionBar.getClass().getDeclaredField("mShowHideAnimationEnabled");
mShowHideAnimationEnabledField.setAccessible(true);
mShowHideAnimationEnabledField.set(icsActionBar,false);
Field mCurrentShowAnimField = icsActionBar.getClass().getDeclaredField("mCurrentShowAnim");
mCurrentShowAnimField.setAccessible(true);
mCurrentShowAnimField.set(icsActionBar,null);
}catch (Exception e){
//....
}
}
}
If you use ActionBarSherlock then you can do it. See ActionBarImpl class, it has setShowHideAnimationEnabled(boolean enabled) method.
Related
I am trying billow Code from this answer to check if the permission is enabled. but it is returning false even when the permission is enabled from the settings.
public static boolean canDrawOverlayViews(Context con){
if(Build.VERSION.SDK_INT< Build.VERSION_CODES.LOLLIPOP){return true;}
try {
return Settings.canDrawOverlays(con);
}
catch(NoSuchMethodError e){
return canDrawOverlaysUsingReflection(con);
}
}
public static boolean canDrawOverlaysUsingReflection(Context context) {
try {
AppOpsManager manager = (AppOpsManager) context.getSystemService(Context.APP_OPS_SERVICE);
Class clazz = AppOpsManager.class;
Method dispatchMethod = clazz.getMethod("checkOp", new Class[] { int.class, int.class, String.class });
//AppOpsManager.OP_SYSTEM_ALERT_WINDOW = 24
int mode = (Integer) dispatchMethod.invoke(manager, new Object[] { 24, Binder.getCallingUid(), context.getApplicationContext().getPackageName() });
return AppOpsManager.MODE_ALLOWED == mode;
} catch (Exception e) { return false; }
}
Recently I've also faced the same issue and got the following workaround .
Referenced from
https://code.google.com/p/android/issues/detail?id=198671#c7
public boolean getWindoOverLayAddedOrNot2() {
String sClassName = "android.provider.Settings";
try {
Class classToInvestigate = Class.forName(sClassName);
if (context == null)
context = activity;
Method method = classToInvestigate.getDeclaredMethod("isCallingPackageAllowedToDrawOverlays", Context.class, int.class, String.class, boolean.class);
Object value = method.invoke(null, context, Process.myUid(), context.getPackageName(), false);
Log.i("Tag", value.toString());
// Dynamically do stuff with this class
// List constructors, fields, methods, etc.
} catch (ClassNotFoundException e) {
// Class not found!
} catch (Exception e) {
// Unknown exception
e.printStackTrace();
}
return false;
}
does the check involves the device admin?
I have encountered this problem when disabling device admin, I have checked this permission in the DeviceAdminReceiver->onDisabled() and on some devices, and canDrawOverlays returned false, despite the fact i had the permission.
The above answer helped sometimes but not all the time. the thing that did work is Thread.sleep before the check.
try {
Thread.sleep(20);
} catch (InterruptedException e) {
// some exception here
}
The minimal time that worked for me was 20 millis. than canDrawOverlays returned true
Note: this is not a good practice however this is the only thing that worked for me
Based on BennyP's answer, I've made a Runnable run the required code after 500ms and that worked very well. The feedback is a bit delayed, but the user won't even notice the delay.
This is the code I've added to my onResume()
Handler handler = new Handler();
handler.postDelayed(new Runnable() {
#Override
public void run() {
if(!Settings.canDrawOverlays(ControllerActivity.this)){
//Handle overlay permission not given here
}
else{
//Handle overlay permission given here
}
}
}, 500);
Hope it helps!
I tried restarting the activity after the user accessed the setting . This is code :
public static void restartActivity(Activity act){
Intent intent = getIntent();
finish();
startActivity(intent);
}
First of all, I am really very surprised with this strange behaviour of
Settings.canDrawOverlays(this);
I also faced the same issue with its usage, it was returning false even if the permission is already assigned.
What I noticed that, I was using this check in my onStart() method, where it was creating this wired behavior. To resolve this, I searched over internet and no result was there that can satisfy me and the one I can use.
Solution
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
Log.e("Overlay Permission", "" + Settings.canDrawOverlays(this));
if (!Settings.canDrawOverlays(this)) {
MyPreferences.saveBoolean(HomeScreen.this, "showOverlayPermissionDialog", true);
} else {
MyPreferences.saveBoolean(HomeScreen.this, "showOverlayPermissionDialog", false);
}
}
I did something lake this, in my onCreate(). Here I saved the values accordingly in my SharedPreferences, and according to these Shared Preference values, I created a check for showing an overlay dialog in my onStart(). This worked fine!
You can try this solution, and mark this answer useful if your problem is solved.
Thanks
If you call AbsListView.setItemChecked() directly, it works well, and the ActionMode will activate and create.
mGridView.setItemChecked(pPosition, true);
But when you call View.startActionMode() first, then call AbsListView.setItemChecked(), the ActionMode create by startActionMode() will destroy, and recreate a new one by setItemChecked().
My question is: How to avoid this issue when call View.startActionMode() first?
Looking forward to your reply! Thanks!
Why recreate a new one? See the source code of AbsListView.setItemChecked(int position, boolean value) method, you can see following code:
// Start selection mode if needed. We don't need to if we're unchecking something.
if (value && mChoiceMode == CHOICE_MODE_MULTIPLE_MODAL && mChoiceActionMode == null) {
if (mMultiChoiceModeCallback == null ||
!mMultiChoiceModeCallback.hasWrappedCallback()) {
throw new IllegalStateException("AbsListView: attempted to start selection mode " +
"for CHOICE_MODE_MULTIPLE_MODAL but no choice mode callback was " +
"supplied. Call setMultiChoiceModeListener to set a callback.");
}
mChoiceActionMode = startActionMode(mMultiChoiceModeCallback);
}
That means if mChoiceActionMode == null, it will call startActionMode(mMultiChoiceModeCallback), so will recreate a new ActionMode.
And how to fix?
Here is a simple way: use reflect to assign a ActionMode create by startActionMode() to the private field mChoiceActionMode in AbsListView.
private void startActionMode() {
// Get the field "mMultiChoiceModeCallback" instance by reflect
AbsListView.MultiChoiceModeListener wrapperIns = null;
try {
Field wrapper = null;
wrapper = AbsListView.class.getDeclaredField("mMultiChoiceModeCallback");
wrapper.setAccessible(true);
wrapperIns = (AbsListView.MultiChoiceModeListener) wrapper.get(mMessageGridView);
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (NoSuchFieldException e) {
e.printStackTrace();
}
// Start the ActionMode, but not select any item.
ActionMode actionMode = mMessageGridView.startActionMode(wrapperIns);
// Assign actionMode to field "mChoiceActionMode" by reflect
try {
Field mChoiceActionMode = null;
mChoiceActionMode = AbsListView.class.getDeclaredField("mChoiceActionMode");
mChoiceActionMode.setAccessible(true);
mChoiceActionMode.set(mMessageGridView, actionMode);
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (NoSuchFieldException e) {
e.printStackTrace();
}
}
Why here we use wrapper? Because AbsListView.setMultiChoiceModeListener(MultiChoiceModeListener listener) will wrap our mMultiChoiceModeListener, so we can't not use directly.
I have a NumberPicker that has a formatter that formats the displayed numbers either when the NumberPicker spins or when a value is entered manually. This works fine, but when the NumberPicker is first shown and I initialize it with setValue(0) the 0 does not get formatted (it should display as "-" instead of 0). As soon as I spin the NumberPicker from that point on everything works.
How can I force the NumberPicker to format always - Both on first rendering and also when I enter a number manually with the keyboard?
This is my formatter
public class PickerFormatter implements Formatter {
private String mSingle;
private String mMultiple;
public PickerFormatter(String single, String multiple) {
mSingle = single;
mMultiple = multiple;
}
#Override
public String format(int num) {
if (num == 0) {
return "-";
}
if (num == 1) {
return num + " " + mSingle;
}
return num + " " + mMultiple;
}
}
I add my formatter to the picker with setFormatter(), this is all I do to the picker.
picker.setMaxValue(max);
picker.setMinValue(min);
picker.setFormatter(new PickerFormatter(single, multiple));
picker.setWrapSelectorWheel(wrap);
dgel's solution doesn't work for me: when I tap on the picker, formatting disappears again. This bug is caused by input filter set on EditText inside NumberPicker when setDisplayValues isn't used. So I came up with this workaround:
Field f = NumberPicker.class.getDeclaredField("mInputText");
f.setAccessible(true);
EditText inputText = (EditText)f.get(mPicker);
inputText.setFilters(new InputFilter[0]);
I also encountered this annoying little bug. Used a technique from this answer to come up with a nasty but effective fix.
NumberPicker picker = (NumberPicker)view.findViewById(id.picker);
picker.setMinValue(1);
picker.setMaxValue(5);
picker.setWrapSelectorWheel(false);
picker.setFormatter(new NumberPicker.Formatter() {
#Override
public String format(int value) {
return my_formatter(value);
}
});
try {
Method method = picker.getClass().getDeclaredMethod("changeValueByOne", boolean.class);
method.setAccessible(true);
method.invoke(picker, true);
} catch (NoSuchMethodException e) {
e.printStackTrace();
} catch (IllegalArgumentException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
}
Calling that private changeValueByOne method immediately after instantiating my number picker seems to kick the formatter enough to behave how it should. The number picker comes up nice and clean with the first value formatted correctly. Like I said, nasty but effective.
I had the same problem and I used the setDisplayedValues() method instead.
int max = 99;
String[] values = new String[99];
values[0] = “-” + mSingle
values[1] =
for(int i=2; i<=max; i++){
makeNames[i] = String.valueOf(i) + mMultiple;
}
picker.setMinValue(0);
picker.setMaxValue(max);
picker.setDisplayedValues(values)
This doesn't allow the user to set the value manually in the picker though.
The following solution worked out for me for APIs 18-26 without using reflection, and without using setDisplayedValues().
It consists of two steps:
Make sure the first element shows by setting it's visibility to invisible (I used Layout Inspector to see the difference with when it shows, it's not logical but View.INVISIBLE actually makes the view visible).
private void initNumberPicker() {
// Inflate or create your BugFixNumberPicker class
// Do your initialization on bugFixNumberPicker...
bugFixNumberPicker.setFormatter(new NumberPicker.Formatter() {
#Override
public String format(final int value) {
// Format to your needs
return aFormatMethod(value);
}
});
// Fix for bug in Android Picker where the first element is not shown
View firstItem = bugFixNumberPicker.getChildAt(0);
if (firstItem != null) {
firstItem.setVisibility(View.INVISIBLE);
}
}
Subclass NumberPicker and make sure no click events go through so the glitch where picker elements disapear on touch can't happen.
public class BugFixNumberPicker extends NumberPicker {
public BugFixNumberPicker(Context context) {
super(context);
}
public BugFixNumberPicker(Context context, AttributeSet attrs) {
super(context, attrs);
}
public BugFixNumberPicker(Context context, AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
}
#Override
public boolean performClick() {
return false;
}
#Override
public boolean performLongClick() {
return false;
}
#Override
public boolean onInterceptTouchEvent(MotionEvent event) {
return false;
}
}
Here's my solution based on answers by torvin and Sebastian. You don't have to subclass anything or use reflection.
View editView = numberPicker.getChildAt(0);
if (editView instanceof EditText) {
// Remove default input filter
((EditText) editView).setFilters(new InputFilter[0]);
}
Calling the private method changeValueByOne() via reflection as described in an earlier answer works for me on API Level 16 (Android 4.1.2 and up), but it does not seem to help on API Level 15 (Android 4.0.3), however!
What works for me on API Level 15 (and up) is to use your own custom formatter to create String array and pass that with the method setDisplayedValues() to the number picker.
See also: Android 3.x and 4.x NumberPicker Example
The answer provided by NoActivity worked for me but I only had to do:
View firstItem = bugFixNumberPicker.getChildAt(0);
if (firstItem != null) {
firstItem.setVisibility(View.INVISIBLE);
}
to fix the issue. I did not need to subclass NumberPicker. I did not see the issue where picker elements disappear on touch.
Kotlin version based on Nikolai's answer
private fun initNumberPicker() {
nrPicker.children.iterator().forEach {
if (it is EditText) it.filters = arrayOfNulls(0) // remove default input filter
}
}
I managed to fix it by calling
picker.invalidate();
just after setting the formatter.
Improved Nikolai answer if selected index is not 0. Not to great for performances but fix the problem..
for(index in numberPicker.minValue..numberPicker.maxValue) {
val editView = numberPicker.getChildAt(index-numberPicker.minValue)
if (editView != null && editView is EditText) {
// Remove default input filter
(editView as EditText).filters = arrayOfNulls(0)
}
}
Now, I try to hide the softkeyboard when user touch outside the keyboard:
((InputMethodManager) getSystemService(INPUT_METHOD_SERVICE))
.hideSoftInputFromWindow(editView.getWindowToken(),
InputMethodManager.HIDE_NOT_ALWAYS);
I want put the logic in my base activity class, so if it is possible to getWindowToken without View?
I faced exactly the same problem, while writing OnPageChangeListener within an Activity. You can use one of these solutions. Either:
getWindow().getDecorView().getRootView().getWindowToken()
or:
findViewById(android.R.id.content).getWindowToken()
Surely you can use:
getContentView().getWindowToken()
or you can refer to SO Quest
Simply use getWindow().getDecorView().getWindowToken()
public static final String M_TOKEN = "mToken";
#Nullable
protected IBinder getToken(Activity activity) {
try {
Field mTokenField = Activity.class.getDeclaredField(M_TOKEN);
mTokenField.setAccessible(true);
IBinder mToken = (IBinder) mTokenField.get(activity);
return mToken;
} catch (NoSuchFieldException e) {
// handle
} catch (IllegalAccessException e) {
// handle
}
return null;
}
You could just get the token from the WindowManager.LayoutParams of the window directly
getWindow().getAttributes().token
In kotlin:
val imm = getSystemService(Context.INPUT_METHOD_SERVICE) as InputMethodManager
imm.hideSoftInputFromWindow(window.attributes.token, 0)
Or, If you have a view:
imm.hideSoftInputFromWindow(view.windowToken, 0)
You can try this on your manifest file activity tag to hide keyboard.
android:windowSoftInputMode="stateHidden"
I have a basic TabActivity. On android 2.1 (and possibly older versions), it looks like a drop shadow is added below the tab widget. On 2.3, this shadow is not present. Is there a way to turn that shadow off completely? Maybe something like "android:fadingEdgeLength=0" ?
Thanks
Are you talking about the white strip? I've hacked past this by calling this method inside onTabChanged
Let you class implement OnTabChangeListener
private static TabHost mTabHost;
#Override
protected void onCreate(Bundle savedInstanceState) {
// Instantiate your tab host normally
}
#Override
public void onTabChanged(String tabId) {
removeWhiteStrip(mTabHost);
}
/**
* Hack
* #param tabHost
*/
private static void removeWhiteStrip(TabHost tabHost) {
TabWidget tw = (TabWidget) tabHost.getChildAt(1);
Field mBottomLeftStrip;
Field mBottomRightStrip;
try {
mBottomLeftStrip = tw.getClass().getDeclaredField("mBottomLeftStrip");
mBottomRightStrip = tw.getClass().getDeclaredField("mBottomRightStrip");
if (!mBottomLeftStrip.isAccessible()) {
mBottomLeftStrip.setAccessible(true);
}
if (!mBottomRightStrip.isAccessible()) {
mBottomRightStrip.setAccessible(true);
}
// This is a blank drawable basically a 1x1 png with 100% alpha
mBottomLeftStrip.set(tw, MyApp.getInstance().getResources().getDrawable(R.drawable.blank));
mBottomRightStrip.set(tw, MyApp.getInstance().getResources().getDrawable(R.drawable.blank));
}
catch (java.lang.NoSuchFieldException e) {
// possibly 2.2
try {
Method stripEnabled = tw.getClass().getDeclaredMethod("setStripEnabled", boolean.class);
stripEnabled.invoke(tw, false);
}
catch (Exception e1) {
e1.printStackTrace();
}
}
catch (Exception e) {
// tut tut shouldn't catch generic exception and ignore it
// but we do because this is a hack
}
}
Enjoy