[TIMOB-19486] Android: Generate missing app icons based on DefaultIcon.png
GitHub Issue | n/a |
---|---|
Type | Improvement |
Priority | High |
Status | Reopened |
Resolution | Unresolved |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | Android, Tooling |
Labels | cb-tooling |
Reporter | Chris Barber |
Assignee | Joshua Quick |
Created | 2015-09-09T21:45:00.000+0000 |
Updated | 2019-08-29T17:42:19.000+0000 |
Description
If any of the app icons are missing, then search for
<project-dir>/platforms/android/DefaultIcon.png
and <project-dir>/DefaultIcon.png
and us it to generate missing app icons.
You simply need to the base Builder object's generateAppIcons()
method:
var missingIcons = [
{
description: 'Resources/<platform>/appicon.png - Used for iPhone', // some meaningful description... iOS build dynamically generates this
file: '/path/to/dest.png', // MUST be a png and MUST have an extension
width: 100, // whatever is required
height: 100, // should match width
required: true // when DefaultIcon.png isn't big enough, true will trigger an error and false will skip the icon
}
];
this.generateAppIcons(missingIcons, function (err) {
// err is either true if there was an error or undefined if it was successful
});
Attachments
File | Date | Size |
---|---|---|
DefaultIcon.png | 2016-02-24T09:32:31.000+0000 | 91321 |
platform.zip | 2016-02-25T03:17:23.000+0000 | 45707 |
PRs: https://github.com/appcelerator/titanium_mobile/pull/7588 https://github.com/appcelerator/alloy/pull/763
Test case A Titanium CLI:
Brand new project, replace DefaultIcon.png with the one attached in ticket. *ti create*, *ti build -p android*Expected Result:
Build success. On home screen you should see the app icon to be the same as the one attached on ticket. Also, in build->android->bin->assets->res, you will find the corresponding icon in each drawable folder, with these respective sizes: ||folder||icon size|| |drawable-hdpi|72x72| |drawable-ldpi|36x36| |drawable-mdpi|48x48| |drawable-xhdpi|96x96| |drawable-xxhdpi|144x144| |drawable-xxxhdpi|192x192|Test case B:
Scenario where DefaultIcon.png exists, and ALL icons described [here](http://docs.appcelerator.com/platform/latest/#!/guide/Icons_and_Splash_Screens-section-29004897_IconsandSplashScreens-LauncherIcon) exists, but are different from DefaultIcon.png. (This is the situation when a user decide to IGNORE the DefaultIcon.png and have his very own other icons). 1. *ti create* 2. unzip attached zip into root of project 3. *ti build -p android*Expected Result:
Build success. User's icons (those in the zip file) should be prioritized over the use of DefaultIcon.png.[~fmiao] [~cbarber] some critical questions i need to ask here: 1. Before this implementation, Android takes *resources/android/appicon.png* and stretch/shrink it during build for the respective resolutions. It is not actually necessary to disect it into folders and individual files. So would doing this here be redundant when we can just point it towards a high res DefaultIcon.png instead? If you do intend to just point it towards the DefaultIcon.png, take note of this statement in the guide: {quote}By default, a newly created Titanium application uses the Resources/android/appicon.png file. The filename must match the name specified in the icon element in your tiapp.xml file.{quote} 2. Before this implementation. ti developers can control which icon to use for whichever resolution, by putting them in this folder: *platform/android/res/drawable-\** Chris didn't you say something about how the platform folder shouldn't be used at all? 3. Feon, for Test case A and B, it doesn't work when using appc. I suppose it's something to do with alloy. But we should address issue #1 and #2 before fixing this on alloy. 4. Another small bug is, once i build the project once, if i change the DefaultIcon.png to a different image, and build again (without doing *ti clean*), the app icon isn't updated. Also, to address issue #1 and #2 first before looking at this.
1. Android will perform scaling/resizing of images if density specific versions are not provided. We can use a single large appicon, and let Android do the work, but I'm not sure how Android's scaling rules work or it is a good practice, and also the result maybe sub-optimal. 2.
<app>/platform/android/res/drawable*
has been the place for developers to place their density specific versions of the appicon. 3 & 4. Works for me. Do you see the updated icons under/build/android/res/drawable*
?1. How confident are we that our scaling rules is better than Android's, or that our results is more optimal? We are pretty much doing the same thing. I guess it's fine as long as the outcome is the same. and we don't create more bugs or issue by introducing this. 2. Ya. This question is more for [~cbarber]. 3 & 4. I'll test it again
OK 1 and 2 is fine now. I retried 3. and yes it's behaving correctly. I was misled because *appc new* uses a template whereby there already exists various res icons in platform/android, that's why my changes to DefaultIcon.png has no effect. Can we also include a PR to remove the platform folder in the template used by appc new? And remove assets/android/appicon.png if possible?
Test case C:
Scenario where DefaultIcon-android.png exists, and the icons described [here](http://docs.appcelerator.com/platform/latest/#!/guide/Icons_and_Splash_Screens-section-29004897_IconsandSplashScreens-LauncherIcon) don't exists, but is different from DefaultIcon.png. 1. *ti create* 2. Include a DefaultIcon-android.png that looks different from DefaultIcon.png in root. 3. *ti build -p android*Expected Result:
Build success. DefaultIcon-android.png should be prioritized over the use of DefaultIcon.png.CR and FT passed. [~fmiao] just consider the removal of platform/android/res/* app icons in the template for *appc new* and we can merge this PR. Above test cases can also be done using appc and the behavior and expected results should be the same.
PRs merged
Need another PR to address the need to rebuild everytime because of generating the icons. Need mechanism to check if there's any need to generate icons.
[~fmiao] Tried to verify whether the missing icons are regenerated whenever DefaultIcon.png changes. However, I discovered a strange bug. Looks like the icon is fickle. Every time I build, the icon switches between 2 different images.
Steps to reproduce
1. *appc new* 2. replace the DefaultIcon.png with the one attached in ticket 3. *appc run -p android* 4. Repeat 3. Do not clean. 5. Repeat 3. Do not clean.Result
3. The app icon appears correctly on the simulator, with the thumbsup. 4. Strangely enough, the app icon changed to the "alloy" icon, which can only be found in appicon.png in app/assets/android/ 5. Strange again, the app icon changes back to the thumbsup. And icon switches every time we repeat appc run. Also take note that, the generated icons (of thumbsup) remains in build/android/bin/assets/res, and still exists there every time we call *appc run*The generated files in
../build/android/res/drawable*
are wiped out on every alternate build, because they are not changed and fall into the old file watch list. These old files get removed down the build pipeline. Since no density specific images are found the default appicon,Resources/android/appicon.png
, is used. The fix is simple. But chatted with Chris, we think it's less confusing to only generate the missingResources/android/appcion.png
. If developers want to have different images for different screen densities, they have to do so by putting the files in../platform/android/res/drawable-*
. [~cng], [~emerriman] thoughts?Am I right to say that the conclusion is to not make any changes to the current implementation. It will only be simply, If Resources/android/appicon.png is missing, generate it. I'm ok with us not generating the different images for different screen densities. Just that, I really prefer a total parity for all platforms to use DefaultIcon.png. i.e. If i change DefaultIcon.png, all platforms should be using that image. If i want specific platform icons, I'll use DefaultIcon-android, DefaultIcon-ios. If I want density specific images for android, i'll put the files in ../platform/android/res/drawable-* Can we do that? I'm fine removing Resources/android/appicon.png from the template and put all dependencies on DefaultIcon.png. I also hear Chris that we should discuss cross-platform assets catalogs, and maybe that would change everything discussed here anyway. However, in terms of planning, that wouldn't come too soon, and if the change i propose is a simple one, we can introduce it first. [~fmiao][~cbarber] ^
[~cng] Mostly correct. Just want to clarify that there is no "generation". The Android build is going to look for an app icon and copy it to the
build/android/res/drawable
directory. Here's the order for finding the app icon:<project-dir>/Resources/android/<icon>
<project-dir>/Resources/<icon>
<project-dir>/DefaultIcon-android.png
<project-dir>/DefaultIcon.png
Note:<titanium-sdk
/templates/app/default/template/DefaultIcon.png}}<icon>
above is derived from the<icon>
defined in the tiapp.xml, or falls back to "appicon.png". There is no resizing. There is no build manifest. There is no hash change tracking. It's super simple. Then we need to nuke the appicon: https://github.com/appcelerator/titanium_mobile/blob/master/android/templates/app/default/template/Resources/android/appicon.png.Thanks [~cbarber] for the clarification. Is it also possible that we can consider: - get rid of the dependency on
<icon>
in tiapp.xml? like obliterate it from tiapp.xml since there's no parity in this regard with other platforms. - Hence get rid of the first 2 checks - also nuke the appicon.png in the templates Naturally this would mean some breaking change. But do we agree that this way it'll be cleaner? then it's just a matter of schooling our developers in the next major version bump.All platforms honor the
<icon>
in the tiapp.xml, so I wouldn't say there's no parity. I think we need to discuss a new asset catalog system to replace the<icon>
in the tiapp.xml as well as all theappicon.png
,appicon@2x.png
, etc icons before we start ripping things out. We need a solution to replace everything and it has to be easy to use and powerful.ok gotcha. sounds good to me. Your proposal will do for now. At least for 5.4.0. [~emerriman] any other concerns before [~fmiao]does it this way?
PR https://github.com/appcelerator/titanium_mobile/pull/7588 reverted by https://github.com/appcelerator/titanium_mobile/pull/7816.