There exist several solutions (both legit and workaround) to allow the navigation bar to be hidden in smartphones and, in the case of https://stackoverflow.com/a/15227433/995285 there is even a magic flag that hides everything. I have confirmed that solution as working on my Sony ExperiaZ running Android 4.1.2. Seemingly perfect.
Trouble is, I am involved in Android OS development and one requirement is that the combined bar be completely hidden while proprietary applications are running - this is for safety reasons - and I cannot, for the life of me, get the status bar to hide using the API.
My question, then, is what modifications need to be made to the Android OS to achieve this goal? Could I derive the responsible class and use that as a replacement? If I'm not mistaken, I'm looking at modifying the WindowManager, but I could be wrong...
We are, so far, limited to Android ICS 4.0.4 and so the aforementioned solution does not work - I tried and hoped...
Related
I created app for Android(with Xamarin Classic). I did the testing and everything is fine, except for one thing: StatusBar not showing on MIUI and EMUI.
I understand that these firmware have their own peculiarities. but I almost did not find any information about it. Only this question, this quote:
your android device does not support that feature. For example, there
are different custom ROMs that manage the status bar in an
unconventional way like MIUI, EMUI, etc.
Please help me, any tips and tricks.
Background
I have a live wallpaper that uses the relatively new API (from Android 8.1 - API 26) to request the OS to use customized colors:
https://developer.android.com/reference/android/service/wallpaper/WallpaperService.Engine.html#notifyColorsChanged()
https://developer.android.com/reference/android/service/wallpaper/WallpaperService.Engine#onComputeColors()
The problem
On Android 8.1 and even on Android P DP1, all worked fine with these functions, as they did what normal wallpaper do with the colors, affecting the notification drawer if the color that was chosen is dark enough. Here's a comparison between choosing a non-dark color and choosing a dark color background:
Thing is, on Android P beta (DP2), even though this function get called, it doesn't do anything, ever.
To test it on your own, you can try the full project I've published here.
What I've found
I thought that maybe the API has changed, so I've tried to find which functions are available, but I couldn't see anything that's new.
I've tried to use various ways to return the customized colors:
a. WallpaperColors(Color.valueOf(0xff000000.toInt()), Color.valueOf(0xff000000.toInt()), Color.valueOf(0xff000000.toInt()))
b. WallpaperColors.fromDrawable(ColorDrawable(0xff000000.toInt()))
c. WallpaperColors.fromDrawable(BitmapDrawable(completelyBlackBitmap))
d. WallpaperColors.fromBitmap(completelyBlackBitmap)
Sadly none worked (fromBitmap is the one that works well on Android 8.1).
Seeing this, I've re-checked that my code is ok, and noticed that the built in live wallpaper works fine, and that selecting a solid black wallpaper (instead of live wallpaper) also affected the UI of the OS.
Seeing that it works with built in apps, I've reported to Google about this issue, only to find out that they don't understand what I'm talking about, and each time I've tried to tell them they've misunderstood it differently:
https://issuetracker.google.com/issues/79404938
https://issuetracker.google.com/issues/79665215
https://issuetracker.google.com/issues/80029770
I wanted to make sure it's not an issue with just my app, but with others too, so I've tested Muzei live wallpaper app, which is actually made by one of Google's own developers. The issue indeed occurs there too, while working fine on Android 8.1.
I was just curious, and wanted to check if the issue could occur if I've moved Muzei to be a system app, but after doing so, I've seen the issue still exists.
The questions
How come it doesn't work anymore?
Is there a workaround/fix for this?
Why does it work fine for built in apps and for normal wallpapers, but not for third party apps? I don't think their code is any difference.
OK, Google confirmed it's a bug, which will be fixed on later version:
The development team has fixed the issue that you have reported and it
will be available in a future build.
And, it works fine now on DP4 (beta 3) of Android P.
I'm trying to figure out how to enable vertical scroll for an Android widget.
From what I read in the documentation and this post it's possible to do that only from Android version 3.0 and up.
However, I saw a phone (Motorola Razr) with Android version 2.3.6 that had a Gmail widget with a vertical scroll.
So I can't understand if it's possible or not? And if it is possible, how to implement it?
Manufacturers generally build out Android from a custom version of AOSP. Since the entire source for Android 2.3.x is available, it is quite possible that Motorola simply added support for scrolling widgets by modifying the source for their own devices (potentially using the same techniques that AOSP 3.0 does). And if this is indeed the case, that will require changes in the underlying operating system and hence will likely not be available to you if you are building the widgets using the SDK.
If by widgets you are talking about ? extends widget.View, you can always build you own View that does vertical scrolling.
This envolves parsing onTouchEvent (and probably onDispatchTouchEvent) and a lot of math.
I did it myself at work.
I'm trying to make some of my applications available on Android 4.0 (Ice Cream Sandwich) devices. It would be helpful to know the different things to look for, as sort of a checklist.
What are the generic steps necessary to make an application available and functional on an Ice Cream Sandwich device? I'm not looking for every single potential API change to make, but any detail would be appreciated.
One thing I have encountered relating to usability is that if you have a fullscreen activity, to allow some way to exit it or go back since phones might not have hardware keys to send the back event. Basically, never assume that the user has hardware keys available.
Google also recently released a design guide for ICS available at http://developer.android.com/design/index.html
Well, as Blundell said, it should work without any problems. I have however, found one quirk while running ICS in the emulator with my apps (maybe this applied to Honeycomb as well, no idea).
Here it is - if you have an app widget, and you don't provide the android:previewImage attribute in the appwidget-provider configuration, your widget will not be visible in the "Widgets" tab. You can use an app that comes with the ICS emulator (Widget Preview) to generate this preview image.
I have a ListPreference on my android application.
On phone 2.3.4, it has the 'downward triangle with a circle' icon on the right.
But when I run on the same app on Samsung Galaxy, it has no such icon. Can you please tell me how can I fix that?
Thank you.
The missing triangle is probably due to customizations that Samsung has made to Android. If you want to force the list preference to appear the exact same on each device regardless of the vendor you will probably have to subclass the ListPrefernce class and define exactly how you want it to appear, rather than using the definition that ships with the device.
Update I just noticed that you mention you are using a tablet in the title. I'm assuming you're using a Galaxy Tab 10.1 or 8.9. If that is the case the missing triangle is either due to Honeycomb or TouchWiz. If its a Honeycomb customization I wouldn't try to hack one in there.
It really is best for everyone if your app conforms to the UI standards put forth by the OS. Introducing inconsistencies in the UI tends to make users unhappy and can lead to interfaces that are difficult to use.