Develop Reference

Notification icons, fully white on some devices, multicolored on others. Why?

My question is not about how to create white icons.
I'm just trying to understand WHEN, exactly, the automatic white filter kicks in.
I've read notification icons, from Lollipop onwards, automatically become white 'silhouettes', so even if you use a multicolored image with setSmallIcon, any non-transparent part of it will turn fully white when displayed in the status bar.
And that's precisely what it actually does on every nexus/pixel emulator I start from android studio. Any android version, among 5, 6, 7, 8, does this.
But I actually didn't find out about this lollipop feature until recently, because all this time, and even now, by loading the exact same app on real devices, I always see the original multicolor image in the status bar. This happens on a samsung s5neo, on a huawei p8lite, and many others.
I asked my users, and apparently some see them white, some see them colored. Some with Oreo see them white, some with Oreo see them colored. It seems it also depends on which specific icons I use, because some users report they see, on the very same device, some of them white and some of them colored.
I use with setSmallIcon either my ic_launcher, so applying it from the resources, or Icon objects created from some Drawables I get from external sources.
And I use pixeled sprites of characters as icons, so when I say colored I don't mean a 'green thing', I mean a really colorful image.
My app has sdk target 27, it also uses some oreo functionalities.
So, what's going on? I read everywhere that it should do the silhouettes on ANY >=lollipop device, but that's obviously not all there is to know about it, and I want to understand better.
How can, for example, my oreo users, see multicolored images, set with setSmallIcon, if I have sdk target 27?
Can someone explain? Thanks!

Create your notification icon using white pixels plus the alpha channel, as documented, and you will get consistent results.
Some device manufacturers tinker with Android. For some, apparently, that tinkering includes supporting non-standard notification icons. You have no good way, ahead of time, of knowing exactly which devices (out of 10,000+ models) will have this behavior.
If a device manufacturer hires you to build an app, or wishes to license an app from you, you might inquire about their notification icon policy and make adjustments to take advantage of whatever they offer.

Phonegap: App thinks my phones screen is smaller than the app, resulting in scrolling (android)

So I first had created an app with HTML/CSS/JS self-typed and after that, I've created a new version with Adobe Muse. Both uploaded to Phonegap, turned into APK and uploaded->Installed on my phone (HTC One X, resolution: 1280x720)
The whole site (both versions) are based on a 1280x720 screen and all sizes are based on that. However, on both versions; if I load it on my phone, it results in a very much zoomed version, which makes you be able to 'scroll' on the app. Somehow.. I can't seem to fix that.
My question: How do I fix it, so my screen size is the same as the apps' (html files)? Resulting in no scrolling? (And for bigger/smaller screens automaticly up/downscaling?).

Updating an old pre-tablet Android app to a tablet version

So here's the scenario: we have an old app on the Play Store that was published before there were any tablets (it runs on tablets using the phone interface.) We want to release an update to that app (because it has >150K users) instead of a new app but because the design for the phone UI won't be ready in time for our deadline we want to release an update that targets only tablets for now while the existing users continue to use the old phone-only app. Later, when the design and implementation of the phone UI is complete, we want to release another update that adds support for phones.
Ideally what should happen is if a user is using the old app on a phone, they will not get the first upgrade notification but a user running it on a tablet will get the update notification (and a new user installing it for the first time will get the the old apk if, for example, they're running a Gingerbread phone while a user using, say, a Nexus 7 will get the new apk.) Eventually, all users will get the update notification to the second release no matter what Android version/device type they are running.
If we do this, what will the experience be for the current users that are using the old version on phones? Will they be prompted to upgrade to an app version they cannot run or will they get no update notification at all? Later, when we release the second upgrade that does support phones will they then get the update notification?

To make your app look great on tablets, just add specialized layout types, just like
layout-large or layout-sw600dp. Then copy your existing layout-xml files from your layout folder to these and modify them as required.
I suggest reading Supporting Different Screen Sizes.
This way, you add tablet-optimization without throwing away phone compatibility.

I'm not quite sure what you mean by having an update only available to a certain device. Tablets and phones work quite differently and the Google Play market is capable of differentiating what will run on the user's current device and what won't.
Like the previous answer you WILL be required to construct different layouts specifically for tablets.
However if you only want an update to tablets to take place on tablets - You need to get as much information about the screen size, density, device version and maybe even the current users android OS version to really help you narrow down whether the current device is a tablet or large screen device or not.
For example:
Get screen dimensions in pixels
shows you how to get screen dimensions.
How can I check the system version of Android? Gives you more information about the current android version.
getting the screen density programmatically in android?
will allow you to find out the screen density of the current screen.
Using all of the above, or some similar combination, you can determine if the user is running your app on the tablet, if they are, provide them with an update, if not, the app continues with its regular layouts as normal.
I'm not quite sure if this is the answer you were looking for, but I hope it helps.
Take care

we have Android Application Size more than max Size?

What should we do if the size of our Android application is more than max size? Currently the acceptable size for Android applications (i.e. <App>.apk) on the Android market is 50 MB.
If our <Application>.apk size is more than 50 MB then what's the alternative to follow on?

Try removing the resources from the project and changing the app so that the resources will be downloaded upon first app opening to the SD card...
It will take some time to develop the changes, but I don't think you really have a choice...
Note that Samsung devices have an even smaller size limit...

The first reason for .apk size growth is resources. The more specialized application gets on each configuration (screen sizes, orientations, densitites etc) the more .apk size grows. Usually .apk still has size much less then 50 mb limits, but even with 20mb users may perceive your application as heavy.
Android Market added support for multiple .apk per application. This feature was designed to specifically address the issue of .apk size growth due to many different configuration. You can read more about it in Multiple APK Support in Android Market post from official Android blog. Though this is considered as last resort.
If you .apk size is large due to other reasons, then you're most likely doing something wrong. If its some embedded video/audio file (or even files!), consider moving them to web and download when user needs them for the first time. This will save internal memory space which is might be critical to users (especially on older devices).

I can't image why an application would be more than 50 mb from just the source code alone. If alot of the size is in design elements(images, etc) or data(database files), you could always have the user download this info when the application is first run.

if you are using Android 2.3.3 version then minimum size of the application must be minimum 9MB and maximum size is depend upon the device,the capacity of memory of the device. but if you take it 50 MB then no problem, its disadvantage is only that the AVD takes time to start.i don't know the Android Market place current application size.

Targeting Different Specs in Android App Submission

We're working on a port of an iPhone game to Android. One of the additional hurdles with this is all the different device resolutions Android has. We're having our art team rework the art for each target resolution (we're only picking a few for now with more later.)
My question is, can we (and how best to do it) submit separate packages for each resolution to the Google Market under a single title so that when someone purchases it they get a specific resolution?
UPDATE 7/21/2011
Although we released without it, it was just announced that the Google Android Market now officially supports multiple APKs for a single app.
http://android-developers.blogspot.com/2011/07/multiple-apk-support-in-android-market.html

You don't have to do extensive job to support every possible screen size, you only need to make resources for several configurations and Android will do the rest. The major concept here is that there are several screen densities you have to support. Once you've made a resource for each density, Android will automatically use an appropriate resource for the specific device. You only upload a single application for all the devices.
You should read an article on supporting multiple screens and also on providing resources.

I have not seen such an option while uploading my own applications to the market. This is a good/official explanation of how to program to various screen resolutions.
If it is impossible for your to package all of your resolution-specific resources into the app, you can download the images from your servers after the initial start-up of the app. At that point, you'll be able to grab the screen resolution details and only download what you need.