|
|
webOS Nation Forums > webOS apps and software > webOS development > Installing homebrew apps w/out rooting
First ... 2 7 8 9 10 11 12 13 14 15
Originally Posted by as4life:
LOL dammit your right. I thought I deleted it but it appeared again.
Yeah...I haven't looked at their appinfo.json file, but I think that it needs to be tweaked. The bummer is, I'm not sure how you can easily delete this one without rooting your phone and manually deleting it. Perhaps it's possible without writing another app to do it, but I haven't given it much thought. No biggie if you have rooted though. It should be a quick delete from the command line.LOL dammit your right. I thought I deleted it but it appeared again.
This is why we test before we release.
Originally Posted by burntsky:
Could someone address this?
I blieve I failed to include vendorurl in the json file. Our main objective was proof of concept and to allow others to publish their applications.Could someone address this?
I've updated the wiki to help prevent this issue.
pre dev wiki: Installing Homebrew Apps on Stock Pre without Rooting - SUCCESS!
pre dev wiki: Installing Homebrew Apps on Stock Pre without Rooting - SUCCESS!
Originally Posted by scuba_steve:
Yeah...I haven't looked at their appinfo.json file, but I think that it needs to be tweaked. The bummer is, I'm not sure how you can easily delete this one without rooting your phone and manually deleting it. Perhaps it's possible without writing another app to do it, but I haven't given it much thought. No biggie if you have rooted though. It should be a quick delete from the command line.
This is why we test before we release.
I tried deleting it with ipkg remove command but it didn't work. Is there another way i need to do it?Yeah...I haven't looked at their appinfo.json file, but I think that it needs to be tweaked. The bummer is, I'm not sure how you can easily delete this one without rooting your phone and manually deleting it. Perhaps it's possible without writing another app to do it, but I haven't given it much thought. No biggie if you have rooted though. It should be a quick delete from the command line.
This is why we test before we release.
Originally Posted by simplyflipflops:
I blieve I failed to include vendorurl in the json file. Our main objective was proof of concept and to allow others to publish their applications.
I thought it was confirmed that the "vendorurl" parameter was not required in the appinfo?I blieve I failed to include vendorurl in the json file. Our main objective was proof of concept and to allow others to publish their applications.
I'm certainly not discrediting anyone for their work on this, but it seems like for a proof of concept, it doesn't PROVE anything except that you can get an icon in the launcher and if the effort to get an executable application working is negligible, why not have just done that in the first place to actually PROVE this proof of concept?
I'm sure I'm just ****ing people off now, but seriously, I don't understand why anyone would go through all this effort to prove they can install an application that doesn't actually run.
We'd love to work with you guys on this.
If you check - you'll see the app did install to the var/usr/ directory. (We've since taken the app down).
I re-packaged it using the instructions on predev but now it doesn't install.
My pre is rooted and I was able to go in to my var/usr directory and remove the app directory for our app, then go to my launcher and delete the icon.
If anyone has the app and can't wait for an uinstaller or fix, delete it from that directory and then delete the icon from your launcher.
I can't post a link, but let me know if you'd take a look at the ipk for us and help us out.
Thanks!
Mitch
If you check - you'll see the app did install to the var/usr/ directory. (We've since taken the app down).
I re-packaged it using the instructions on predev but now it doesn't install.
My pre is rooted and I was able to go in to my var/usr directory and remove the app directory for our app, then go to my launcher and delete the icon.
If anyone has the app and can't wait for an uinstaller or fix, delete it from that directory and then delete the icon from your launcher.
I can't post a link, but let me know if you'd take a look at the ipk for us and help us out.
Thanks!
Mitch
Deleting SimplyFlipFlops from a non-rooted Pre posed no problems, (even after reset) but PimpMyPre does not for some reason? Even though they were stored in the same file structure?
Originally Posted by sir_mycroft:
Deleting SimplyFlipFlops from a non-rooted Pre posed no problems, (even after reset) but PimpMyPre does not for some reason? Even though they were stored in the same file structure?
There's obvious "some" difference, but I can't find it. Deleting SimplyFlipFlops from a non-rooted Pre posed no problems, (even after reset) but PimpMyPre does not for some reason? Even though they were stored in the same file structure?
When I installed and deleted simply flip flops, it worked, but not for the ringtone app. When I went in to my rooted pre and looked at the directory, it was where it should be and (funny thing) simply flip flops was still in the directory, although it wasn't in the launcher.
So, we're not deleting at all, and it doesn't look like the other one is completely deleting either.
That's why we're reaching out -combine ideas.
I am refreshing this page every minute awaiting an install link. This is a great opportunity for apps that may not be approved by Palm to be on the Pre without rooting and learning Linux programming.
thank you for refreshing the addiction.
thank you for refreshing the addiction.
Finally got my FlipFlop app, LOL! I was emailing the link into my texts and not retrieving it through email. That is were people like me were getting the continuous cards from. All good now
I was experimenting last night trying to modify simplyflipflops's example application, repackage it, and link to the new version in an email, but with very little success.
If I extracted the IPK (ar -x), deleted the .pem and signature files, re-signed using OpenSSL, and repackaged the IPK (ar -r), it still installed the icon in the launcher, so creating OpenSSL certs was obviously working.
However, if I unpacked control.tar.gz and immediately repacked control and rules (i.e. simply created my own control.tar.gz using the same files), then signed and packaged the IPK, I no longer got the launcher icon.
I experimented with several versions of tar and gzip and various format options (the file size of my re-packed control.tar.gz was always different than the one included in simplyflipflops's IPK), but to no avail. The icon would no longer appear in the launcher when email-clicking the IPK.
Can anyone explain why this might be the case? My thoughts have ranged as far as end-of-line character conversion somewhere in the re-tar process, but I'm skeptical. I repeated the results above (successful first step, unsuccessful subsequent steps) packaging my new IPK on Fedora Core 6, Fedora Core 9, and Cygwin. I'm curious as to what platform (and version of tar) simplyflipflops was using - unless of course I've missed something critical.
If I extracted the IPK (ar -x), deleted the .pem and signature files, re-signed using OpenSSL, and repackaged the IPK (ar -r), it still installed the icon in the launcher, so creating OpenSSL certs was obviously working.
However, if I unpacked control.tar.gz and immediately repacked control and rules (i.e. simply created my own control.tar.gz using the same files), then signed and packaged the IPK, I no longer got the launcher icon.
I experimented with several versions of tar and gzip and various format options (the file size of my re-packed control.tar.gz was always different than the one included in simplyflipflops's IPK), but to no avail. The icon would no longer appear in the launcher when email-clicking the IPK.
Can anyone explain why this might be the case? My thoughts have ranged as far as end-of-line character conversion somewhere in the re-tar process, but I'm skeptical. I repeated the results above (successful first step, unsuccessful subsequent steps) packaging my new IPK on Fedora Core 6, Fedora Core 9, and Cygwin. I'm curious as to what platform (and version of tar) simplyflipflops was using - unless of course I've missed something critical.
Originally Posted by pimpmypre:
There's obvious "some" difference, but I can't find it.
When I installed and deleted simply flip flops, it worked, but not for the ringtone app. When I went in to my rooted pre and looked at the directory, it was where it should be and (funny thing) simply flip flops was still in the directory, although it wasn't in the launcher.
So, we're not deleting at all, and it doesn't look like the other one is completely deleting either.
That's why we're reaching out -combine ideas.
If anyone has looked at the findapps codebase it states in the comments that there is no logical way to "uninstall" applications as of yet. That simply means that your launcher application removes the icon but the code will remain in the filesystem. I see this as a "virtual memory leak" long term especially as more (and larger) apps become available. I am sure Palm is working on this portion of the code and we should see a modified version of the app catalog in the near future.There's obvious "some" difference, but I can't find it.
When I installed and deleted simply flip flops, it worked, but not for the ringtone app. When I went in to my rooted pre and looked at the directory, it was where it should be and (funny thing) simply flip flops was still in the directory, although it wasn't in the launcher.
So, we're not deleting at all, and it doesn't look like the other one is completely deleting either.
That's why we're reaching out -combine ideas.
Originally Posted by simplyflipflops:
If anyone has looked at the findapps codebase it states in the comments that there is no logical way to "uninstall" applications as of yet. That simply means that your launcher application removes the icon but the code will remain in the filesystem. I see this as a "virtual memory leak" long term especially as more (and larger) apps become available. I am sure Palm is working on this portion of the code and we should see a modified version of the app catalog in the near future.
Were you able to verify this with the tip calculator app as well? This does seem like a bit of an issue until it can be fixed.If anyone has looked at the findapps codebase it states in the comments that there is no logical way to "uninstall" applications as of yet. That simply means that your launcher application removes the icon but the code will remain in the filesystem. I see this as a "virtual memory leak" long term especially as more (and larger) apps become available. I am sure Palm is working on this portion of the code and we should see a modified version of the app catalog in the near future.
Originally Posted by sir_mycroft:
Were you able to verify this with the tip calculator app as well? This does seem like a bit of an issue until it can be fixed.
I have not installed the tip calculator.Were you able to verify this with the tip calculator app as well? This does seem like a bit of an issue until it can be fixed.
Originally Posted by quailish:
I was experimenting last night trying to modify simplyflipflops's example application, repackage it, and link to the new version in an email, but with very little success.
If I extracted the IPK (ar -x), deleted the .pem and signature files, re-signed using OpenSSL, and repackaged the IPK (ar -r), it still installed the icon in the launcher, so creating OpenSSL certs was obviously working.
However, if I unpacked control.tar.gz and immediately repacked control and rules (i.e. simply created my own control.tar.gz using the same files), then signed and packaged the IPK, I no longer got the launcher icon.
I experimented with several versions of tar and gzip and various format options (the file size of my re-packed control.tar.gz was always different than the one included in simplyflipflops's IPK), but to no avail. The icon would no longer appear in the launcher when email-clicking the IPK.
Can anyone explain why this might be the case? My thoughts have ranged as far as end-of-line character conversion somewhere in the re-tar process, but I'm skeptical. I repeated the results above (successful first step, unsuccessful subsequent steps) packaging my new IPK on Fedora Core 6, Fedora Core 9, and Cygwin. I'm curious as to what platform (and version of tar) simplyflipflops was using - unless of course I've missed something critical.
I don't think it's a signing issue. This is where I would look/change first...I was experimenting last night trying to modify simplyflipflops's example application, repackage it, and link to the new version in an email, but with very little success.
If I extracted the IPK (ar -x), deleted the .pem and signature files, re-signed using OpenSSL, and repackaged the IPK (ar -r), it still installed the icon in the launcher, so creating OpenSSL certs was obviously working.
However, if I unpacked control.tar.gz and immediately repacked control and rules (i.e. simply created my own control.tar.gz using the same files), then signed and packaged the IPK, I no longer got the launcher icon.
I experimented with several versions of tar and gzip and various format options (the file size of my re-packed control.tar.gz was always different than the one included in simplyflipflops's IPK), but to no avail. The icon would no longer appear in the launcher when email-clicking the IPK.
Can anyone explain why this might be the case? My thoughts have ranged as far as end-of-line character conversion somewhere in the re-tar process, but I'm skeptical. I repeated the results above (successful first step, unsuccessful subsequent steps) packaging my new IPK on Fedora Core 6, Fedora Core 9, and Cygwin. I'm curious as to what platform (and version of tar) simplyflipflops was using - unless of course I've missed something critical.
1) Change your namespace. "com.pimpmypre.appname2" in your appinfo.json file
2) Change your folder structure to be the same as the namespace change in your appinfo.json file
3) Re-sign and retry the install
Alternatively you could be looking through your db3 files for reference to your package and remove those as well which could remove the signature cached.
My hypothesis is that the Luna system caches the package information (perhaps including a signature) to ensure the application remains constant which is why the signing verifies but does not reinstall as the signature changes when file changes occur in your data.tar.gz file. Remove references to your app in any database file (downloadhistory.db3 comes to mind off hand).
If my memory serves me correctly I also believe that when installing a native app through the findapps module there may be some communication with the palm server upon correctly installing that includes your device ID, your wireless carrier, your palm email address and the package information "appid". I have not tested or confirmed these assumptions to see if this information is truly sent back to palm with a simplyflipflops package installation but I do see it in the logs.
Let us know if one of these two approaches works for you and it will confirm my assumptions.
Originally Posted by simplyflipflops:
I have not installed the tip calculator.
Anyone?I have not installed the tip calculator.
BTW: Reving up the version won't work either.
That explains simplyflipflops - now just need to find out why our icon doesn't get removed.
Thanks for the tips simplyflipflops! I'll start looking, but I need a way for non-rooted pre's and changing the app id shouldn't matter. (in theory)
Also, my app "updates" with my new code when the link is re-sent, so ooverwriting the app works.
I could add code to the app to destroy itself, but that seems beyond what I should have to do.
Thanks for the tips simplyflipflops! I'll start looking, but I need a way for non-rooted pre's and changing the app id shouldn't matter. (in theory)
Also, my app "updates" with my new code when the link is re-sent, so ooverwriting the app works.
I could add code to the app to destroy itself, but that seems beyond what I should have to do.
Originally Posted by simplyflipflops:
Alternatively you could be looking through your db3 files for reference to your package and remove those as well which could remove the signature cached.
My hypothesis is that the Luna system caches the package information (perhaps including a signature) to ensure the application remains constant which is why the signing verifies but does not reinstall as the signature changes when file changes occur in your data.tar.gz file. Remove references to your app in any database file (downloadhistory.db3 comes to mind off hand).
Interesting. I'd considered briefly that it was a cache issue on the phone itself, but was hoping otherwise, as my Pre is not rooted. (Something tells me it's only a matter of time, however, unless Palm surprises me with an early access SDK invite very soon.)Alternatively you could be looking through your db3 files for reference to your package and remove those as well which could remove the signature cached.
My hypothesis is that the Luna system caches the package information (perhaps including a signature) to ensure the application remains constant which is why the signing verifies but does not reinstall as the signature changes when file changes occur in your data.tar.gz file. Remove references to your app in any database file (downloadhistory.db3 comes to mind off hand).
Is it possible the issue might lie with the fact that the /usr/palm/applications/com.simplyflipflops files are not being deleted when the launcher icon is deleted? I can consistently get your original (simplyflipflops) IPK to install the launcher icon - perhaps it's not overwriting the existing files, and as a result refuses to install the launcher icon for an IPK whose signature doesn't match the existing certs, but is happy to re-add the launcher icon for the same IPK (with the same signature).
I did also try creating an entirely custom IPK using a /var/usr/palm/... structure in data.tar.gz, also based on your (simplyflipflops) IPK, using a different application namespace etc. My new control.tar.gz and data.tar.gz looked good (so far as I could tell given the wiki instructions), but I couldn't get a launcher icon to appear using my modified control and appinfo.json files. It was after failing at this that I decided to take a few steps backward to see where during my modifications the process had failed, but now it seems that I can't backstep too far before I've returned to the com.simplyflipflops namespace and encounter an entirely new set of problems (if caching or preexisting files are indeed the issue).
I'm feeling rather limited by my lack of root access, but I was really hoping to demonstrate that applications could be installed and tested consistently on a stock Pre, so I'm still holding out.
i too am holding out to test drive new apps, is there any progress on pimpmypre?
First
...
2 7 8 9 10 11 12
13 14 15
webOS Nation Forums > webOS apps and software > webOS development > Installing homebrew apps w/out rooting
