When there is a configuration change, such as uiMode, Locale, etc., the fragments are not restored correctly. Then simply put the application in the background, and then return to the foreground, and everything is restored.
The problem does not arise in a systematic way, but without a rule, it does not arise until version 10 of Android. Apparently it also depends on the devices, for example with two different brands of phones, with Android 11 installed, on one it will happen and on another it will not happen.
In the attached video you can see the problem when it occurs.
https://drive.google.com/file/d/1nRXG9fqttc8TtTL4tLF0o8haru8A1YNg/view?usp=drive_web (Screen_Recording_20220530-231647_Call Blocker - Phone.mp4)
Related
Since upgrading to Nougat, there are some situations when my app's UI is completely unresponsive to touches on my Nexus 5x even though all views are drawn and contain the correct contents; only the Back or Home key are effective to dismiss it. There have been a few rare occasions where it does work on my 5x, and there is also no problem with it working on an emulated 5x, which of course has no other 3rd-party apps installed, etc.
Since this app has worked flawlessly in this respect since its original release on Android 2.3, obviously something has changed. What I suspect is some sort of race condition during initialization, but I don't know where to start to figure out what is happening.
What is it that could be disabled so as to make the app's UI visible but unresponsive? Is there a place that I could insert a break or logging statement, or just look at settings to figure out what's happening?
I have an Android app in the Play Store. In the last couple of days I've started getting bug reports about "black blocks in the settings screen". Unfortunantely I haven't been able to reproduce the bug on my devices, so everything I know comes from user reports.
I've got the following screenshots from a helpful user:
http://madscientist.pl/temp/bug0.png
http://madscientist.pl/temp/bug1.png
There's supposed to be white text on the tab headers, on the buttons and next to the radio buttons and seek bars. There should also be white horizontal lines separating the options.
The sizes of those black boxes that are visible (the rest is on the black background) correspond to the sizes of letters that are supposed to be there. The text on the two columns of buttons reads "Save" and "Load".
My app can be opened in two modes: live wallpaper and as a "regular app". The problem apparently exists in both versions.
Almost all bug reports describe another characteristic: the settings screen sometimes works correctly and sometimes it doesn't. E.g., sometimes opening the settings activity of the live wallpaper for the second time fixes the problem.
Another person wrote that it works correctly on the first application run only. After that, he has to clear the app data and then again it fails on the second run. So it seems that the bug manifests itself rather unpredictably.
I admit to not being a very good dev and that all the text is put directly in the layout files instead of in strings.xml. It was never an issue before, but just in case I'm in the process of establishing if putting the strings in strings.xml helps with one of the users.
The problem seems to be independent of the device. I've got reports from Samsung, Motorola, LG and Nexus users.
From what I've established so far, for at least one of the users the problem happens on both current and previous version of my app. The previous version was in the store since January 2015. The current version is a month old. I've been getting bug reports for just over a week now so this doesn't seem to be (directly) caused by some change I made to the app.
This led me to believe that the new Android version that has been rolling out recently (at least I've got 5.1 a week ago) is the reason. However I've got bug reports from a user who runs the app on 5.0.2 and 4.4.4.
The app is moderately popular and has a stable amount of downloads, so the fact that in the last week I've got a dozen reports of this bug, and before that I've never heard of it, leds me to believe that it indeed started happening over a week ago. So apart from the bug itself, it's really beyond my understanding what made it appear just now, if neither application update nor system update seem to be related.
I could provide more data, but the question is already terribly long. Let me know what else you think could be helpful.
I have incredibly hard problem to pinpoint.
I have a project which is not really important here (actually tested it on other project, same thing, and also on another computer, same thing) with typical hierarchy. Within it I use custom views, and also use custom views from my external library (which initially thought is the cause, but it isn't as the same thing happens with custom views within src of the same project). I use some of those custom views inside my xml's defining views. I had a need to debug some operations going on within one of those custom view classes. So I set couple breakpoints, ran the project, and when the runtime hit them I saw this screen:
As you see the debugging is broken although the breakpoint is hit on exact line I put it. I cannot do anything here though, except resuming it or terminating it. All the "step in/out" options are greyed out, and the stack trace for the main thread is literaly gone.
This happens on the Galaxy S4 (i9500) that I aquired lately. I cannot say for certain, but I'm pretty sure on my previous Galaxy S+ (i9001) it did not happen.
More information for you:
My i9500 is rooted with custom kernel flashed. The DDMS screen also does not show any processes that are going on on my device (was deffinetly showing on galaxy s+ I had before):
As you see, the processes are being shown just fine inside an emulator, but there are no processes (the application process for the project, after I run it is being shown there, but nothing else).
As for emulator, same machine (tested on both), same environment, same projects, and no problems with debugging it whatsoever:
As you see, everything is perfect over here.
Another important information is that it only happens (from what I see) when xml views are being processed. When I create a reference to one of my custom views manually, debugging works as expected on both the emulator, and the device. So far, it only happens when the breakpoint is being hit when the xml view is being processed.
The last piece of information is that my Device Chooser when I deploy application, shows empty space inside the Debug column. I don't know if it's relevant or not.
I've lost almost 5 hours now looking for solution of this problem (and the cause) on the web, without any luck.
From all the circumstances, it seems the problem is with galaxy s4 I have, not with the computer, or the IDE, or the project itself, but the question is, what is the problem. Tried reinstalling samsung drivers, tried uninstalling those and installing PDA.net drivers alone. No help.
If anybody of you will be able to figure out this puzzle, you are God. Besides that, you will have my deepest gratitude, as this issue is driving me nuts.
ps. I have all the android SDK's up to date, and eclipse plugin as well.
Half the answer (so far).
Upon updating to new 4.3 update, and new custom kernel (Perseus Kernel alfa 14), the DEBUG flag is shown in the Device Chooser dialog screen, and is set to YES. Also, the processes are now visible in DDMS.
Unfortunetly, still the stack is empty once the breakpoints are hit in the custom views.
I do have a problem and have very little to go on. I'm about to release an App (created with Air for Android As3) on the Samsung App Store and just got a list of issues that have to be resolved after the app has been tested by samsung staff before the app could be released.
I did manage to solve almost all of the issues, but 1 very important one is beyond me. They say the screen turns/stays black, when returning after the device alarm interrupted the app. This issue practivally happend on all their devices, including a group including the phones I own (e.g. Galaxy S3).
I do have "OnDeActivate" and "OnActivate" listeners in place that are there to pause the app, disable sound etc. if it loses focus, gets minimized etc., yet I checked on my devices and I can't reproduce this error. Meaning if the app gets interrupted on my device by the alarm, I can resume it without any problems. no black screens.
So the question is: Is there any way for me to fix that at all? I do have to work within AirForAndroid AS3 so I guess possibilities are limited. Any clues where I can look? Any listeners to set, or is there a way to maybe "force" the app to reinitialize or refresh the display? Or to listen for the system alarm? Help would be much appreciated. Thanks in advance!
I am trying to overcome the same issue, I read somewhere that setting the stage quality to something else on both the activate and deactivate events might solve the issue.
So just set your stage quality to medium or whatever different in the deactivate and set it back to what it needs to be in the activate.
This should make AIR snap out of that black screen for the alarm (I hope)
An app of mine is with this fix is currently undergoing testing on the Samsung App Store.
I hope it fixes it.
Good news, the dirty fix of toggling the stage quality seems to have worked for Samsung, it has not shown up in their latest certification report of my app.
by the way, this is not for a stage3D app, that's different
It's for a GPU app
When the app loses focus on Android (goes into background) it will lose the context, which among other things mean that you lose all the created graphics, cached objects and like.
You didn't specify what kind of app it is. If you're using Stage3D, that means you'll have to recreate all your textures, and if you're on plain old displaylist, you'll have to recreate any bitmaps that were created at runtime, and redraw your screen at least once (so the vector graphics get redrawn too).
Now, if you're using Starling, for example, it can take care of recreating context for you (there's a flag for enabling that), although you'll still have to recreate dynamically created bitmaps.
Is there any way in Android to determine whether a device is running Sense UI? I'm working on an app that is working fine with vanilla Android, but Sense UI is messing with layouts and sizes. I'd like to be able to see whether the device is running Sense UI and so I can take appropriate action.
There is nothing built into Android that indicates what sorts of modifications like Sense are running on the device. You would either need to use PackageManager to look for HTC Sense components or use the Build class to determine what model device you are on. In either case, you would need to keep updating that "sniffing" logic as Sense is changed and is rolled out to new devices.
but Sense UI is messing with layouts
and sizes
If you have a reproducible test case with source code that demonstrates these problems, I would be interested in seeing it.
There are only two scenarios I can think of that would fit your description:
App widgets may display differently on the HTC Sense home screen, just as they may display differently on other home screens. Ideally, there would be no modification, but since you are running in another app's process, I can't rule it out.
If you rely on android.R resources, those might have been modified by HTC as part of creating Sense, though you can always grab the standard ones from your SDK and ship them with your app.