I recently used Crashlytics to crash monitor an Android application.
All crash log that reported on Fabric cannot be read (all missing, unknown). I suspect that the DSYM file isn't uploaded correctly.
My questions are:
Is there a way to check on Fabric that the DSYM file is missing?
A recommended way to upload DSYM file to fabric?
Can the DSYM file re-uploaded again on the same version build? and how?
Are you still experiencing the issue ? Here is the link to fabric doc on dSYM "All about Missing dSYMs". Answer to you questions;
Is there a way to check on Fabric that the DSYM file is missing?
Missing DSYM information can be found under "fabric.io > settings > apps > "app in question > Missing DSYMs tab. That tab will have Optional and required missing DSYM UUID display there.
A recommended way to upload DSYM file to fabric?
Check out the link I shared above.
Can the DSYM file re-uploaded again on the same version build? and how?
Only time dSYm will be generated when you have made any significant changes to the code.
Related
Google play store team mentioned that they found our app is not compliant with how REQUEST_INSTALL_PACKAGES permission is allowed to be used. Specifically, the use of the permission is not directly related to the core purpose of the app.
But no where in our app, we have used REQUEST_INSTALL_PACKAGES permission but still it was rejected multiple times.
We have added below code snippet in android manifest to remove the REQUEST_INSTALL_PACKAGES from our build and sent for play store review. We have verified in the build permissions and could n't find REQUEST_INSTALL_PACKAGES but, still it was rejected by play store.
Please let us know if anyone faced this issue and how can we rectify this error and make our build approved by Play store team.
In my case, this was related to the open_file in Flutter. This package is using REQUEST_INSTALL_PACKAGES permission in the manifest.
I fixed by using (open_file_safe) :https://pub.dev/packages/open_file_safe
or you can also use open_filex: https://pub.dev/packages/open_filex
both packages are the same as open_file, but .apk file type is not supported. Thus, android.permission.REQUEST_INSTALL_PACKAGES permission is not required.
If you are not using the open_file plugin, you check if the permission REQUEST_INSTALL_PACKAGES is declared in the merged manifest in build/app/intermediates/merged_manifest/ If it is being used remove the permission or else remove that plugin and find any other alternative to that plugin.
Note: If you are facing this issue with a native android project You may be querying all packages with the package manager, this is no longer allowed since Android 8.0. To resolve open the android project of your app in android studio and check the Merged Manifests portion of the AndroidManifest.xml to see if you find that permission is being used in your app if it is being used remove the permission.
If you are still not able to find the plugin or in the merged manifest file so for workaround you can try adding :
<uses-permission
android:name="android.permission.REQUEST_INSTALL_PACKAGES"
tools:node="remove" />
In your main manifest file. try submitting the app again on the play store hope it will help.
See more info here. https://support.google.com/googleplay/android-developer/answer/12085295?hl=en
Github Issue: https://github.com/crazecoder/open_file/issues/204
Check your builds in Alpha, Beta and open testing tracks. Sometimes builds in production will be rejected if your other tracks have this permissions. So remove the old builds in these tracks and try to upload the newer APK to prodcution track.
I have some problems with uploading dSYMs to crashlytics using Xcode 14. I saw a lot of similar questions and discussion on apple forum, but none if them are the same as my case.
Since in Xcode 14 bitcode is deprecated we can't download dSYMs from TestFlight. As i understand as long as flag "enable_bitcode" is set to no, dSYMs from my local archive (which was used to upload app to TestFlight) should be valid for crashlytics, but unfortunately there is a mismatch in dSYM uuid.
So in Firebase Console there is an information that for version X build Y there are missing dSYMs with UUID idX1 and idX2, but unfortunately when i check archive that was uploaded to Testflight there is no dSYMs with uuids idX1 or idX2.
Do i miss sth? I will appreciate any help.
When bitcode is disabled, these are usually the steps to follow:
Make sure that Xcode is generating dSYMs.
Follow these configuration steps to automatically upload dSYMs when building the app.
Increase the version/build number (this is to easily distinguish the new tests).
Do a small code change. This will trigger Xcode to generate a new UUID and related dSYMs.
Build the app and cause a test crash following these steps.
If everything went well, the correct dSYMs should be uploaded to Crashlytics. But, if you see "missing dSYMs" for the this version/build number, it would be interesting to see if something went wrong when uploading the dSMYs.
Typically, the run script will do some validations but will do the upload asynchronously. To override this behavior and do it as part of the build process you can use this other run script:
"${BUILD_DIR%/Build/*}/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/upload-symbols" --build-phase --debug
The --build-phase flag will indicate the script to upload the dSYMs during build time, this will make the build to take a bit longer but will give you the opportunity to obtain more information about this process. Also, the --debug flag will make the script to provide verbose output.
Things to look in these debug logs:
The UUIDs of the dSYMs files.
The App Id. Make sure this is the correct one. In some scenarios there can be multiple GoogleServices-Info.plist files and the script could be using the wrong file.
Errors in the upload process.
I am building project with react native and its completed. I have also generated APK file successfully, however when I tried to open project in Xcode it showing many files as missing mainly are libraries and font files.
I had used below URL to generate ios build
https://medium.com/#tunvirrahmantusher/create-ipa-and-apk-from-react-native-72fe53c6a8db
not sure what is wrong and why files are missing, any suggestion or help will really helpful.
Thank you in advance.
I have tried to build iOS folder twice but its not working either
If someone can say why those files are missing an what can be done to get those files in xCode and I can run project in xCode also that will really help.
We have a dozen targets in the same Xcode project, each target is an app on itself, and we always release all the apps at the same time.
It extremely counterproductive to individually archive and upload each target to iTunesConnect.
I believe I've found a way to archive: http://blog.octo.com/en/automating-over-the-air-deployment-for-iphone/
But so far I was unable to find a way to upload to iTunesConnect from command line.
Please advice how should I approach this task. Thank you.
You can use altool, Application Loader’s command-line tool for validating and uploading your application binary files to the App Store. Please checkout apploader
Also, you can use deliver to submit your app for App Store review. Please checkout master/deliver
The TestFlight SDK recommends setting Strip Debug Symbols During Copy to YES in Xcode Build Settings to enable the best crash reporting possible. I noticed that it's set to YES by default.
Should I change it to YES? Why or why not?
I work at TestFlight. Short answer is: set it to YES.
Long answer:
#Kerni is correct. Before we started symbolicating server side, we needed that data to symbolicate on device.
So if you upload your dSYM to TestFlight, you can strip them. If you don't want to upload your dSYM for some reason, you can leave them in and TestFlight can symbolicate on device.
Basically the README was not updated. Sorry #Manni! I will update it for the next release. (I'm going to remove that entire section).
Sorry about the confusion!
If the default setting is YES, there is no need to do anything else.
In general this setting makes sure that debug symbols are not part of the distributed binary which reduces the file size by 30-50%. The debug symbols should instead be written to the dSYM DWARF file, which can later be used to symbolicate crash reports.
The TestFlight SDK recommends to set this setting to NO, not to YES:
To enable the best crash reporting possible we recommend setting the following project build settings in Xcode to NO for all targets that you want to have live crash reporting for. You can find build settings by opening the Project Navigator (default command+1 or command+shift+j) then clicking on the project you are configuring (usually the first selection in the list). From there you can choose to either change the global project settings or settings on an individual project basis. All
settings below are in the Deployment Section.
Deployment Postrocessing
Strip Debug Symbols During Copy
Strip Linked Product
Bugsense (http://www.bugsense.com/pages/faq) also recommend this setting with this explanation:
Why do I get memory dumps instead of the stack trace for my iOS app?
iOS apps usually don’t include debugging information or this information is included in a special file with the extension dSYM
(debugging SYMbols). To turn on (and include in your binary) debugging
information for your iOS app you must set to NO a project setting
called “Strip Debug Symbols” for all project configurations.