How do you download the Android support library via the command line?
For example:
echo y | android update sdk --no-ui --filter "android-19"
echo y | android update sdk --no-ui --all --filter "extra-android-m2repository"
android command is deprecated now
You can use sdkmanager instead like so:
sdkmanager --install "extras;android;m2repository"
sdkmanager "extras;android;m2repository"
worked for me.
I ran in to the error: Warning: File /var/root/.android/repositories.cfg could not be loaded.
so I had to create that file before running the above command.
touch ~/.android/repositories.cfg
The sdkmanager should be your go to. Otherwise, there is another way which is what sdkmanager will do automatically. So, there are dangers to this, one typo and the whole thing will not work. Go to Google Sources repository and choose either support or m2repository and download by clicking the tgz/archive link under the breadcrumbs.
Or use;
wget https://chromium.googlesource.com/android_tools/+archive/master/sdk/extras/android.tar.gz
The second option downloads a bigger file size (and two versions of the support library but neither is the newer androidX referenced on the official Android development page). But, both will give you a zipped archive with the Android support library. Go to your directory and create the extras directory. Use "extras/android" as a file path and unzip (use tar xvfj) your archive into it;
unzip <archive file>
mv -R <unzipped directory> <Android SDK home>/extras/android/
mv -R <unzipped and moved directory> <support>
Or
tar xvjf <archive file>
mv -R <unzipped directory> <Android SDK home>/extras/android/
mv -R <unzipped and moved directory> <support>
You should now have the Android support library installed in your SDK package.
Further support in use.
Related
While trying to install and configure Zotero using a bash script, I'm encountering some difficulties in adding an .xpi addon using bash. The documentation says:
To install a plugin in Zotero, download its .xpi file to your
computer. Then, in Zotero, click “Tools → Add-Ons”, then drag the .xpi
for the plugin onto the Add-Ons window that opens.
My closest approach was simulating the "open with" option and chosing "Zotero". However, even when using "open with" manually, Zotero assumes the incoming file is a literature file instead of an addon file. So the implementation:
#!/bin/bash
zotero some.xpi
Analogous to option 1 of this answer, launches Zotero, yet it does not (prompt the user to) install the add-on.
I did not yet find an API or method to load the add-on automatically. Hence I would like to ask: How can I add an arbitrary .xpi add-on for Zotero from a bash script?
The instructions in the documentation did not work for me, so I found out another method:
One can
Download the Zotero standalone version
Get the add-on source code
Compile the add-on into a build directory that contains an install.rdf file
Copy this build directory into the /modules/ directory of the Zotero Standalone Build repository
Compile the Zotero Standalone Build repository into a build (exported to /staging/<your system architecture>/)
Add the instructions to include the new addon when Zotero loads, into the /staging/<your system architecture>/defaults/prefs.js file.
Start zotero using: ./zotero.
git clone --recursive https://github.com/zotero/zotero-standalone-build
...
npm run build
git clone git#github.com<your zotero extension>.git
# Switch out build file to add additional plugin
cp -r "src/build.sh" "src/submodules/zotero/zotero-standalone-build/build.sh"
..
npm build
...
staging/Zotero_linux-x86_64/zotero -purgecaches
I created a modified build.sh file for the zotero-standalone-build which adds the extensions to the prefs.js file with:
echo 'pref("extensions.something.unopkgPaths", "{}");' >> "$APPDIR/defaults/preferences/prefs.js"
echo 'pref("extensions.something.version", "");' >> "$APPDIR/defaults/preferences/prefs.js"
echo 'pref("extensions.something.installed", false);' >> "$APPDIR/defaults/preferences/prefs.js"
echo 'pref("extensions.something.skipInstallation", false);' >> "$APPDIR/defaults/preferences/prefs.js"
The build command specifics depend on the addon you want to include.
Is there an easy way to show a diff between two different versions of one Composer package? Of course, I could manually or semi-automatically download the two versions and then manually run a diff on them. However, it would be quite handy to have a command like
composer diff namespace/module 1.0.0 1.0.1
This would show a diff between the versions 1.0.0 and 1.0.1 of package namespace/module, so that I can easily review what has changed.
Is there any smart way to do that?
It would even be nicer if I could see the diff in PhpStorm.
Assuming you are in the project directory, JQ must be installed.
It installs both package versions in temp folders and compares them.
Usage: ./composer-diff.sh foo/bar 1.0.0 2.0.0
#!/bin/bash
PACKAGE=$1 # namespace/module
OLD=$2
NEW=$3
PROJECT=`pwd`
TMPBASE=/tmp/$$
mkdir -p $TMPBASE/$OLD
mkdir -p $TMPBASE/$NEW
jq '{repositories}' composer.json > $TMPBASE/$OLD/composer.json
jq '{repositories}' composer.json > $TMPBASE/$NEW/composer.json
cp auth.json $TMPBASE/$OLD
cp auth.json $TMPBASE/$NEW
cd $TMPBASE/$OLD
composer require $PACKAGE $OLD
cd $TMPBASE/$NEW
composer require $PACKAGE $NEW
set +x
diff -ur $TMPBASE/$OLD/vendor/$PACKAGE $TMPBASE/$NEW/vendor/$PACKAGE > $PROJECT/composer-package.diff
Now the resulting composer-package.diff file can be openend in any editor.
I stumbled upon this while documenting myself about the existence of such a command for my other question. A similar feature was suggested in the Composer issue tracker previously. The author of that proposal made it into a separate tool, available here (looks old, working status unknown). I'm not sure it covers your exact case, tough.
I’m having an odd issue where my installer properly overwrites the previously installed app, but then overwrites the app in my build directory.
My installer build looks like this:
mkdir /tmp/foo
cp -R ~/Projects/MyApp/Builds/MacOSX/build/Release/MyApp.app /tmp/foo
pkgbuild --quiet --analyze --root /tmp/foo/ MyApp.plist
pkgbuild --quiet --root /tmp/foo/ \
--component-plist MyApp.plist \
--identifier com.mycompany.myapp \
--version $VERSION \
--install-location "/Applications" \
MyApp.pkg
productbuild --quiet --distribution "./Distribution.xml" \
--package-path "./" --resources "./Resources" \
--sign "Developer ID Installer: My LLC" "MyApp Installer.pkg"
Now, this works…it installs the app in the /Applications folder as I’d expect. But I was noticing some issues with my next Xcode build. After some investigating, I noticed that my build folder looked like this after the Xcode build and before running the installer:
drwxr-xr-x# 3 me staff 96 Jul 11 23:15 My.app
…and like this, AFTER running the installer:
drwxr-xr-x 3 root wheel 96 Jul 11 23:44 My.app
Somehow, the owner of my app had changed. I double checked everything and didn’t see anything that touched my build folder. But then I checked the installer log and found this mysterious line:
PackageKit: Applications/MyApp.app relocated to
Users/me/Projects/MyApp/Builds/MacOSX/build/Release/MyApp.app
After some googling, others have speculated that the installer overwrites ANY copy of the app it finds anywhere on the drive…not just the one in the folder you tell it. It makes some sense…if I delete that copy of my app in the build folder, the installer doesn’t create a new one. It only overwrites it if it’s there.
While this isn’t a huge problem, it’s somewhat problematic as it changes the owner of the file which prevents the next build from working.
Has anyone else run into this issue? Is there some option for the installer to NOT overwrite EVERY copy of the installed app?
The Installer has a few features that allow it to locate application bundles that have moved in the file system. Inside your compiled .pkg, have a look at the PackageInfo and Distribution files, and see if you see any <locator> tags. The <locator> tag is defined at the link below, and is one of the main ways to enable this sort of thing.
https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/DistributionDefinitionRef/Chapters/Distribution_XML_Ref.html#//apple_ref/doc/uid/TP40005370-CH100-SW15
Another possibility is that you may have a <bundle> element with the search property set, as documented here:
https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/DistributionDefinitionRef/Chapters/Distribution_XML_Ref.html#//apple_ref/doc/uid/TP40005370-CH100-SW36
If you want to easily inspect the internal structure of your compiled package, you can use Pacifist to do that fairly easily. (disclaimer: I'm the author of Pacifist)
It's just a hunch, but I wonder if this can be solved by forgetting the current installs of your app by dropping the installation receipts like this:
sudo pkgutil --forget com.mycompany.myapp.pkg
You can get a list of all package receipts on your machine like this:
sudo pkgutil --pkgs
The reason I have this hunch is because I think the install locations might be stored in the receipts. Therefore causing the machine to "forget" (delete) where the packages are might make it so the installer has to install at the specified location specified by the package. I fully admit this is a WAG (wild-ass guess).
With Xcode 8.3 PackageApplication is gone. I did use it to convert an *.app package/directory to a *.ipa file (after re-signing):
xcrun -sdk iphoneos PackageApplication -v "MyApp.app" -o "MyApp.ipa"
Is there any replacement for this, so I can continue to convert .app to .ipa?
Apparently there is no need to use any other tool, and it's also not necessary to change the process that leads to the *.app package (in other words: no need to use xcodebuild -exportArchive).
All we have to do, is to zip that *.app package:
pushd "/build"
mkdir ./Payload
cp -R "$PATH_TO_SIGNED_APP_PACKAGE.app" ./Payload
zip -qyr MyApp.ipa ./Payload
rm -r ./Payload
popd
Note:
Jump into the target directory, here /build. This ensures we don't have the full path in the zip archive later.
Create a folder named Payload (important, this cannot vary)
Copy the *.app bundle to the Payload folder
Zip the folder and instead of *.zip use *.ipa as extension
Jump back to where you came from
Another workaround would be to put a copy of the PackageApplication tool from a previous Xcode into the Xcode 8.3 directory
Get the PackageApplication script from Xcode 8.2.1 here: https://gist.github.com/anonymous/48f3e4c5ae25313dc0fe10d9ec50c3fc
Remember to make it executable
chmod +x PackageApplication
Then drop it into your 8.3 Xcode.app as
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/PackageApplication
This is the error:
xcrun: error: unable to find utility "PackageApplication", not a developer tool or in PATH
It looks like PackageApplication is removed from Xcode 8.3.
In Xcode 8.2 there was a warning: PackageApplication is deprecated, use xcodebuild -exportArchive instead.
I am trying to create an installer for a Java app on Mac OS 10.8.4. The app runs fine, and I can install it without a hitch from a zip file. I can create a .pkg installer with either productbuild or pkgbuild. I can also install either of the installer .pkg file successfully, however the app does not run properly due to the fact that both packaging programs change the ownership of a data directory and its subordinate files and subdirectories from user to root. I install this data directory in the Resources directory of the .app bundle, and the first time the program executes, it moves the data directory to /Users/user/Library/Application Support. I tried using the --ownership preserve and --ownership preserve-other options with pkgbuild to no avail. The only way I have been able to install and execute properly is via the zip file, since it leaves file ownership alone. Here is the pkgbuild command I am using:
pkgbuild --ownership preserve --component ./myApp.app ./myApp-installer.pkg
My questions are:
How can I force pkgbuild to honor my --ownership preserve option?
Is it possible to build a separate data-only package with user ownership and destined for the user area and merge it with the executable package via the --synthesize option of pkgbuild? if yes, could someone show me how to build such a data-only package?
I know it is quite old, I'll just answer in case someone else needs the answer.
What I usually do, is that I have a shell script which creates the .pkg file for me. In that script I set all the file permissions and ownership before packaging. Here is an example:
NAME="PKGFILENAME"
IDENTIFIER="com.pkg.APPNAME"
VERSION="1.0.0"
INSTALL_LOCATION="PATH_TO_WHERE_THE_FILES_SHOULD_BE_COPIED_ON_USERS_MACHINE"
ROOT_LOCATION="PATH_TO_WHERE_FILES_ARE_ON_YOUR_MASCHINE"
# Remove any unwanted .DS_Store files.
find "$ROOT_LOCATION" -name '*.DS_Store' -type f -delete
# put any command for changing the ownership or permissions here
chmod -R +r "$ROOT_LOCATION"
# Build package.
/usr/bin/pkgbuild \
--root "$ROOT_LOCATION" \
--install-location "$INSTALL_LOCATION" \
--identifier "$IDENTIFIER" \
--version "$VERSION" \
"$NAME.pkg"
save this something in a file like create-my-package.sh and run this in command line.