I'm doing android open source project and I'm new to aosp.
I am building gingerbread in Ubuntu 14.04 64-bit.
I have managed to successfully compile the source code without any error, and now when I run the command 'emulator', I get the following error and my emulator is not running at all
emulator: WARNING: ignoring locked user data image at /home/hari/Android/aosp/out/target/product/generic/userdata-qemu.img
emulator: WARNING: Another emulator is running. user data changes will *NOT* be saved
emulator: ERROR: There is no user data image in your build directory. Please make a full build
I searched over the internet and was not able to find a guy with the similar problem. So, anyone have any idea? What could be the possible solution ?
Edit:
My out directory and userdata-qemu.img is locked! Is this unusual ??
Thanks in advance.
I think your file is locked... may be you copied some files from another user. Make sure you give the all your files some permissions.
cd one step back from your aosp root directory and use this command
chmod -Rv 755 youraospdirectory/
I had similar issues, but in my case the whole directory was the problem.
So it would be better to chmod the whole directory.
Related
I want to distribute a Flutter desktop app outside of App Store. The app includes some extra binaries using the assets key in pubspec.yaml. The binaries end up in this directory inside the app:
flutter_sample.app/Contents/Frameworks/App.framework/Versions/A/Resources/flutter_assets/bin
So that's what I use with Process.run(...) and it works locally. However, if I try to notarize the app in Xcode and export it then app will crash immediately when trying to run an included binary. I opened Console and found the following entry in launchd.log corresponding to the time the app crashed:
2022-01-07 08:28:04.875197 (gui/501/application.com.example.flutterSample.1772919.1772925) : removing job: caller = runningboardd
2022-01-07 08:28:04.875204 (gui/501 [100020]) : removing service: application.com.example.flutterSample.1772919.1772925
2022-01-07 08:28:04.875309 (gui/501/application.com.example.flutterSample.1772919.1772925) : internal event: PETRIFIED, code = 0
2022-01-07 08:28:04.875311 (gui/501/application.com.example.flutterSample.1772919.1772925) : job state = removed
I wasn't able to find any other information about the error. If I enclose the code using Process.run in a try-catch block it doesn't change anything, the entire application crashes anyway. The same happens if I use a zone or onError handler as described on the handling errors page in Flutter docs.
Extra details:
I've disabled com.apple.security.app-sandbox in the *.entitlements files, with it running the processes didn't work even locally
I've enabled hardened runtime in Xcode, it was required to notarize the app.
the app also crashes if instead or exporting from Xcode I plainly archive the build directory (with tar) and send it via internet (or set com.apple.quarantine with xattr). It won't crash if I just pack and unpack it without marking it as quarantined. That makes sense but I expected that notarizing the app would fix it.
So, what can I do to prevent these crashes, or at least get more details when they happen so I can investigate further?
As it turns out, it was an issue with paths. If I go to my project directory and then enter the debug build directory:
$ cd build/macos/Build/Products/Debug
then from this point I can access two identical asset directories:
$ ls -lh App.framework/Versions/A/Resources/flutter_assets
(output omitted)
$ ls -lh flutter_sample.app/Contents/Frameworks/App.framework/Versions/A/Resources/flutter_assets
(the same output, omitted)
As it turns out, I was actually trying to call the binary in the first asset directory (even though I posted the second one in the question). And apparently the other one is correct when the app is packaged for distribution. After changing this the binaries work in the exported, notarized app.
Try to firstly copy your binary from assets folder to somewhere else. Let's say copy to /tmp/myfile. Then ensure you have executable permission to it (chmod +x /tmp/myfile using shell; should have sth similar using code). Then execute that binary.
This is a common practice, at least for platforms like Android. Because in android, an asset does not have a "normal" path so you have to copy it out, IIRC.
If this method works, it is great; even if not, now you can manually call /tmp/myfile in a shell to see what is happening.
I'm trying to add an external library to my AOSP (v9.0.0-2.0.0) image by following the instructions provided with said library. The instructions are:
cd <aosp source folder>/external/libgpiod
mm
Then I run luch and then make to build the image then I flashed it to the SD card. But when I the library commands it via adb shell, none of them work. I get the response:
dart_mx8mm:/system/app # gpiodetect 0
/system/bin/sh: gpiodetect: not found
Although I can see that there are some files name the same as the library in the /out folder.
Is there any way to debug this? The log file isn't helping me very much.
The library in question is https://github.com/technexion-android/platform_external_libgpiod
I'm using a PC and I've created a build for Mac standalone.
I shared the file with my test user by zipping and emailing the build, but when he tries to run the application he sees this error:
The application "SomeApp.app" can't be opened.
After some searching, I learned that I need to do chmod to open the file. Can anyone tell me how to do that on a Mac?
The zip format doesn't have easy support for Unix-like file permissions, so your transfer process is stripping any permission flags that OSX uses to recognize files within that zip that are supposed to be executable. This can also happen with other file transfer solutions, so it's something to watch out for.
The best solution would be to create an archive which does keep those permissions, such as a tar archive.
Failing that, you can have a Mac user open a terminal and set the permission flag manually:
chmod a+x SomeApp.app/Contents/MacOS/*
(Replace SomeApp.app with whatever your .app folder is named)
I had the same issue, I left an answer here, at the bottom: https://forum.unity.com/threads/mac-build-breaking-when-uploaded-to-storage.1093330/
The problem was not with the .zip, but rather with the build itself. Ran fine on my Mac, did NOT run fine once I uploaded it and downloaded it again (or if anyone else downloaded it).
Edited 12/8/2021, as per EmiOB's suggestion, to add the text of my answer (same as in the link):
This worked for me on 2020.3.16f1:
In the Unity Editor: Build Settings, check the box that lets you make an XCode project (requires having XCode installed, I believe I have Xcode 11)
Open the XCode project
Build
That solved my problem :)
Each time I try to archive my application to submit it to apple Xcode keeps giving me this error! I'v Triple checked that in the Cocos2d libraries Target i made that my Install Group & Install Owner are correct and i;v restarted my computer & reinstalled Xcode. It runs just fine in the simulator. But like i said as soon as I hit Archive it gives me this error
SetOwnerAndGroup "Home:staff" "/Users/Home/Library/Developer/Xcode/DerivedData/Swimmu-bdswkmmaijgxvyasdnmkpmnfgxji/ArchiveIntermediates/Swimmu/InstallationBuildProductsLocation/usr/local/lib/libcocos2d libraries.a"
cd /Users/Home/Documents/Swimmu
setenv PATH "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/usr/sbin/chown -RH "Home:staff" "/Users/Home/Library/Developer/Xcode/DerivedData/Swimmu-bdswkmmaijgxvyasdnmkpmnfgxji/ArchiveIntermediates/Swimmu/InstallationBuildProductsLocation/usr/local/lib/libcocos2d libraries.a"
chown: /Users/Home/Library/Developer/Xcode/DerivedData/Swimmu-bdswkmmaijgxvyasdnmkpmnfgxji/ArchiveIntermediates/Swimmu/InstallationBuildProductsLocation/usr/local/lib/libcocos2d libraries.a: No such file or directory
Command /usr/sbin/chown failed with exit code 1
Yet a third problem with the same error... Different solution as well. In my case, the default install group $(INSTALL_GROUP) was a windows domain and had \ in it, which translated to space and caused the build to fail.. I fixed it by changing my install group to be admin.
Your name entered in Install Owner should match the name of your Mac OS login under which you are logged in and the Name of Apple's Dev License and certificates.
So go to System Preferences | Users & Groups and set a Full name that matches your Apple's Developer License name
"libcocos2d libraries.a"
The problem may be related to the space in the library. If you created that library target it should be easy to fix by changing the name of the library target to "cocos2d_libraries".
I had a different problem than you, but had the same error:
Command /usr/sbin/chown failed with exit code 1
When I created my XCode project, my app name had a space in it, so trying to deploy my app always failed. I was able to fix this by using a Custom Archive Name.
In XCode 4...
Edit the Deployment Scheme
Click on the Archive tab
Then specify an Archive Name that doesn't have spaces in it.
I was able to fix this by cleaning the project, deleting derived data, and restarting Xcode.
When I attempt to resize the internal storage for the emulator
./emulator -partition-size 1024
This is the error I receive: 2011-03-01 15:42:55.263 emulator[1033:903] LCC Scroll Enhancer loaded emulator: WARNING: ignoring locked user data image at /android-sdk-mac_x86/tools/./../platforms/.DS_Store/images/userdata-qemu.img emulator: WARNING: Another emulator is running. user data changes will NOT be saved emulator: ERROR: could not initialize user data image from /android-sdk-mac_x86/tools/./../platforms/.DS_Store/images/ramdisk.img: Not a directory
Any advice or help would be greatly appreciated.
you can check this post and this one for details about how to increase the internal storage of the Android emulator.
It looks that for some reason the platform subdirectory is not correctly looked up and the first entry in the platforms directory is assumed to be one platform dir (whereas it is the .DS_Store file on MacOS).
Just delete the .DS_Store file in the specified directory (using a rm command, not the Finder which will recreate it automatically) and it will workaround the problem.