Currently working on an issue in our application where a dependency is reading the state of night mode from the Activity (i.e. activity.getResources().getConfiguration().uiMode & Configuration.UI_MODE_NIGHT_MASK). The Activity in question is configured with android:configChanges="uiMode" and I am seeing that the state of night mode never changes from light when reading from the Activity.
However the value is correct when reading from the Application (i.e. activity.getApplicationContext().getResources().getConfiguration().uiMode) and it is also correct in the Configuration object passed to onConfigurationChanged.
Unfortunately since its a dependency that is using the night mode value fixing my issue by simply using either of the objects that give the expected value isn't the simplest solution, so I would prefer to fix the root cause. Kind of at a loss for what is going wrong and I haven't been able to find why these values are differing.
Related
There is N old projects for API 13-14, on eclipse(juno)+adt. All projects are compiling, working, etc.
After import (one of) them into Android Studio, its also good compiling, but...
Using of startActivityForResult immediatelty destroys parent(main) activity, if dev flag do not store is on. If flag is off, all working good. Is normal, but...
original eclipse project is working good (not destroys parent immediately) in all states of dev flag.
I think there is a difference of defaut processing in each case or may be something expected in manifest?
It may be because the parent has openGl context, but eclipse project works good...
The parent activity gets too many different data (used to monitoring a real time signal) and destroing it is very bad for me.
There is only one question - why this fatal difference is, and how to avoid this?
Reload state manually in (onSaveState) is too complex and not correct.
I'm using Android Studio to debug class field, the things I want to know is:
who and when changed the variable. But it seems that it doesn't work like a regular break point, whenever the field gets changed my application just stops and there is not such option as Step Over or Resume Program in debug window. My tool bar looks unusable:
So, as you can see from the Overhead the field was hit once, and my application stopped afterwards. Also it doesn't show who changed a variable, or how it was changed(via setter or from inside class). How can I make it work?
Both "Add watchpoint" and adding breakpoints every time value is updated almost did the trick.Actually, None of the breakpoints were triggered at all, but it led me to conclusion that the application was not using the correct object at all, and yes, the hashcodes of used object and the object that application
should have used were different, should be more carefull with singleton :)
I'm having a bizarre transparency issue with my app on Android Lollipop (and only Android Lollipop).
Steps:
Uninstall any previous versions of my app.
Install the app.
Notice weird transparency on some fragments in my app (full-screen dialog, a fragment we slide in, our pull-to-refresh code).
Build a new binary with no code changes and install on the phone as an update.
Fragments all look fine.
Steps 1-3 I understand -- maybe some material theme is being applied inconsistently, or there's an issue with the custom themes we use in our app.
But I don't understand why re-deploying to the phone fixes the problem.
I'm seeing this on an unmodified Nexus 5 that got the Lollipop update over the air. I see the same issue on the Lollipop emulator.
I've tried changing our targetSdk from 19 to 21 and it did not help. minSdk remains at 15.
Has anyone seen an issue like this and can hopefully point me in a direction to debug?
Edit: Clearing data causes the transparency to return. Force-stopping the app and restarting it fixes the transparency issue. So I think cybersam is on the right track with his answer below -- there's some kind of issue in bootstrapping. But the fragments in question use #android/color:black and #color/my_app_black (= #FF000000) as their background colors, so I don't think the issue is in my app-specific code.
There is not enough information to say for sure what is going on, but I can see one scenario that can cause this. It may be totally unrelated to your situation, but here it is, anyway:
(1) You normally depend on persistent data (e.g., stored in shared preferences, DBs, files, etc.) to determine how to display your background, and have a bug where you: (a) look for the persistent data, (b) see it's not there and use an inappropriate default value (e.g., null) instead, and (c) go on to display strange backgrounds due to the bad default value.
(2) However, you also have special code that detects the missing persistent data and initializes it with appropriate values. But that special code has a bug in that it does not update your in-memory state to match the stored values.
With the above situation, during a fresh install (and as long as the app is not killed by the system and then re-started), you would continue to use the bad data and see the bad backgrounds. During a re-installation (where you did not uninstall the app first), the system would kill your app and then re-install it without deleting its persistent data. Therefore, on a re-installation, bug (1) would not be hit and you would see the expected backgrounds.
Not really an answer, but adding a values-v21 and changing my black color to #010101 works fine. I have no idea what the issue is. Seems like an obscure theme misuse or an obscure platform bug.
How do I avoid reloading the activity with asynctask class in activity when the user changes orientation, in android? Can anybody give an example?
Please turn off config changes as a last resort. Your app must work correctly when this happens. If you turn off the orientation config change because it breaks, your app will still break in other and some times more subtle way. Allowing the activity to be restarted due to an orientation config change is a very good way to easily test these important code paths of your app that are otherwise much less often exercised but still will result in failures in your users' hands.
To transfer active objects across Activity instances, use the new fragment static library which allows you to make a fragment that is retained for you across instances.
Chirag have already correctly pointed out the solution.
I just want to add that, restart of Activity has nothing to do with the AsyncTask in it. By default, when there are any config changes,the activity is restarted UNLESS the config change is explicitly handled by the Activity. This is done by making an entry in manifest file.
Go through this link developer guide : android:configChanges
NOTE: Check the code on a device not on emulator. Because I had faced similar problem earlier. The same code didn't worked on emulator but it worked on device perfectly. So add the entry for android:configChanges in manifest and check the application on a android device instead of emulator.
And I second #hackbod. Do it only if necessary!
I would like to know how works a turn of Android device (from the point of view of the OS). I'm interested in this action, because my Android program can not save and RIGHT restore its state after any turn of device (I use it with OnSave... and OnRestore... methods), I've learned almost all tutorials, but in spite of that, I can't find the mistake. Thank you.
A very detailed information on this matter is located in Android documentation here.
You most likely need this section:
Retaining an Object During a Configuration Change