I developed a daemon that is tracking the location as given in the Chris Alvares webpage.
It is working fine if install it through SSH directly to the phone from mac terminal. It's not at all launching if I install the same daemon through Cydia. I am getting the error in the log as
Mar 3 16:07:11 Jailbreak-iPhone-5S installd[51] : 0×100590000
verify_signer_identity: MISValidateSignatureAndCopyInfo failed for
/Applications/Myapp.app/TsavoriteClient: 0xe800801c
Mar 3 16:07:11
Jailbreak-iPhone-5S installd[51] : 0×100590000 load_application_info:
Failed to validate binary at path /Applications/Myapp.app/Myapp:
0xe800801c. This binary may not work properly.
I tried all steps given in this post.
Any idea what's wrong here?
Finally found the solution after long debugging steps!
The problem is with the LaunchDaemon plist file ownership. If I copy plist from SSH the the file properties are as below
-rw-r--r-- 1 root wheel 461 Mar 3 15:20 com.Mycompany.Myapp.plist
If the LaunchDaemons copied by cydia the file properties are as below
-rw-r--r-- 1 503 staff 461 Mar 3 15:20 com.sourcebits.TsavoriteClient.plist
We need to change the LaunchDaemons plist file ownership before preparing the .deb file using the command
sudo chown -R root:wheel filePath
Related
i want to add .h and .lib files to a own created recipe to the sdk.
I use cmake to build my lib's, with the sdk i can build it.
My recipe name is served. (i want to add the served https://github.com/meltwater/served as a own recipe).
in my served_0.1.bb File i add following:
BBCLASSEXTEND = "native nativesdk"
RDEPENDS_${PN} += "nativesdk-served"
in the layer.conf i add:
TOOLCHAIN_TARGET_TASK_append = " served "
When i start to create my sdk with
bitbake core-image-base -c populate_sdk
ERROR: core-image-base-1.0-r0 do_populate_sdk: Could not invoke dnf. Command '/home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/recipe-sysroot-native/usr/bin/dnf -v --rpmverbosity=info -y -c /home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/sdk/image/opt/poky/3.2.4/sysroots/cortexa72-poky-linux/etc/dnf/dnf.conf --setopt=reposdir=/home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/sdk/image/opt/poky/3.2.4/sysroots/cortexa72-poky-linux/etc/yum.repos.d --installroot=/home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/sdk/image/opt/poky/3.2.4/sysroots/cortexa72-poky-linux --setopt=logdir=/home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/temp --repofrompath=oe-repo,/home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/oe-sdk-repo --nogpgcheck install packagegroup-base-extended packagegroup-core-boot packagegroup-core-standalone-sdk-target psplash-raspberrypi run-postinsts served target-sdk-provides-dummy' returned 1:
DNF version: 4.2.23
cachedir: /home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/sdk/image/opt/poky/3.2.4/sysroots/cortexa72-poky-linux/var/cache/dnf
Added oe-repo repo from /home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/oe-sdk-repo
User-Agent: falling back to 'libdnf': could not detect OS or basearch
repo: using cache for: oe-repo
oe-repo: using metadata from Sun 06 Jun 2021 03:50:26 PM UTC.
Last metadata expiration check: 0:00:01 ago on Sun 06 Jun 2021 03:50:26 PM UTC.
--> Starting dependency resolution
--> Finished dependency resolution
Error:
Problem: conflicting requests
nothing provides nativesdk-served needed by served-1.0+git0+2eb36b83fa-r0.cortexa72 (try to add '--skip-broken' to
skip uninstallable packages)
ERROR: Logfile of failure stored in:
/home/yocto/videoMon/build/tmp/work/raspberrypi4_64-poky-linux/core-image-base/1.0-r0/temp/log.do_populate_sdk.27092
ERROR: Task
(/home/yocto/videoMon/meta/recipes-core/images/core-image-base.bb:do_populate_sdk)
failed with exit code '1'
Have anyone an idea?
Bests
Assuming that you have a recipe for served which compiles without errors.
The step to add served .h and lib files to sdk is to add below line to local.conf
TOOLCHAIN_TARGET_TASK_append = " served "
And then run command
bitbake core-image-base -c populate_sdk
The lines below in your served recipe are causing errors and are not needed for SDK generation. Please remove them and try building your image again.
BBCLASSEXTEND = "native nativesdk"
RDEPENDS_${PN} += "nativesdk-served"
I've been building (from a mac terminal) this native application successfully for a long time but today I've run across an error I can't seem to pin down. After tiring from all the javac warnings I upgraded to a newer version of ant. I'm not sure it is related but the timing is suspect. I can still build, deploy, and run my application but now I can no longer use ndk-gdb to debug the native part of the application. It appears on inspection that the gdb.setup file is not getting added to the debug apk.
here is the build sequence, abbreviated output, and information. I'm looking for suggestions on how to resolve the issue.
I've done a full clean on both NDK and ant builds
The android NDK version and android SDK versions are all up to date.
I use the built in ndk-bundle that gets loaded with the android studio sdk tools.
The devices we develop on are not rooted and is not an option.
hsmith$ java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
hsmith$ $ANT_HOME
-bash: /Users/hsmith/dk/ant/apache-ant-1.9.6: is a directory
hsmith$ ndk-build -j4 NDK_DEBUG=1
[armebi-v7a] Gdbserver : [arm-linux-androideabi-4.8] libs//gdbserver
[armebi-v7a] Gdbsetup : libs//gdb.setup
[armebi-v7a] Install : lib1.so => libs/armebi-v7a/lib1.so
[armebi-v7a] Install : lib2.so => libs/armebi-v7a/lib2.so
[armebi-v7a] Install : lib3.so => libs/armebi-v7a/lib3.so
hsmith$ ant debug
…
-package:
[apkbuilder] Found modified input file
[apkbuilder] Creating -debug-unaligned.apk and signing it with a debug key...
-post-package:
-do-debug:
[zipalign] Running zip align on final apk...
[echo] Debug Package: /Users/hsmith/packageFolder/bin/<package>-debug.apk
[propertyfile] Updating property file: /Users/hsmith/packageFolder/bin/build.prop
[propertyfile] Updating property file: /Users/hsmith/packageFolder/bin/build.prop
[propertyfile] Updating property file: /Users/hsmith/packageFolder/bin/build.prop
[propertyfile] Updating property file: /Users/hsmith/packageFolder/bin/build.prop
-post-build:
debug:
BUILD SUCCESSFUL
hsmith$ adb install -r ~/packageFolder/bin/-debug.apk
hsmith$ ndk-gdb adb --start
ERROR: Package is not debuggable ! You can fix that in two ways:
Rebuilt with the NDK_DEBUG=1 option when calling 'ndk-build'.
Modify your manifest to set android:debuggable attribute to "true",
then rebuild normally.
After one of these, re-install to the device!
I unzipped the apk file to find
unziped apk file/lib/target/
hsmith$ ls -la
total 48264
drwxr-xr-x 12 hsmith staff 408 Aug 25 14:50 .
drwxr-xr-x 5 hsmith staff 170 Aug 25 14:50 ..
-rwxr-xr-x 1 hsmith staff 409940 Jun 3 11:47 gdbserver
-rwxr-xr-x 1 hsmith staff 33920 Aug 25 14:44 lib1.so
-rwxr-xr-x 1 hsmith staff 165092 Aug 25 14:44 lib2.so
-rwxr-xr-x 1 hsmith staff 1614028 Aug 25 14:44 lib3.so
note there is no gdb.setup file
I don't use debuggable=true in the manifest because it isn't needed anymore however including it has no affect on the result.
UPDATE: https://code.google.com/p/android/issues/detail?id=183455
This is exactly the problem I'm having. if you copy the target gdb.setup file from the target directory to the ./lib directory you can get ndk-gdb to work; The COMPAT_ABI variable in ndk-gdb isn't being set correctly and sending the script into a spin. I hope they fix this one soon. almost three days wasted on a broken tool chain.
UPDATE: https://code.google.com/p/android/issues/detail?id=183455 This is exactly the problem I'm having. if you copy the target gdb.setup file from the target directory to the ./lib directory you can get ndk-gdb to work; The COMPAT_ABI variable in ndk-gdb isn't being set correctly and sending the script into a spin. I hope they fix this one soon. almost three days wasted on a broken tool chain.
I followed the instructions here and it happens in both tweak and app:
http://iphonedevwiki.net/index.php/Theos/Setup#Creating_a_Project
But I don't see any .deb files
RoverMR-2:testapp rover$ find . -name "deb"
Here are several relevant command output logs:
https://gist.github.com/anonymous/42b4a086d6b7ee792b08
I just see this in packages:
RoverMR-2:testapp rover$ ls -la .theos/packages/
total 8
drwxr-xr-x 3 rover staff 102 Apr 30 11:12 .
drwxr-xr-x 4 rover staff 136 Apr 30 11:12 ..
-rw-r--r-- 1 rover staff 1 Apr 30 11:12 com.mysite.testapp-0.0.1
RoverMR-2:testapp rover$ make package
/Users/rover/Documents/Dev/Cydia/Theos/apps/testapp/theos/makefiles/targets/Darwin/iphone.mk:41: Deploying to iOS 3.0 while building for 6.0 will generate armv7-only binaries.
Making all for application testapp...
Copying resource directories into the application wrapper...
Compiling main.m...
Compiling testappApplication.mm...
Compiling RootViewController.mm...
Linking application testapp...
Stripping testapp...
Signing testapp...
Making stage for application testapp...
RoverMR-2:testapp rover$
RoverMR-2:testapp rover$ ls
Makefile RootViewController.h _ main.m testappApplication.mm
Resources RootViewController.mm control obj theos
RoverMR-2:testapp rover$
the error:
RoverMR-2:testapp rover$ make install
/Users/rover/Documents/Dev/Cydia/Theos/tweaks/testtweak/theos/makefiles/targets/Darwin/iphone.mk:41: Deploying to iOS 3.0 while building for 6.0 will generate armv7-only binaries.
Could not find "./com.yourcompany.testtweak_0.0.1-10_iphoneos-arm.deb" to install. Aborting.
I posted an issue about this https://github.com/DHowett/theos/issues/120
Type make package install all at once in the tweak's directory.
I already installed the latest version of phonegap-facebook-plugin
But when i build the project, I got the error message below.
I tried many solutions mentioned at stackoverflow and other websites with no positive result.
com.phonegap.plugins.facebookconnect/FacebookConnectPlugin.m:11:
Et3arrafApp/Plugins/com.phonegap.plugins.facebookconnect/FacebookConnectPlugin.h:11:9: fatal error:
'FacebookSDK/FacebookSDK.h' file not found
#import <FacebookSDK/FacebookSDK.h>
^
1 error generated.
** BUILD FAILED **
The following build commands failed:
CompileC build/Et3arrafApp.build/Debug-iphonesimulator/Et3arrafApp.build/Objects-normal/i386/FacebookConnectPlugin.o Et3arrafApp/Plugins/com.phonegap.plugins.facebookconnect/FacebookConnectPlugin.m normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)
Error: /Users/apple/Desktop/et3arraf/platforms/ios/cordova/build: Command failed with exit code 65
at ChildProcess.whenDone (/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/cordova/superspawn.js:131:23)
at ChildProcess.EventEmitter.emit (events.js:98:17)
at maybeClose (child_process.js:753:16)
at Process.ChildProcess._handle.onexit (child_process.js:820:5)
I encountered the same problem today.
Installing this plugin using the plugin register does not work (for iOS) at the moment.
You must clone the repository (phonegap-facebook-plugin) to your local file system, say $HOME/src/phonegap-facebook-plugin. And then install the plugin pointing to that path, e.g. cordova plugin add $HOME/src/phonegap-facebook-plugin
...
It turns out that FacebookSDK.framework isn't installed properly when fetching through the plugin registry. It should look like this:
$ ls -l plugins/com.phonegap.plugins.facebookconnect/platforms/ios/FacebookSDK.framework/
total 24
lrwx------ 1 mjl staff 24 Aug 15 15:23 FacebookSDK -> ./Versions/A/FacebookSDK
lrwx------ 1 mjl staff 20 Aug 15 15:23 Headers -> ./Versions/A/Headers
lrwx------ 1 mjl staff 22 Aug 15 15:23 Resources -> ./Versions/A/Resources
drwx------ 4 mjl staff 136 Aug 15 15:23 Versions
But the symlinks aren't preserved when installing through the plugin registry... They are preserved when installing from the local file system though.
I had solved it by installing the plugin using --save option.
in my case I had downloaded the plugin to my computer and what I did is :
cordova plugin add --save <my downloaded plugin directory> --variable APP_ID=<app_id> --variable APP_NAME=<app_name>
The required file will be listed same as #mjl's result from ls -l plugins/com.phonegap.plugins.facebookconnect/platforms/ios/FacebookSDK.framework/
P/S: if you are using iTerm, you can drag the folder into your iTerm terminal and the full directory path will be type in automatically.
After more and more search around the web, I tried to re create the sym link of Headers, FacebookSDK and Resources and resolved
ln -s ./Versions/A/Headers Headers
and so on
I'm attempting to set up a CI environment for an iOS application. So far I've gotten xcodebuild to build the test build correctly from the command line but when Jenkins tries to execute it I get the following read out in the console:
Started by user anonymous
Building in workspace /Users/Shared/Jenkins/Home/jobs/Unit Tests/workspace
Working directory is /Users/iosappdev/Documents/Xcode Projects/rules.
[rules] $ /usr/bin/xcodebuild -version
FATAL: Cannot run program "/usr/bin/xcodebuild" (in directory "/Users/iosappdev/Documents/Xcode Projects/rules"): error=13, Permission denied
java.io.IOException: Cannot run program "/usr/bin/xcodebuild" (in directory "/Users/iosappdev/Documents/Xcode Projects/rules"): error=13, Permission denied
at java.lang.ProcessBuilder.start(ProcessBuilder.java:460)
at hudson.Proc$LocalProc.<init>(Proc.java:244)
at hudson.Proc$LocalProc.<init>(Proc.java:216)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:707)
at hudson.Launcher$ProcStarter.start(Launcher.java:338)
at hudson.Launcher$ProcStarter.join(Launcher.java:345)
at au.com.rayh.XCodeBuilder.perform(XCodeBuilder.java:224)
Any thoughts? I'm fairly new to Jenkins but I have done my best to answer this question with Google Fu to no avail. I did originally run into this problem with a manual installation of Jenkins (homebrew technically) but recently used the OSX installer and it resulted in the same error.
I'm guessing this has more to do with Unix/Linux/OSX permissions than Jenkins/Xcode but don't have enough expertise to determine that for certain.
Edit
Project directory permissions set to 775.
I've also tried changing the ownership to the user Jenkins runs on.
Here's the output for when I attempted to run xcodebuild as the daemon user ($ sudo -u daemon xcodebuild):
dev-imac:rules iosappdev$ sudo -u daemon xcodebuild
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
2012-03-21 11:05:46.161 xcodebuild[1411:70b] [MT] DVTAssertions: ASSERTION FAILURE in /SourceCache/IDEXcode3ProjectSupport/IDEXcode3ProjectSupport-1196/Xcode3Sources/XcodeIDE/Frameworks/DevToolsBase/pbxcore/Xcode3Model/Xcode3Project.m:266
Details: Assertion failed: [directoryPath isAbsolutePath]
Object: <Xcode3Project>
Method: +projectFilesInDirectory:
Thread: <NSThread: 0x40010a260>{name = (null), num = 1}
Hints: None
Backtrace:
0 0x000000010025b85f -[DVTAssertionHandler handleFailureInMethod:object:fileName:lineNumber:messageFormat:arguments:] (in DVTFoundation)
1 0x000000010025b6b5 _DVTAssertionFailureHandler (in DVTFoundation)
2 0x00000001011559bc +[Xcode3Project projectFilesInDirectory:] (in DevToolsCore)
3 0x00000001008a424b -[Xcode3CommandLineBuildTool _resolveInputOptions] (in Xcode3Core)
4 0x00000001008aa097 -[Xcode3CommandLineBuildTool run] (in Xcode3Core)
5 0x00000001001d7db6 (in xcodebuild)
6 0x00000001001d7c2c (in xcodebuild)
Make sure that the user under which Jenkins runs has the right permissions. Go to http://[jenkins_server]/systemInfo and search for user.name.
Above it reads:
Building in workspace /Users/Shared/Jenkins/Home/jobs/Unit Tests/workspace
Working directory is /Users/iosappdev/Documents/Xcode Projects/rules.
[rules] $ /usr/bin/xcodebuild -version
Somehow the job execution has jumped into a "wrong" directory. Maybe you have set the job with a custom workspace? Jenkins is probably running as user daemon and thus has no access to files under the user iosappdev.
The usual way to use Jenkins is for you to commit your source code to a version control repository. Jenkins jobs are then configured to check out the code from the repository into the Jenkins workspace and build it there and then report back the results.
I'm not sure what can be achieved by trying to make Jenkins jump directly into your working directory and do the build there. If that is really what you are trying to do, you need to tell us why you think it is a good idea.