Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-19486] Android: Generate missing app icons based on DefaultIcon.png

GitHub Issuen/a
TypeImprovement
PriorityHigh
StatusReopened
ResolutionUnresolved
Affected Version/sn/a
Fix Version/sn/a
ComponentsAndroid, Tooling
Labelscb-tooling
ReporterChris Barber
AssigneeJoshua Quick
Created2015-09-09T21:45:00.000+0000
Updated2019-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

FileDateSize
DefaultIcon.png2016-02-24T09:32:31.000+000091321
platform.zip2016-02-25T03:17:23.000+000045707

Comments

  1. Feon Sua Xin Miao 2015-12-16

    PRs: https://github.com/appcelerator/titanium_mobile/pull/7588 https://github.com/appcelerator/alloy/pull/763
  2. Chee Kiat Ng 2016-02-24

    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|
  3. Chee Kiat Ng 2016-02-25

    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.
  4. Chee Kiat Ng 2016-02-25

    [~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.
  5. Feon Sua Xin Miao 2016-02-25

    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*?
  6. Chee Kiat Ng 2016-02-26

    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
  7. Chee Kiat Ng 2016-02-26

    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?
  8. Chee Kiat Ng 2016-02-26

    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.
  9. Chee Kiat Ng 2016-02-26

    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.
  10. Chee Kiat Ng 2016-03-01

    PRs merged
  11. Chee Kiat Ng 2016-03-01

    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.
  12. Chee Kiat Ng 2016-03-02

    [~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*
  13. Feon Sua Xin Miao 2016-03-02

    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 missing Resources/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?
  14. Chee Kiat Ng 2016-03-03

    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] ^
  15. Chris Barber 2016-03-03

    [~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

    <titanium-sdk/templates/app/default/template/DefaultIcon.png}}

    Note: <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.
  16. Chee Kiat Ng 2016-03-03

    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.
  17. Chris Barber 2016-03-03

    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 the appicon.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.
  18. Chee Kiat Ng 2016-03-03

    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?
  19. Chris Barber 2016-03-08

    PR https://github.com/appcelerator/titanium_mobile/pull/7588 reverted by https://github.com/appcelerator/titanium_mobile/pull/7816.

JSON Source