#104 ✓resolved
Nikias Bassen

[PATCH] new installation_proxy interface

Reported by Nikias Bassen | December 31st, 2009 @ 02:45 AM | in 1.0 Release

Hi!

Here it is: the installation_proxy interface. Allows enumeration, install, uninstall, upgrade, archive, restore, etc. of apps.

Some notes: For installing/upgrading an app, instproxy_install/_upgrade will require a pkg_path that points to a *.ipa (=ZIP) file path inside the AFC jail, so the app package ideally has to be copied to the device via AFC before calling this function.

Another point is that the operations install, upgrade, and restore will fire the notification com.apple.mobile.application_installed (NP_APP_INSTALLED) whereas the operations uninstall and archive will fire the notification
com.apple.mobile.application_uninstalled (NP_APP_UNINSTALLED), when these operations succeed. So the use of the notification_proxy is advised ;-)

Most of the interface's functions allow to specify a status callback function, which makes it possible to get the progress (including a percentage value in most cases) of the ongoing operation aswell as error messages. If no callback function (NULL) is passed, the operations run synchronously until they finish (or an error occurs). Read the code and comments for more details :-P

Have fun and all the best for 2010!

Comments and changes to this ticket

  • Nikias Bassen

    Nikias Bassen December 31st, 2009 @ 01:50 PM

    Last minute update!

    Here's a follow-up patch that adds an 'options' parameter to instproxy_archive. Currently, you can specify the following options:

    INSTPROXY_ARCHIVE_APP_ONLY - Archive only the application data
    INSTPROXY_ARCHIVE_SKIP_UNINSTALL - Do not uninstall the application.
    

    Combine these options with logical OR to specify both. These two options
    combined are used by iTunes to create app archives of on-device downloaded
    apps that are later copied as *.ipa files to the computer.

    If no option is specified (options set to 0), ALL app data including app specific user settings and data will be archived AND the application will be uninstalled afterwards.

    Note that if INSTPROXY_ARCHIVE_SKIP_UNINSTALL is specified the device will NOT fire the com.apple.mobile.application_uninstalled (NP_APP_UNINSTALLED) notification.

    And note that to remove an application archive, the correct way is to use instproxy_remove_archive; as far as I know it is NOT enough to just remove the ZIP file from the ApplicationArchives folder, it is also stored somewhere else.

  • Matt Colyer

    Matt Colyer January 4th, 2010 @ 03:33 PM

    • State changed from “open” to “resolved”

    (from [daee8be013dae3821463fd85f4076ca2ab3adce6]) Add options to instproxy_archive function

    This change allows to specify the following options:
    - Archive only the application data - Do not uninstall the application.

    Combine these options with logical OR to specify both. These two options
    combined are used by iTunes to create app archives of on-device downloaded
    apps that are later copied as *.ipa files to the computer.

    [#104 state:resolved]

    Signed-off-by: Matt Colyer matt@colyer.name
    http://github.com/MattColyer/libiphone/commit/daee8be013dae3821463f...

  • Paul Sladen

    Paul Sladen January 4th, 2010 @ 03:39 PM

    Hmm. Seems my email from earlier this week didn't get through:

    Subject: Re: [libiphone #104] options FLAG names

    INSTPROXY_ARCHIVE_APP_ONLY - Archive only the application data INSTPROXY_ARCHIVE_SKIP_UNINSTALL - Do not uninstall the application.

    I've read this a few times and I'm still having difficulty following what
    happens in each case---which is perhaps an indication that the flags need
    renaming (or possibly inverting?).

    SKIP_UNINSTALL sounds like a double-negative, should it be just INSTALL

    Should APP_ONLY be perhaps DATA_ONLY; the interface is one for installing
    application packages, so repeating 'app' doesn't help.

    If the "Note that..." explanation is needed, something is non-obvious and
    perhaps it's possible to make it obvious instead.

    There may also be more to this than meets the eye; is
    uninstall(options=_INSTALL) perhaps a --reinstall?

    ApplicationArchives folder, it is also stored somewhere else.

    I would have thought that we add/insert it into the public AFC chroot, and
    then fire the API install/remove which unpackages it to the hidden
    /root; but that's only a hunch as I don't have the necessary to test that hypothesis.

  • Matt Colyer

    Matt Colyer January 4th, 2010 @ 03:46 PM

    • State changed from “resolved” to “open”

    Nope I don't have a copy of your email.

    Can you work up a proposed patch to change the names?

  • Nikias Bassen

    Nikias Bassen January 4th, 2010 @ 05:27 PM

    OK, the names might be a bit confusing, but remember those are for the function instproxy_archive which is not for installing an app but to make an archive of an installed app. And the names were taken from the plist protocol of the installation_proxy interface:

    INSTPROXY_ARCHIVE_SKIP_UNINSTALL
    
    This flag has it's name from the key 'SkipUninstall' which is set to 'true' before sending the 'Archive' command to the device, meaning not to uninstall the app for which an archive should be made. Without this flag the app will be archived AND uninstalled.
    INSTPROXY_ARCHIVE_APP_ONLY
    

    This flag has it's name from the key 'ArchiveType' which is set to the value 'ApplicationOnly' before sending the command to the device, meaning to just archive the app data itself without any user settings or files created by the app. This is basically what gives us an install package like iTunes stores them on the local compute (either from the device or out of the app store).

    I think the naming is OK as it just reflects the protocol.

  • Paul Sladen

    Paul Sladen January 4th, 2010 @ 05:42 PM

    Yup, still confusing. Perhaps the second (based on the key:value used in the protocol should be the (unabbreviated):

    INSTPROXY_ARCHIVE_TYPE_APPLICATION_ONLY

    which is a more honest following of the enum (reads better and looks less tacky). Are there any other enums for the "ArchiveType" parameter?

  • Martin S.

    Martin S. January 13th, 2010 @ 01:45 AM

    • Assigned user changed from “Matt Colyer” to “Paul Sladen”

    That way it actually should be INSTPROXY_ARCHIVE_CLIENT_OPTIONS_ARCHIVE_TYPE_APPLICATION_ONLY. Perhaps a bit weired.

    I think Nikias defines that INSTPROXY_ARCHIVE_* are flags for the "Archive" installation_proxy command's "ClientOptions".

    Each command appears to have it's own set of "ClientOptions. For instance install/upgrade has like "iTunesMetadata" so the additional "INSTPROXY*" grouping seems rational, or? Suggestions?

  • Nikias Bassen

    Nikias Bassen January 22nd, 2010 @ 01:56 AM

    • Assigned user changed from “Paul Sladen” to “Matt Colyer”

    Hi guys,

    I reworked the code to use plist client options for each function so we don't have to alter the service implementation when new client options show up. There are several function that don't have and probably will never have any client options, but to be prepared I added client options to every operation.
    I added some helper functions to allow easy handling of client options, e.g. for using the options ArchiveType:ApplicationOnly and SkipUninstall:TRUE when calling instproxy_archive you can simply do:

    plist_t opts = instproxy_client_options_new();
    
    // you can use just one call
    instproxy_client_options_add(opts, "ArchiveType", "ApplicationOnly", "SkipUninstall", 1, NULL);
    
    // OR you can separate them
    instproxy_client_options_add(opts, "ArchiveType", "ApplicationOnly", NULL);
    instproxy_client_options_add(opts, "SkipUninstall", 1, NULL);
    
    // do the operation
    instproxy_archive(client, "com.yourcompany.yourapp", opts, status_cb);
    
    instproxy_client_options_free(opts);
    

    If you want to perform operations without client options or operations that do not require any client options, pass NULL:

    instproxy_browse(client, NULL, &apps);
    

    So with the attached patch the above discussed naming issue has been solved ;)

  • Matt Colyer

    Matt Colyer January 22nd, 2010 @ 05:16 AM

    • State changed from “open” to “resolved”

    (from [1999ce8929dcad052e4af48f23daab2264b312e7]) installation_proxy: rework code to use plist client_options

    [#104 state:resolved] http://github.com/MattColyer/libiphone/commit/1999ce8929dcad052e4af...

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

A project around supporting the iPhone in Linux.

See http://libimobiledevice.org

Referenced by

Pages