When I open my activity the screen is just blank...then I see the above error in the log:
01-28 15:19:03.000: D/TiledPage(3366): ERROR: We don't have enough tiles for this page! nbTilesHeight 427575 nbTilesWidth 786344
I am lost as to where I need to go from here. The application has worked fine in the past, now it is just showing a blank screen.
The layout for the activity being displayed is the actionbar and a webview filling the remaining space. Not even the actionbar is appearing, so, I don't think it has to do with the webview specifically.
Any help would be greatly appreciated!
Update:
When I force close the app, and open it again, it works. Obviously, I don't want this to happen when a user is using the application, so, what can I do to prevent it in the future? It would help to know how to find the actual cause.
Do you have hardware acceleration turned on?
You can try turning it off by setting View.setLayerType(View.LAYER_TYPE_SOFTWARE, null);.
This turns off the hardware acceleration just for the view. You can also turn it globally.
Check here for more information on Hardware Acceleration.
Related
again I got a really strange Bug on Android devices for my app with the use of videogular.
I also use a Fullscreen-Plugin, and a plugin for Screen-Orientation to make sure which orientation is in use.
But anyway, the problem now is, that when I play a video and change to "FullScreen"-Mode, go to landscape-mode, and then cancel the Fullscreen-Mode I see my app in the "Ultimate Zoom-Mode" (not real, I only call it in that way). Which means everything is too big and in fact I only see the upper left corner of my app.
That is kind of a strange thing. And I have no idea where it comes from or what I can do against it.
First I fixed the issue by change to landscape mode when the user go to fullscreen. But now I found out, when the user click on the "Hardware-Back-Button" instead of the "Cancel Fullscreen"-Button on the screen, the "Ultimate Zoom..." returns.
Does anybody have an idea what I can do against it?
Thank you, and sorry for the long post.
I used Eclipse before and I could easily stop logcat from scrolling, but I can't find same funcionality in Android studio. Anyone knows how to do it?
There's no dedicated button for this, but you can just click on / highlight some text around where you want to stop scrolling.
android studio have this feature
you just click on the line three times and you can selectd the line , it will stops scrolling.
I had the same issue. Simple solution:
In Android monitor, on the right, change No Filters -> Show only selected application.
Android Studio Stop scrolling log
Disable Scroll to the end
If not - you are able to scroll to necessary line manually and LogCat will not be automatically scroll to down
I actually just had a problem (in 1.2.2) where I couldn't keep it from scrolling. I tried all the tricks and proper methods mentioned here, but it kept scrolling out from under me.
Turns out there was a problem trying to connect to an emulator that had long since been disconnected, and it kept retrying. And every time it did, it reloaded everything causing logcat to refresh. So it wasn't REALLY scrolling, it just felt like it was because of how big the buffer is.
I unplugged my physical device (that was running along side the emulator), restarted Android Studio, plugged the physical device back in, and boom, it no longer kept "scrolling".
Hopefully this might help someone else. Because I was getting incredibly frustrated for a while, there.
Goodness, the trick is to search. Search for something within LogCat and then scrolling will stop. Tested: running Android Studio 1.1.0 against a real device (S5). Also, was ticking one line up and one back down until I then right clicked. Then it totally stopped. After that, I can remove the search and the scrolling is no longer automatic.
A very strange problem that cause the app to draw ontop of itself without cleaning the previous frame.
Its a bit hard to explain, see the next image:
Some other symptoms of this problem:
If I start it on emulator with GPU, the problem occur.
However if I start the emulator without GPU, it does not.
The actual device that I use is connected to a monitor using HDMI. Maybe it is related.
Any help will be highly appreciated.
This looks like a very similar problem I've posted before (link here) .
The problem is that I tried to use 2 tricks for optimization - have an empty background for both the window and its views.
The reason is that there is the window of the activity already has a default background, but when you remove it, and the views don't have a background, Android doesn't "clear" the content with the background, so it smears...
Do note that this "bug" might occur on some devices yet on others it would work fine.
In short, the solution is to set a background to either the window or its views.
I'm building an html5 wrapped iOS / Android app with Trigger.io.
I have a problem on Android with a grey background appearing on the screen in some occasions after the virtual keyboard has closed, or after the phone has changed orientation.
Example screenshots are shown below.
The grey background is after the end of my app's page. Sometimes it is visible for a split second, other times it stays visible until you make an action such as scroll the page, bring the keyboard back, change orientation.
It's pretty jarring to look at.
I'd ideally like to stop the issue occurring, but as a temporary fix I'd be happy with being able to set the grey to my own background colour to make it less noticeable.
This looks like the HTML's not being re-drawn when the keyboard disappears... does it clear up if you do something to trigger a render?
Are you using a framework to handle the UI here? Something that might be trying to do something clever based on the visible viewport?
From what I can tell, the root of the issue is in the webview not re-drawing correctly, or something in your JavaScript failing to respond to the viewport changing size.
You could try running the app on the "web" target (instead of Android) then opening it in your phone's browser: if you can get far enough into the app to create the same effect it would help isolate the problem to the webview rendering or your JS.
I had a very similar issue in my project, in my case on Android 2.3.5 but not on Android 4.*. The cause in my case was not setting a window soft input mode for the associated activity in the manifest:
android:windowSoftInputMode="adjustPan"
Instead, the window was resizing when the keyboard appeared but apparently not resizing once more when the keyboard disappeared.
More details can be found here.
I almost went crazy with the same issue. I finally found out that this largely depends on the device you are using. I had a similar problem : Fixed elements (HTML) break after android keyboard dissapears?
And I am also using trigger.io. This doesn't happen with some devices. Could be the particular OS in android or could just be the way the specific device handles the memory latency.
I have looked for this but I go with #jamesbrady in that the HTML doesn't redraw. The problem in trigger is that you cannot edit the
android:windowSoftInputMode="adjustPan"
because the activity tag in the AndroidManifest.xml updates on each run. You would need to build a private module for that.
I've been using FLAG_WATCH_OUTSIDE_TOUCH to get touches from a system overlay in honeycomb, but this no longer works in ICS. I need the application underneath to receive touches too so TYPE_SYSTEM_ALERT didnt work. The application isnt going to be put on the play store so its ok if it needs root or to be put in the system directory to work. Any ideas?
Thanks,
ng93
It seems this is just the case, as this post highlights. This is generally a bad idea, see the documentation:
These windows must not take input focus, or they will interfere with the keyguard.
I haven't actually tested those overlays on Android 4.0 ICS but other apps like SwipePad seem to do this just fine. The only concern I am aware of is related to performance, such overlays often take a hefty toll on the device. If you want to accurately detect touch input and the overlay does not have to be above the lock screen, try TYPE_SYSTEM_ALERT. Another post on SO seems to have chosen that type as well.