I run my .apk file from eclipse to BlackBerry Playbook. It runs successfully. After that, when I sign my application for BlackBerry App World from Eclipse, it successfully signs it and gives me bar file in dist folder. However that file is marked crossed which indicates that the bar file contains an error. I don't know how to debug the error. I have made 2 layouts: one layout for Playbook and the other for BlackBerry Alpha 10. Is this causing an error or is it something else?
This APK was already packaged and signed, please update the APK’s version number to package again
This error means you are signing the same build again, with the same version no. Blackberry signer identifies the debug build and release build both as same, as they have same version no. So to overcome this, just change the version no. of the release build. It'll work without any problem.
Related
I'm developing a game for Mac App Store from Unity in which I have a plugin created in Xcode as .bundle file. I am able to codesign and package my game via terminal but problem appears when I try to submit package via Application Loader. I will try to explain everything thoroughly:
Package gets uploaded on iTunes Connect but at the end I get following warning:
WARNING ITMS-90239: "Invalid
Signature. A sealed resource is
missing or invalid. The binary at path
[Panda Commander Air
Combat.app/Contents/Plugins/InAppPurchase.bundle/Contents/MacOS/InAppPurchase]
contains an invalid signature. Make
sure you have signed your application
with a distribution certificate, not
an ad hoc certificate or a development
certificate. Verify that the code
signing settings in Xcode are correct
at the target level (which override
any values at the project level). If
you are certain your code signing
settings are correct, choose "Clean
All" in Xcode, delete the "build"
directory in the Finder, and rebuild
your release target."
I can click on "Next" and finish my submit, but this warning must be resolved because I get mail from iTunes Connect with issues that must be corrected:
UNABLE TO SIGN - This package doesn't
meet the current code signing
requirements. For more information,
see the Code Signing and Application
Sandboxing Guide [1] and Technical
Note 2206 [2].
Specifically, codesign generated the
following error:
webelinx.appstore.panda.pkg/Payload/Panda
Commander Air
Combat.app/Contents/Plugins/InAppPurchase.bundle:
unsealed contents present in the
bundle root
Once these issues have been
corrected, you can then redeliver the
corrected binary.
[1]
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html
[2]
https://developer.apple.com/library/mac/technotes/tn2206/_index.html
My plugin actually IS signed in Xcode, I've created new bundle ID and distribution provisioning profile for Mac App Store specifically for this plugin and setup everything in Code Signing tab. Code signing identity is 3rd Party Mac Developer Application and appropriate provisioning profile is selected. When I build this bundle it asks me to allow codesigning, and afterwards when I check it with "codesign -dvvv" command in terminal I can see codesign details. If I don't codesign it, I get another warning when I upload my package which says that bundle is not signed at all. I even tried to do a "Clean all", delete "build" directory and rebuild bundle as suggested in warning, but it has no effect, warning appears again.
How can resolve this warning? Am I missing something important or trying to fix things in wrong way?
Any help will be appreciated because I am out of options at the moment.
Thanks in advance!
OK, I solved my problem. I was missing few things and I found solution here: http://forum.unity3d.com/threads/signing-mac-app-on-os-x-mavericks.206762/.
The thing I still had to do was to manually codesign every file in Contents/Frameworks and Contents/Plugins directories inside .app file and to delete all .meta files inside my plugin. After I did these steps, I codesigned once more whole .app file and created a package which I uploaded on iTunes Connect without warning mentioned above.
I am trying to install the Blackberry 10 SDK as well as the PlayBook SDK for Blackberry and can't get the signing to work. I set up the signing and registered the keys for the Blackberry 10 SDK no problem. I then installed the Blackberry PlayBook SDK and then tried to register the keys for it also. I tried to register the same keys as for the BB10 SDK and new keys just for the PB SDK and in both cases I get the error "Error: Already registered with RDK". When I build the BB10 app it works okay and builds the app with signing. When I try to build the PB app I get the message "Cannon sign the application - failed to find signing keys".
I have read through the documentation and I can't see anywhere on how to set up signing with multiple SDK's on one machine. I am sure this can be done, but can't seem to figure out how it should be done to get the singing working.
SDK's:
BB10-WebWorks-SDK_1.0.4.11
WebWorks-Tablet-Win-v2.2
OS: Windows 8
You do not need to register code signing keys more than once.
When you were emailed the *.csj files from BlackBerry, you installed them on your machine using these instructions:
https://developer.blackberry.com/html5/documentation/signing_setup_bb10_apps_2008396_11.html
Doing so generates *.p12 and *.db and *.csk files in the following folder:
%HOMEPATH%\Local Settings\Application Data\Research In Motion
Both the BB10 and PlayBook WebWorks SDK should be able to re-use these files for signing. If they cannot find the signing keys, I suspect your system has the %HOMEPATH% variable set to the wrong location.
Try installing both SDKs to the same /Program Files folder and make sure that %HOMEPATH% is correct.
I have an application ready for internal distribution. I created the manifest file and a simple download page in order to download the app from a personal server.
If the app is not installed in the device, the application is downloaded and installed without problems.
Once the app is installed, If I hit the download button again, iOs ask me if I want to install the app, just like the first time, and then the download starts.
After the second download finishes, I tap on the icon but the application refuses to start and the console on the iPhone Configuration Utility throws the following
The 'MyApp' bundle at /private/var/mobile/Applications/15F088EB-B996-48CE-8331-A5CE85CDD74F/myapp.app does not have an executable path. Please check the bundle's Info.plist file.
Weird things:
1 - When having this error, if I shut down the device by holding the sleep button a few seconds and restart the device again, the app start working again.
2 - Let's say I myapp.app that has a bundle version 1.0 hosted in my server. I install it on the device for the first time and it works. Then I upgrade the hosted version to a bundle version 2.0 and perform the same download again, the app upgrades and launches without problems.
Question 1: Any ideas?
Question 2: Is there a way to handle this version difference? I mean, as a simple workaround, it would be great if I can display something like: "Your version is up to date" and do not download the new package
Thanks!!!
The solution worked for me is really simple. Before deploying a new version, modify the "Bundle version" and "Bundle version string, short" values in the Info.plist file to reflect a new version. For example if the installed app has "Bundle version" 1.0, use 1.1. Same for Bundle version string, short too.
I had exactly the same issue and have found a Strange solution using windows unzip and zip...
The cause of this problem for me was repackaging the ipa with a customer specific file after the initial build. So this may or may not work for you as I do not know the root cause of your problem.
My ipa, installation plist and an installation html file are hosted on an internal Windows Server 2003 running Tomcat.
Forgot to add this before, but the 'zip/unzip' used were from Symbian common files...
Required Installations: (We install these by default as part of our client customer build and provisioning systems)
Perl (ActivePerl 5.6.1)
S60 3RD EDITION SDK FOR SYMBIAN OS (9.1)
SOLUTION:
Ensure path includes "C:\Program Files\Common Files\Symbian\tools" and "..\Perl\bin"
open a prompt at the location of the ipa file.
Unzip the ipa using "unzip myapp.ipa" after which you should see the 'Payload' folder.
Re-zip the package using "zip -r mynewapp.ipa Payload"
and viola, for me the newly zipped ipa can be installed over itself without causing the error you and I were both seeing.
I'm not sure if any other zip/unzip will work in the same way as Symbians tools do, but as I require it to be installed for legacy s60 provisioning that is what I used. This solves my issue so I've now scripted a deployment mechanism that does this re-zipping when releasing a new version.
When creating the deployment script I also found that the zip command produced different results if not run from the same directory as the files. The resulting ipa in that case was uninstallable, so make sure you change to the directory containing the ipa before using unzip and zip.
Hope this is of some help.
You should specify two keys (CFBundleVersion & CFBundleShortVersionString) in Info.plist.
CFBundleVersion (String - iOS, OS X) specifies the build version number of the bundle, which identifies an iteration (released or unreleased) of the bundle. The build version number should be a string comprised of three non-negative, period-separated integers with the first integer being greater than zero. The string should only contain numeric (0-9) and period (.) characters. Leading zeros are truncated from each integer and will be ignored (that is, 1.02.3 is equivalent to 1.2.3). This key is not localizable.
CFBundleShortVersionString specifies the release version number of the bundle, which identifies a released iteration of the app.
You can add the CFBundleVersion by 1 every time when you build an adhoc version for your test or user with the same release version(CFBundleShortVersionString)
For example : your CFBundleShortVersionString is 1.2.3, your CFBundleVersion is 1000. when you fix a bug and build an adhoc version for testing, you can change CFBundleShortVersionString to 1001.
I'm getting this error when trying to build:
The entitlements specified in your application’s Code Signing Entitlements file do not match those specified in your provisioning profile.
(0xE8008016).
This is not my first time building apps. This will be my sixth app, so this thing is tripping. I'm making an AppStore distribution build, so I dont need entitlements. I dont have any entitlement files specified in my code signing entitlement. ITS BLANK. For the project info pane and the target info pane, there is absolutely nothing in my code signing entitlements, which is how its supposed to be. Yet I still get this dumb error. Remember, this is NOT an adhoc build, rather it is an AppStore build. What can be the problem??
Do you have multiple versions of Xcode installed (such as one of the betas)? Did you change the install directory after installing your current stable version of Xcode? Xcode installs things for code signing that can break if you either install a new version of Xcode simultaneously, or you rename your /Developer directory.
Also, try checking the console for related error messages.
I would like to find a way to compile and package our iPhone application as part of our automated nightly build. At present we always have to manually kick off a build on a shared Mac that has the adhoc certificates installed on the box and then post the resulting test binaries some place where testers can pull them down and install them.
Has anyone found an approach to automation that works for them?
There's a command line tool to build Xcode projects: xcodebuild
Try using xcodebuild, it'll build an Xcode project from the command line. You can then pull the binaries out of the build directory.
I wrote an XCodeBuilder (it calls xcodebuild) for CruiseControl that is now part of the standard release. We used this on an app that is now in the app store and it was great. After every commit a version of the app w/the ad-hoc signature was ready for download and testing by the rest of the team.