{ "id": "152335", "key": "TIMOB-25171", "fields": { "issuetype": { "id": "4", "description": "An improvement or enhancement to an existing feature or task.", "name": "Improvement", "subtask": false }, "project": { "id": "10153", "key": "TIMOB", "name": "Titanium SDK/CLI", "projectCategory": { "id": "10100", "description": "Titanium and related SDKs used in application development", "name": "Client" } }, "fixVersions": [], "resolution": null, "resolutiondate": null, "created": "2015-10-26T14:07:12.000+0000", "priority": { "name": "None", "id": "6" }, "labels": [ "cb-tooling" ], "versions": [], "issuelinks": [], "assignee": null, "updated": "2020-01-30T21:22:54.000+0000", "status": { "description": "The issue is open and ready for the assignee to start work on it.", "name": "Open", "id": "1", "statusCategory": { "id": 2, "key": "new", "colorName": "blue-gray", "name": "To Do" } }, "components": [ { "id": "13103", "name": "CLI", "description": "Node-based command line interface" } ], "description": "Triggered by a [blog post|http://skypanther.com/2015/10/arggh-failed-android-install/] by [~skypanther] I was thinking maybe we should ask the user to try again when for some reason the CLI failed to install an app on a device.\r\n\r\nCurrently, you'd need to do the full build again or manually figure out how to use the involved to tooling directly to install the existing build - which would not get you the logs via the CLI.\r\n\r\nWe could do something like:\r\n\r\n{code}\r\n[INFO] Making sure the adb server is running\r\n[INFO] Installing apk: /path/to/your_app/build/android/bin/YourApp.apk\r\n[INFO] Installing app on device: Galaxy Nexus\r\n[ERROR] Failed to install apk on \"01498FE710016018\"\r\n[ERROR] Error: INSTALL_FAILED_VERSION_DOWNGRADE\r\n\r\nWould you like to have me try it again?\r\n\r\n0) No, thanks\r\n1) Try again with device A (selected)\r\n2) Try again with device B\r\n{code}\r\n\r\nBy displaying and refreshing the (otherwise cached) list of connected devices the user would be able to try another device, the same or give up.\r\n\r\n*UPDATE:* As [~timpoulsen] suggested, it might be even better to have a map of errors-codes to human-readable reasons why the install failed as well as a flag if a retry would make sense. Like in the above example, it would not and the users will simply have to remove the app or bump the version and rebuild.", "attachment": [], "flagged": false, "summary": "Ask to try again after installing app to device fails", "creator": { "name": "fokkezb", "key": "fokke", "displayName": "Fokke Zandbergen", "active": true, "timeZone": "Europe/Amsterdam" }, "subtasks": [], "reporter": { "name": "fokkezb", "key": "fokke", "displayName": "Fokke Zandbergen", "active": true, "timeZone": "Europe/Amsterdam" }, "environment": null, "comment": { "comments": [ { "id": "367792", "author": { "name": "timpoulsen", "key": "timpoulsen", "displayName": "Tim Poulsen", "active": true, "timeZone": "America/Havana" }, "body": "Thanks for submitting the ticket Fokke. I think if this is implemented, it would be most useful if the tooling provided some plain-language interpretation of why the first build failed. By that I mean simply parsing the error code (e.g. INSTALLED_FAILED_VERSION_DOWNGRADE) and offering a helpful suggestion (\"Looks like you already have a newer version of this app installed on your device.\"). ", "updateAuthor": { "name": "timpoulsen", "key": "timpoulsen", "displayName": "Tim Poulsen", "active": true, "timeZone": "America/Havana" }, "created": "2015-10-26T14:13:13.000+0000", "updated": "2015-10-26T14:13:13.000+0000" }, { "id": "367794", "author": { "name": "fokkezb", "key": "fokke", "displayName": "Fokke Zandbergen", "active": true, "timeZone": "Europe/Amsterdam" }, "body": "Good one [~timpoulsen]", "updateAuthor": { "name": "fokkezb", "key": "fokke", "displayName": "Fokke Zandbergen", "active": true, "timeZone": "Europe/Amsterdam" }, "created": "2015-10-26T14:17:31.000+0000", "updated": "2015-10-26T14:17:31.000+0000" } ], "maxResults": 2, "total": 2, "startAt": 0 } } }