I'm experiencing very nasty bug trying to implement Admob in my
application.
I thought the problem is in my code, but after some investigation I
found it present also in Android-Banner-Essentials example (available for download here).
I wonder if anyone ever met this problem or maybe knows how to deal
with it.
Basically, when application has both status and title bar disabled, it
should use full screen.
Banner Essentials example displays nothing but Admob banner on the
very top of area available.
I downloaded the example, changed only two things:
added my publisher ID to compile properly and receive any ads ;)
added one param to activity's manifest to disable title and status
bar:
android:theme="#android:style/Theme.NoTitleBar.Fullscreen"
Compiled binary, no matter what device is it launched on (tried Nexus One, G1, Desire, different Android versions), is affected with the same issue:
When ad banner is displayed press Home,
Once taken back to home screen press and hold Home to see recently
launched apps,
Select back Banner Essentials app.
My tests reveal that with 50% reproduction chance Admob banner doesn't
go back to its position -the very top of the screen.
To show better what I mean I prepared three screenshots:
http://img841.imageshack.us/g/correctz.png/
Important notices:
When app is resumed normally, banner is displayed just below status
bar, and slides up until is aligned to the top screen border,
when error appears the banner doesn't move at all,
I couldn't reproduce the issue with any other interrupt (pressing
Back, Power Button),
I think it may be somehow connected to gaining/losing focus (see
screenshots).
My app is bit more complex than Banner Essentials so I started with searching the issue in my code, with no luck, thus tried to simplify the situation as much as possible and here are the results.
Does anyone know what may be causing the problem? Maybe some additional flags or properties have to be set to handle this behaviour?
This one is referenced as an Android bug. There is no solution, just a workaround.
You have to re-set Window Fullscreen about 1 second after onResume (to wait till the status bar finishes its fancy sliding out animation...), which will cause it to re/calculate the whole layout, "solving" the problem (with a quick jump to the correct positiin).
public void onResume()
{
...
handler.postDelayed(new Runnable() {
public void run() {
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
WindowManager.LayoutParams.FLAG_FULLSCREEN);
}
}, 1500);
...
}
It's not good. But it's still the best available. More info here.
In my case this behavior was triggered by resume from lock screen. No idea why but after adding empty overloaded function it was fixed (but I tested it only on my HTC Wilfire). It may be a different bug thou.
#Override
public void onWindowFocusChanged(boolean hasFocus) {
super.onWindowFocusChanged(hasFocus);
/* Workaround a probable Android bug with fullscreen activities:
* on resume status bar hides and black margin stays,
* reproducible half of the time when coming back from lock screen
* (tested on HTC Wildfire)
* No idea why but this empty overload method fixed it.
*/
}
Related
I have an APK that runs completely fine across several android levels varying from android 5 through 9. We started testing a new android 9 phone (Hot Pepper HPP-L55B aka Serrano), and I'm seeing an interesting issue that I'm hoping someone has come across.
All of my Activities extend a base activity that does some standard logging (such as logging onCreate, onResume, etc).
On app launch:
Activity 1 - MainLaunch
onCreate starts the activity Splash then calls finish
Activity 2 - Splash
onCreate sets the content view and finds the WebView on the screen.
onResume sets a gif in the webview so it's rendered on the splash screen. It also starts a thread that sleeps for a few seconds that then kicks off Activity 3. The gif animates as expected.
Activity 3 - Launchpad
onCreate sets the content view and finds references to other items on the screen (buttons and textviews).
onResume checks a few internal things, and may or may not hide things on the UI based on configuration. Nothing to exciting.
There are times this process will go through without a hitch, and other times where the UI that was being displayed in Activity 2 (splash) stays up while my logs are showing that the code thinks it's showing UI 3. The gif in this case is no longer animating.
As you click around on the splash screen the buttons that are referenced and would be showing on Activity 3 are being pressed. So basically like the splash screen is covering the 3rd activities screen and allowing button push pass through. If i turn the screen off/on again the splash screen still shows up. Throwing breakpoints in activity 3 get hit as the hidden buttons get clicked.
Anyone ever see this before or have suggestions how to fix it? This phone model seems to be the only one with the issue. So it definitely seems like a phone model problem and not anything i can control. Any suggestions?
This problem boiled down to the processor (MediaTek) being used in combination with the theme being used for the application. At least that was the only thing that was found different across the supported phones we tested.
The theme for the activities were changed:
from #android:style/Theme.Translucent.NoTitleBar
to #android:style/Theme.Light.NoTitleBar
Odd problem. If I:
Launch my app so the splashscreen is showing, then.....
immediately 'minimise' it and send it to the 'recent apps' list, then....
quickly resume the app from the 'recent apps' list, before the splashscreen goes away
watch the splashscreen and wait while resources finish loading
Then when the splashscreen disappears, only the part of the GLSurfaceView that was in the small version of the app view while it was in the recent apps list is actually visible.
I'll explain by way of (very basic) graphics :-).......
I'd like to know if there are any tools I can use to find out what this blank rectangle is.
So I basically have a layout to which I ad my views.
Code snippets
layout = new RelativeLayout(this);
layout.setLayoutParams(new LayoutParams(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT));
I then add my GLSurfaceView (MyGLView) and my splashscreen (which is a standard View) once it's been created:
layout.addView(myGLView);
layout.addView(splashscreen); //The work behind the splashscreen takes place on an AsyncTask
Once the AsyncTask has finished it's work, it removes the Splashscreen from the layout to reveal the GLSurfaceView underneath:
layout.removeView(splashscreen);
Note that if we then place it back to the recent apps list as shown in fig 5 above, then the maximise it again, all is back to normal and I can see everything. Likewise, if I just launch the app and leave it running, all is OK as well as virtually every other sitatuation I can think of. It's only when dong things the way shown above that the problem manifests itself.
What am I doing wrong? Would appreciate any helpful comments.
Please ask if anymore information is required.
Test Device : Google Nexus 10
OS : Stock Lollipop 5.0.1
Edit:
Thanks to #fadden's suggestion below, I've managed to get some new information. When running adb tools dumpsys window when the app is correctly displayed, I get the following:
mFocusedApp=AppWindowToken{b68cbca token=Token{dc7b35 ActivityRecord{7dae96c0 com.me.myapp/.MainActivity t1761}}}
However, with the app not displaying correctly, I get this:
mFocusedApp=AppWindowToken{28ecfffa token=Token{189d2225 ActivityRecord{38b161u0 com.android.systemui/.recents.RecentsActivity t1110}}}
Having said the above, if I tap the screen and run dumpsys window again, the mFocusedApp does change to my app (but the problem doesn't go away) and I have seen similar behavour (with the dumpsys window output with other apps downloaded from the Play Store but their graphics don't have this problem, so this may not be relevant at all.
I have confirmed my view (myGLView has focus via DDMS).
I'm having an issue with a responsive menu I've been working on for some of my designed sites. The jQuery part of it is made to show or hide the menu depending on window width (and hide/show a bar to toggle it).
In mobile browsers, the toggled-open menu will close again when you scroll -- but only if the address bar has been hidden or shown by scrolling down or up. This happens in Android and iOS.
I've definitely narrowed it down to the address bar's appearance and disappearance, because:
it only happens on mobile browsers.
the address bar doesn't disappear while the page is still loading (at least in Opera), and thus the menu doesn't close when I scroll under that condition.
the menu won't close if I scroll after the address bar has been hidden.
However, I don't know what to do to fix it; the address bar affects the height of the window/page, not the width, so I'm unsure of why the menu toggles when you scroll up/down.
This method is the simplest way for me to make a responsive menu with how things are set up currently.
Here's the relevant part of the code I'm using:
var winwidth = $(window).width();
$(window).resize(function() {
var newwinwidth = $(window).width();
if(winwidth = newwinwidth && newwinwidth <= 768) {
// if smaller or equal
$('.menu ul').hide();
} else {
// if larger
$('.menu ul').show();
}
}).resize();
Here's a live example of a site on which this happens: http://jessicacantlope.com
I've already tried a couple debounce methods to see if that would solve the problem (it doesn't; it just delays the action) and also scoured this website. I've included app-capable meta elements and a few other iOS-specific things.
I also looked into solutions that hide the address bar entirely, but they only work under certain conditions and rely on modifying system UI/UX, which is something I don't want to do. I just want to keep it simple.
Any help would be appreciated. I'm more of a designer than a developer, and I love elegant solutions.
EDIT, 2020: Five+ years later, after having implemented a solution that seemed to work for a while and then failed again, I started tinkering and realized that, for the way I had designed my mobile menu and website, and with some of the things I had tried since then, I had been mistakenly targeting the wrong selectors in my code! And I hadn't thought deeply enough about how to apply the first suggestion. It's not elegantly written so I won't post my final code, but I finally got things in working shape. Thanks, everyone!
I had the same issue when working on a responsive site of my own. I was unable to discover the root cause of the issue but I developed a work-around. The anchor which I use to display the menu had a "open" toggle class added to it. I essentially used the "window.onscroll" call to check whether or not the menu should be shown each time the user scrolls the page, "showing" the menu again after each scroll.
window.onscroll = function (e) {
var sidebar = $('#sidebar')
var menu = $('#sidebar > ul');
if(sidebar.hasClass('open'))
{
menu.show();
}
}
Hope this helps!
I had faced the same problem. But I fixed the solution. The problem is, while scrolling the page some times it triggers the resize event of window. When it will check the width of the window it is less than 768px. So the menu will be hidden. There are two solutions for this. First one, you can remove window resize function. Second one, inside the window resize function you should check whether the navigation is opened or closed. According to that you can customize the hide and show process. Which means, if navigation is closed and window width is greater than 768px you can show navigation.
I was also facing the same issue and no matter what I do with resize() function matching height or width of dom the function was still triggering on mobile device so i tried using $(window).on("orientationchange",function() and the problem got fixed.
I found a solution for the problem here javascript resize event on scroll - mobile
var cachedWidth = $(window).width();
$(window).resize(function(){
var newWidth = $(window).width();
if(newWidth !== cachedWidth){
//PUT YOUR RESIZE HERE
cachedWidth = newWidth;
}
});
I am using the Launcher 3 code as a base for building my own launcher application. I've managed to build everything correctly and import the project in Android Studio, however I seem to have some issues when switching into landscape mode on a Nexus 7 (first generation) device.
The problem is that at first the Google search and voice search icons do not appear but after pressing the home button they do. Also if you tap on the places where they should be, the search activity appears and when coming back to the launcher the buttons are there too. It seem that somehow they are not visible and I have looked over in the code but so far I could not find what the issue is.
Is there any one who encountered this problem and can point me in the right direction to solving it?
Thanks,
Mihai
I have managed to solve the problem.
It would seem that the drawableStateChanged() method from HolographicImageView is called when switching to landscape mode before the view is laid out. This would cause the mStatesUpdated flag set in the method generatePressedFocusedStates(ImageView v) in HolographicViewHelper to be set to true and the code updating the search bar ui would not be executed anymore in the subsequent calls of the generatePressedFocusedStates(ImageView v), after the view is laid out.
A simple check for isLaidOut() before calling generatePressedFocusedStates(ImageView v) in the drawableStateChanged() method would do the trick.
I'm using the well known TYPE_SYSTEM_OVERLAY method to create a full screen overlay that's always on top of other views.
On a Moto Atrix2 API15 and for each AVD from API 10 through 17 the overlay view resizes automatically (expands vertically) when the status bar is hidden by another app. The overlay appears to "stay on top" of all other views, as I think it should. When the status bar is in view again, the overlay reduces it's size automatically again (less vertical pixels, basically subtracting the height of the status bar).
This is the desired behavior and am inclined to think this is not the exception or flawed behavior due to it working on many different emulators as well as at least one device manufacturer (motorola), perhaps more, but I don't have access to addtl devices.
The problem: On a Samsung GS2 (API15) & also tested on Kindle Fire (API10?), the overlay does not automatically resize (fill the space where the status bar once was) when the status bar is hidden by another app (status bar behind full screen app). On these devices, after the view is created the first time I don't get any more events from an onSizeChanged override for the view.
Here's the pertinent code:
params = new WindowManager.LayoutParams(
1, WindowManager.LayoutParams.MATCH_PARENT,
WindowManager.LayoutParams.TYPE_SYSTEM_OVERLAY,
WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE
|WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL,
PixelFormat.TRANSPARENT);
wm.addView(sizeLayout, params);
sizeLayout has the onSizeChanged override.
I've played around with just about every windowmanager layoutparam I can find, including SYSTEM_ALERT, FLAG_LAYOUT_IN_SCREEN, etc. I won't sleep until I can figure this out!
Edit 11/30/12: I found this from #deviant: https://stackoverflow.com/a/9195733/1851478 which is basically what I'm doing, however the problem remains with certain devices not resizing the system_overlay automatically. Perhaps I should raise a bug.
More INFO: IF I force a redraw (or even just load the overlay app) while there is a full screen app at the top of the view tree, my overlay still does not draw over the space the status bar normally takes up (even though the status bar is not in view at the time of draw), so it seems as if the overlay is not "overlayed" on top of the frontmost window which is full screen (and I've both created and tested many full screen apps using a variety of methods to make them go full screen). On these devices, the only way to get the overlay to draw over the status bar (even if the status bar is not in view) is to use the flag FLAG_LAYOUT_IN_SCREEN, but then the size of the layout never changes, is always full screen, and thus back to the original problem why this works on some devices but not others.
Edit 12/12/12: So I haven't had any further luck on this, and I did try using getLocalVisibleRect on views, but unfortunately since my app doesn't own the SystemUI views it can't detect what's below the overlays. I suppose with a custom ROM I could do this, but I need a solution without root.
I do see other apps on the marketplace are having the same problem detecting the status bar on the non-working phones I listed above. Example: cool tool, omega statusbar & status bar +. Bounty raised.
Edit 12/19/12 Pictures added. Note that on a working device the gray area also "covers" the black area (any app that is currently full screen), the black area actually covers entire screen, I'm just showing the gray area as my overlay even though it is also full screen (minus or plus the height of the status bar depending on working/non-working device and whether it is in view or not).
Hopefully i understand what you are after here but, in my app (TEAM BatteryBar) i had a similar problem. ( no root minimal permissions )
I couldn't detect a full screen on anything below API11 (and intermittent on some (Samsung mostly) devices above API11). So i made a custom listener for it by adding a second layout to the WindowManager with a different layout param then overrode the onLayout to check if the statusBar is still there or not by checking the window size. from there you can do what ever you need to to your main view.
I was going to tidy it up but it worked so i didn't :P code is over a year old and is from when i first started coding for android so yeah. Food for thought tho. hope it helps.
here is the code in a repo at my github with a copy paste straight out of my app on how i am using it. small snippet here
wm.addView(sizeLayout, params);// add your view
// then add the next one
Screendetect mDetector;
mDetector = new Screendetect(this);
mDetector.setOnFullScreenListener(new OnFullScreenListener() {
#Override
public void fsChanged(boolean FS_Bool) {
// TODO rethink this to be better.... bit hacky...
if (FS_Bool) {
Log.d("battbardetect", "Statusbar hidden");
FS_vissible(); // do what ever you need to
} else if (!FS_Bool) {
Log.d("battbardetect", "Statusbar Vissible");
FS_hidden(); // do what ever you need to
}
}
});
wm.addView(mDetector, params);
I think this may be the same issue with hiding the titlebar on dialog windows where the system sets the visibility to hidden instead of gone. This causes the dialog window to get incorrectly centered.
For that, here's how I fix it. This might work for your situation but you may need to adjust it for the name of the status bar identifier.
Window window = dialog.getWindow();
View view = window.getDecorView();
int topPanelId = getResources().getIdentifier("topPanel", "id", "android");
LinearLayout topPanel = (LinearLayout) view.findViewById(topPanelId);
topPanel.setVisibility(View.GONE);