I have an app that installs a DriverKit system extension when it launches.
If I then drag this app to the Bin from /Applications then I am prompted about that the app also manages a system extension and that the system extension also will be removed.
I would like to have an uninstaller that removes the app. I have tried to remove the app in the uninstaller with rm -rf, but then the system extension is not removed.
I have also tried the trash terminal utility (can be installed with brew install trash) to check if something similar could be used from the uninstaller, but without luck.
Is there a way to programmatically remove an app and also the system extension that the app installs.
Good question! I don't have a fully baked answer, but enough suggestions to try that they won't fit in a comment, so here goes anyway:
Try using Cocoa APIs for "trashing" files. This answer gives a good rundown. I don't know how this will cope with the system extension confirmation though.
If you definitely want to pop up the confirmation dialog, using AppleScript to tell the Finder to delete the file is a great approach. I can confirm the solution given in this answer works but it will show the confirmation dialog, which may or may not be what you want.
You can uninstall a system extension (including a dext) using the systemextensionsctl uninstall command. Unfortunately, this will always pop up an authentication dialog, even if you run it with root privileges. But depending on what you're doing, that might be preferable to the above.
Related
I want to create a new profile with an addon preinstalled.
What works:
run firefox a first time.
add the addon.xpi to profile/extensions/addon.xpi.
edit profile profile/extensions.ini and add Extension0=/full/path/to/extension.xpi.
start firefox again.
What i need:
add the addon to profile/extensions/addon.xpi.
edit extensions.ini or something similiar.
use only relative paths, if possible (seems not to be implemented for extensions.ini)
Finally i want to create a zip file with some firefox preferences/addons, which can be unziped into a profilefolder to create a fresh profile with some preinstalled stuff. For this, it would be important, that everything works with relative paths. If it is definitely not possible, i can add some script to it. But i would prefer some "just unzip" solution.
I think it may be a bit harder, because mozilla wanted to prevent other software from adding toolbars and similiar to firefox by making external addon installation harder. What i already found is the key extensions.autoDisableScopes=0.
What you can do is open firefox with command line options. And pass the file path to your xpi file, so you don't have to mess with all this internals you are over there.
So do this:
"C:\Program Files (x86)\Mozilla Firefox\firefox.exe" "C:\my.xpi"
and on launch it will open a tab and prompt to install your addon.
In the prefs.js:
pref("extensions.autoDisableScopes", 14); // 0x1 not set
See https://developer.mozilla.org/en-US/Add-ons/Installing_extensions#Disabling_install_locations
Then put the addons into extensions/myaddonid.xpi, making sure the filename is the id given in the install.rdf file inside the addon.xpi (zip-)file as <em:id>addon_id</em:id> tag.
On the next start the addons will be silently installed. Some addons needed one restart to work, at least the toolbar buttons were not added on the first start.
Not sure, if this will still work, when firefox decides to allow only addons signed by addons.mozilla.org. On the other hand, they will allow self-hosting addons, as soon as they are signed by AMO, so preinstalling addons downloaded from there will have a good chance.
I want to make my application autorun, like using autorun.inf on Windows. I googled and there is one way for me to do that:
"On the Mac side there are many applications you can buy for creating a Finder window that looks a certain way but all these changes can be made within finder. You then will need to copy the DS_Store file to the CD and finder will automatically apply any changes that you have made.
Also using -hfs-openfolder will cause it to open automatically when inserted on the mac."
Can anyone tell me more clearly about that, or is there any other way?
Thanks so much.
According to this page, you should be able to do that with bless:
sudo bless --folder "/Volumes/discName" --openfolder "/Volumes/discName"
The man page confirms that, at least on 10.6.8. I don't have Lion in front of me right now.
I have another question dealing with app sandboxing. So I need access to the users' home directory and at the same time the app should be able to shut down the Mac. This requires to not using sandboxing.
My problem is that I don't know how to remove sandboxing and being able to submit the app to the Mac App Store. I think that the archives are sandboxed because I had turned it on once..
How to remove sandboxing from the archives properly?
Thanks for your help!
On Xcode 11, you can turn off Sandboxing by removing it from the Signing & Capabilities tab:
If I understand what you are asking correctly, you'll need to remove the entitlements.plist from your project and make sure that the Summary view of your target in Xcode has sandboxing turned off:
As Derek Wade pointed out, you can make an App like GarageBand X (which behaves obnoxiously with third party plugins like Amplitube due to Sandboxing) NOT run in a sandbox by editing the binary itself with a HEX editor like HexFiend. Look for:
<key>com.apple.security.app-sandbox</key>
Immediately following that bit you'll see the true tag, which as suggested I switched to 'fals' (no extra bytes) and now GarageBand will happily interact with third party VST plugins. Huzzah.
I found if you go into the .app package, under Contents/MacOS, there should be a binary file that matches the name of your app. Copy that file to your desktop. Edit the desktop copy of the file with TextEdit. You should find within the file, the text representation (xml) of the Entitlements for the app. Find the Sandbox entitlement flag (usually set to <true/>) and change it to <false/>. You will have to unlock the file when editing. Save the file (located on the desktop). Rename the original file in the .app package (i.e. append .old to the filename). Copy the desktop file back to the .app Package location (you may have to authorize it). This should remove the sandboxing.
You cannot remove Sandbox if the user ran you application via Sandbox.
That's the whole point - don't you think ?
i have a problem, which is exactly as here http://compgroups.net/comp.sys.mac.apps/PackageMaker-not-installing-my-app (no solution is offered)
simply said, with PackageMaker i create an installer, which should just copy the .app inside /Applications
all goes well, the installer has the apropriate size of 150MB, the install starts, iam promped for the install location and admin password, i click install, progress shows up and a window that installation was successfull, but when i look at the Applications, or the custom folder specified, its nothing there
i tryed the PackageManager from Xcode 3 and also 4, but the result is the same, i also tryed to set the file permission for everybody, so they are world writable, but no success
Are you testing the installer on the same machine where you are building the installer? If you've set the "Allow Relocation" box a install will simply overwrite your already existing app you used for packaging instead of installing to /Applications.
Don't create the package just to move the app inside /Applications.
Just zip your app bundle so that it becomes YourApp.app.zip, which is a perfectly acceptable way to distribute your app. Then the user can place the app bundle (after unpacking the zip) wherever the user wants.
Do you have "Include root in package" enabled for the package's contents? See this answer for an explanation of what it does and why you probably need it.
I have written an application suite on Windows which amongst other things installs a Firefox add-on which once run modifies the Firefox network preferences by interfacing with nsIPrefService.
The extension itself resides in a folder under Program Files along with other parts of the application which work together with each other.
Since the application consists of a number of components, the correct way to uninstall it is via the Control Panel or via an uninstall shortcut I provide for the users.
I have no control over whether Firefox will be running or not when the user chooses to uninstall (possibly I could try to detect if it's running in the uninstaller and request the user close it to continue).
Since the purposes of the uninstaller is to remove all traces of the program from the end-users system i.e:
all the files under the Program Files folder, including the extension components
remove the add-on from Firefox (by removing the registry key under HKEY_CURRENT_USER\Software\Mozilla\Firefox\Extensions, causing the add-on to unregister on next Firefox restart)
remove application specific registry keys
Then after uninstall there isn't any of my code left on the users system capable of restoring the network preferences to what they were before the component was installed. This results in end-users not being able to browse the web and being very frustrated!
The only way I can figure out how to do this at the moment is to have my component write to the window's registry the location of the users profile folder - which I can do with my add-on:
Components.classes["#mozilla.org/file/directory_service;1"]
.getService(Components.interfaces.nsIProperties).get("ProfD",
Components.interfaces.nsIFile).path
And then have my uninstaller modify the prefs.js file in that location directly. But this will only work if I can guarantee Firefox isn't running during uninstall (since prefs.js is re-written on FF close)
To me this is not an elegant solution:
It seems not to be future proof since it is dependent on the format and symbols used prefs.js which may change in future FF releases.
Firefox has a nasty habbit of not always closing properlly (sometimes other installed add-ons prevent it from completely unloading from memory. This would break my uninstaller).
This wouldn't work (without elaborate modification) if the user has multiple FF profiles setup all using my add-on.
Is there a better or "standard" way to achieve this simple task?
Did you try to package defaults files (defaults/preferences/myprefs.js) in your extension? I didn't check if it works for overriding Firefox-wide defaults, but it should.
Can't the uninstaller "insist" that Firefox be closed? eg,
check if FireFox is open
if open, inform user "FF must be closed, or cancel uninstall" ok/cancel
loop
I've had several installers do this to me. Not unistallers, though, that I can remember.
Also, this doesn't future-proof the solution, nor deal with profiles.