When i am trying to run a video with embedded ID in the OOyala player, i am getting like "Widevine can only run on ARMv7".
NSLog(#"video id= %# ",videoID);
self.ooyalaPlayerViewController = [[OOOoyalaPlayerViewController alloc] initWithPcode:PCODE domain:PLAYERDOMAIN];
// Attach it to current view
[self addChildViewController:_ooyalaPlayerViewController];
[self.ooyalaPlayerViewController.view setFrame:self.videoPlayerView.bounds];
[self addChildViewController:self.ooyalaPlayerViewController];
[self.videoPlayerView addSubview:self.ooyalaPlayerViewController.view];
// Load the video
[self.ooyalaPlayerViewController.player setEmbedCode:videoID];
// Add observers
[self addObserversForOoyalaVideoplayer];
[self addCloseButton];
[self.ooyalaPlayerViewController.player play];
I added that line a while back when I still worked at Ooyala.
Basically, the Widevine playback library for iOS is only distributed in compiled ARM binaries. The simulator runs natively on x86, so it can't load the library (I believe is purposeful, as it makes the DRM code slightly harder to reverse engineer), and we issue a warning.
Try playing it back on an actual device and everything should work fine.
In our case, we were testing on the iPhone 5S, which can't really be ignored.
As it turns out, the issue was that we left the project files configurations as they are, which added arm64 support to the build, and that broke the player. All we had to do was override the architecture configuration in all the project files and build.
Set valid and build architectures in the build settings to armv7 and try to run the application it will work.
Related
When I try to run project on real device (iPhone 5 and 5S with iOS 8.1) I get following compiler errors:
// ARC Semantic Issue - myPath/SDWebImage/UIImage+GIF.m:26:42: No visible #interface for 'UIImage' declares the selector 'initWithData:'
animatedImage = [[UIImage alloc] initWithData:data];
// ARC Semantic Issue - myPath/SDWebImage/UIImage+GIF.m:47:34: No known class method for selector 'animatedImageWithImages:duration:'
animatedImage = [UIImage animatedImageWithImages:images duration:duration];
// ARC Semantic Issue - myPath/SDWebImage/UIImage+GIF.m:155:21: No known class method for selector 'animatedImageWithImages:duration:'
return [UIImage animatedImageWithImages:scaledImages duration:self.duration];
My project was working normally until this morning. I changed nothing, just tried to debug on real device. The strangest part of that is I can run/debug on emulator (on any iPhone device with iOS 8) without any error.
When I downgrade deployment target from 8.1 to 8, XCode can successfully build and run the project for emulator and real device.
I tried completely removing SDWebImage and adding it back but didn't solve the problem.
I am using XCode 6.1 (Swift) and iOS 8.1 SDK on my project.
What might be causing the problem that suddenly appeared?
As has been said on other questions, the new "ModuleCache" directory within DerivedData has been responsible for many of these problems.
Here's the path:
/Users/[user]/Library/Developer/Xcode/DerivedData/ModuleCache
Simply delete the module cache, or the entire derived data directory as many have been doing on a daily basis for the last few iOS SDK iterations.
I came here looking for a different answer to a similar problem since this solution isn't fixing my current problem, but I figured I would share this as it will fix many of these.
I've got an app that crashes even before the debugger can connect.
I placed a break point on the first line of main(). (I added an NSLog statement as very first statement in main() and set the break point there.
The app seems to start. The main screen with some ui elements becomes visible on the screen. Then it disappears.
There is no crash log found on the devices.
Xcode message:
Could not launch "appname"
process launch failed: failed to get the task for process xyz
Debugging is enabled of course.
The same for the profiler Instruments.
Code signing works fine so that the app can be deployed to the devices.
(Same for enterprise distribution. And the app validates for store submission.)
It does work on the simulator though.
The app used to work fine. I was just about to build it for the store. For final tests on iOS 8.1 I upgraded to Xcode 6.1 with SDK 8.1. But the problem did not occur directly after the upgrade. It worked just fine.
Then it crashed when building for release for enterprise distribution.
The AppStore build crashed in the same manner (according to Apple, the app was rejected of course.)
But it ran nicely in debug modes.
Now I was trying whether compiler options for optimization may make all the difference and I was trying to build in release mode with debugging enabled etc and end up with a debug build crashing as well. (No optimization in debug).
So it may well be that the migration to Xcode 6.1 did cause it but the problem may have come effective only after Xcode cleaned and rebuild the project in response to changes to compiler settings for code optimization.
Sorry for the long text. I tried to put everything in that may be of importance.
Reason is most likely some incompatibility of Crackify and iOS 8.1.
Therefore it may be of interest for others, altough my problem along with these symptoms may be very special.
Very early within AppDelegate didFinishLaunchingWithOptions we have had the following statement.
if ([Crackify isCracked] || [self isCertificateUnvalid])
exit(173);
That, as such, is not really well designed. The app is just terminated rather than any error message displayed to the user. Thus, it appears as if the app has crashed. But it has not crashed and therefore no crashlog is provided.
For reasons which I don't yet understand and which may not be related to this error, my debugger did not manage to hook up into the executed app. Once that was overcome (suddenly the debugger worked without any changes made to any of the debugging related settings) the error was found rather quickly.
This is Crackify: https://github.com/itruf/crackify
Within Crackify it was this code sniplet that caused the problem:
static NSString *str2 = #"ResourceRules.plist";
BOOL fileExists3 = [manager fileExistsAtPath:([NSString stringWithFormat:#"%#/%#", bundlePath, str2])];
if (!fileExists3) {
return YES;
}
For reasons that I did not further investigate, the file, that is tested here, apparently does not exist in iOS 8.1 any more.
While uploading app-file to itunesconnect the XCode says: improper advertising identifier [IDFA] usage...etc.
But I do not use this feature in my project. I've tried to find any
[[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString]
calling. Futhermore, I'm just fixing a bug of my app, I hadn't included such features since my first release. The first release didn't said about IDFA-usage.
Well, this error happened about 15 days ago and it wasn't clear what is the reason till Apple released the Xcode update the same day and everything went smooth after that. Again, today I get the same message though I tried to upload the same builds for an app which I submitted 8 days ago.
I think we have just to wait for a few hours and see what will happen.
EDIT: Here is a link to show people complain about it at that time and how it was solved without doing anything: LINK
UPDATE: For anyone who uses PlayHaven ads, this may be helpful to avoid this error. Comment the 2 following sections:
In the file PHAdRequest.m (Lines 35-44)
/* if (![PHAPIRequest optOutStatus] && [ASIdentifierManager class])
{
NSUUID *uuid = [[ASIdentifierManager sharedManager] advertisingIdentifier];
NSString *uuidString = [uuid UUIDString];
if (0 < [uuidString length])
{
theIdentifiers[#"ifa"] = uuidString;
}
}*/
In PHAPIRequest.m (Lines 379-383):
/* if ([ASIdentifierManager class])
{
NSNumber *trackingEnabled = [NSNumber numberWithBool:[[ASIdentifierManager sharedManager] isAdvertisingTrackingEnabled]];
[combinedParams setValue:trackingEnabled forKey:#"tracking"];
}*/
This is a temporary workaround till PlayHaven updates their SDK.
I had provided this answer on another similar question and it seems to have been of help & I think my answer is particularly suited also to this question...
I had a similar error in an update to an app that had previously updated fine and then a few days ago was causing an error, after Apple made a recent change. I wasn't using any ads but do have Facebook integration (which needs the AdSupport framework). I believe, after searching the net, that Facebook uses the advertising ID for its own analysis purposes so, even though I'm not including ads in my app, the validation and upload processes through xCode were failing with the error "Your app contains the Advertising Identifier [IDFA] API..."
I searched and found that I needed to download the Facebook SDK source code, update the FBUtility.m to remove the references to the advertisingID but, in fact, I simply needed to:
1) download the source code for the latest SDK, which I did from here: https://github.com/facebook/facebook-ios-sdk (I downloaded the zip file from github to my documents folder)
2) build the framework - open the terminal. Use cd documents at the command prompt, then use this command: sudo scripts/build_framework.sh, which will run the build_framework.sh script that is in the scripts subfolder within the downloaded Facebook SDK folder
3) Remove the old FacebookSDK.framework from your Xcode project and add the new one (in my case, I navigated to documents/facebook-ios-sdk/build & choose the FacebookSDK.framework folder
4) Archive the project and it should (it was in my case) be good to upload
Hope that helps someone along the way - I've been at this for days!!
Simply upload your binary as you've been doing this while, and broadly classify IDFA in two categories:
publisher: You use third-party ad-networks library to display ad. Choose the 1st option in IDFA -> "Serve advertisements within the app". You're a publisher since you show ads, but do not perform advertising for your own app.
Advertiser: You use third-party libraries to track conversions for your app, as well as track 'goals' in your app. You directly do not show ads in your app. Choose the 2nd & 3rd option in IDFA -> "Attribute this app installation to a previously served ad". AND "Attribute an action taken within this app to a previously served advertisement".
Mixed: You track conversions for your app, as well as display ads in your app. Choose all three options.
In case of PlayHaven, setup PH_USE_AD_SUPPORT to 0 will disable the AdSupport framework.
PHConstants.h
/**
* By default, PlayHaven will require the AdSupport framework. Projects using a version of
* Xcode older than 4.5 may define \c PH_USE_AD_SUPPORT to be 0.
*
* #note By disabling the AdSupport framework, the SDK will not be able to collect the IFA
**/
#ifndef PH_USE_AD_SUPPORT
#define PH_USE_AD_SUPPORT 1
#endif
Work for me to fix "improper advertising identifier" when submit.
I have an strange behavior on reusing CGrects in ipod touch 2G, but not in 3G 4G.
When I run the app from XCode4 with the device plugged it works just fine, but when I archive the app and upload it via itunes or through web server, comes the weird behavior.
If I go to edit scheme, select Archive and choose Build configuration: Debug, upload the app through web server, it works fine.
my code is like this
//this code works perfect
CGRect pos = self.toolBar.frame;
pos.origin.y = 0;
self.toolBar.frame = pos;
//this code fails, to fix it I need to create a new CGRect (CGRect pos2)
//or assign an CGRectMake to pos
pos = self.picker.frame;
pos.origin.y = self.toolBar.frame.size.height;
self.picker.frame = pos;
What is causing this problems. How can I compare those builds configurations (debug - release)
Edited
The main difference between running from XCode vs. archive is DEBUG vs. RELEASE builds, and in particular compiler optimization which is enabled in your release build.
You're likely seeing an LLVM compiler optimization bug related to armv6 processor, I had something very similar happen to me. Try switching from LLVM to GCC compiler. Does this resolve your issue?
Further, if you upgrade to XCode 4.5, you'll find that ARMV6 has been deprecated, so you can also choose to drop support for these old devices and be lockstep with Apple.
I'm getting the following error after a crash in an iPad app that uses CoreMIDI (The * are to blank out the app name):
Dyld Error Message:
Symbol not found: _MIDINetworkNotificationContactsDidChange
Referenced from:
/var/mobile/Applications/8F08B78E-929D-4C5A-9F02-08FD5743C17F/***.app/***
Expected in: /System/Library/Frameworks/CoreMIDI.framework/CoreMIDI
in /var/mobile/Applications/8F08B78E-929D-4C5A-9F02-08FD5743C17F/***.app/***
Dyld Version: 179.4
When the app launches, I listen for MIDI Network Sessions using
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(sessionDidChange:) name:MIDINetworkNotificationSessionDidChange object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(sessionDidChange:) name:MIDINetworkNotificationContactsDidChange object:nil];
Which seems to be what is causing the crash. This is after I call
session = [MIDINetworkSession defaultSession];
session.enabled = YES;
session.connectionPolicy = MIDINetworkConnectionPolicy_Anyone;
MIDIClientCreate(CFSTR("MidiManager"), midiNotifyProc, (void*)self, &midiClientRef);
This kind of looks like CoreMIDI library has not been included in the build. Problem is, it IS included in the build as a required framework. (And the deployment target is set to 4.2). I can run the build fine on my iPad and have been testing extensively with other users' iPads also with no problems whatsoever. Also, this is an update to an existing app that has had several updates already with no problems.
I just double checked my deployment build and the framework is definitely included, and I just installed that build onto my iPad (with a different provisioning profile from the store) and it works fine also.
What could be happening? Could it be that Xcode just did a bad build for the one I sent to Apple, or am I missing something obvious? Could I change the MIDINetworkNotificationSessionDidChange notification symbol to a literal string (#"MIDINetworkNotificationSessionDidChange") to fix things for the mean time?
Thanks for any help!
Seems like this was an Apple thing. The .mm of PGMidi's workhorse class includes this at the top:
// For some reason, this is not pulled in by the umbrella header
#import <CoreMIDI/MIDINetworkSession.h>
https://github.com/petegoodliffe/PGMidi
Did you remember to set the minimum OS requirements to 4.2 in your Info.plist? It could be that the crash reports are coming from users on an earlier version of iOS who are upgrading when they shouldn't be.