i am facing problem related to requestPermissionAsync this method does not show prompt to the user. Any help would be highly appreciated
Android Version: 12
Expo SDK: 47
Can you put the code where you have invoked the method 'requestPermissionsAsync()'
Make sure that you did not use the method before that,If the user has
already granted permissions for notifications, the prompt will not be
shown again. You can check the current status of the permissions by
using the getPermissionsAsync() method and see if the status is
"granted"
Make sure you are using the latest version of the expo-notifications library. There could be compatibility issues with the current version of your expo sdk.
It is also possible that the problem is related to the Android version 12, as there have been some reports of issues with notifications on this version. If this is the case, you can try testing on a different version of Android to see if the issue persists.
Another solution is to check if the code is running on an emulator or real device, sometimes the permission prompt doesn't work well on emulators.
-You could also try to check the logs of your app and see if there are any error messages related to notifications.
If you are still facing problem, please provide more details about your problem, the error logs and the code you are using.
Related
When attempting to run a simple Android Instant App, I receive this error in the console and the app does not open. What does this error mean and how do I pass in a valid credential header?
There's a known issue where emulators are not allowed to talk to the Instant Apps backend, resulting in this error. If you try to use the emulator to launch a published instant app, it'll fail for this reason. We've also seen it on some physical devices, but it's very inconsistent there.
When running an instant app locally, you may still see this error, but it's not the root cause. The loader tries to fall back to the backend if something goes wrong with the local launch. So hopefully there's something further up indicating what went wrong initially.
A change has been submitted to skip the fallback for emulators, to reduce that noise, and that'll be in an upcoming SDK release.
Clean build the project and try again. I did get the same error but got rid of it after clean build.
This error can be due to a variety of things and means that your device is not able to run Instant Apps for one reason or another. For example, your device is in a country that is not currently launched (available countries).
I would recommend using the emulator by following the instructions here, as this is a debug device, Studio is able to send override flags to the emulator to ensure Instant Apps will run.
I (brutally) solved with a clean boot: Tools/AVD Manager/Virtual Devices/Down-arrow on the line of the selected emulator/Cool Boot.
I have implemented a sync adapter in my app which requires an account to be added in the device account settings. I followed the same approach given in the Android docs. It works fine till Marshmallow and I can see my account listed in the device accounts. But in Android N preview, account does not add to the device accounts. AccountManager's addAccountExplicitly() method always returns false. Has anyone faced this problem?
Not sure if this is the same issue, but there's an issue with AccountManager on the current version of the Android N image. Basically, if you:
Add an account to AccountManager
Uninstall the app
Reinstall the app
Try to add account again
This will fail and you'll see the following in the log:
W/AccountManagerService( 1503): insertAccountIntoDatabase: Account {name=foo#bar.com, type=com.foo.bar}, skipping since the account already exists
This is a known issue and it's been reported to Google:
https://code.google.com/p/android/issues/detail?id=210992
https://code.google.com/p/android/issues/detail?id=210951
I have totally the same issue.
I could fix it by manually going to the application settings and enabling Сontacts permission. I don't know how, but after that I was able to use addAccountExplicitly() method without issues. I even disabled that permission again and cleared app data but it still was working properly...
After app was reinstalled - problem appeared again.
Has this been fixed now in the latest Android N release.
The developer console for android has functionality for reporting runtime crashes if users decide to report a crash. Other frameworks has similar features that sends crash-reports without involving the user.
Does anyone know of a way to report installations or upgrades that has failed? With android 5.0 I am getting more and more user-reports of failed installs, but it is hard to obtain logs from non-technical users of my app.
You cannot detect whether or not an installation has failed yourself, because there is no way to execute code before your app is actually installed. So the logical app to do such a thing would be the market app triggering the install (i.e. Google Play). This not only knows when each installation starts, but also knows all details about the apk to report to the right developer.
Unfortunately however, Google play does not support this currently (as far as I know) and hence you cannot detect failed installs.
On older Android phones you could ask users is to install a "logcat app" and email the logs to you for analysis, but this will only work for devices older than Jelly bean. (Read this Link)
The best solution I can come up with (Mac only) is to ask users to install AndroidTool, press one button to generate a bugreport and email that to you. Not great, but for now the best you can do.
You can build an api that reports successful installation. Just call the api in onCreate of first activity. I don't think there is need to collect log on why the installation failed, is it needed ? You can do the same for upgrade, call an api one time from upgraded code.
I'm using the 5.1 SDK to log in on Android. This works first time round and I'm able to download profile pics and use the API with no issues.
When I restart the app, I'm prompted with the permissions screen again, even though I already given permissions.
When I look at the device log, I see
{"key_hash":"XXXXXXXXXXXXXX=\n","user_id":"1234","expiration_timestamp":"1404234168","access_token":XXXXX...","opened":true}
(values replaced with XXXXX for privacy)
This expiration_timestamp is parsed to be "07/01/2014 17:02:48", which is wrong.
Every time I restart the app, I get the same permissions prompt.
Have I made an error with the setup or is this a known issue? Anybody know any workarounds?
Thanks all
I use a Facebook sample app (SessionLoginSample) to understand how to log into Facebook. My Facebook SDK is latest — version 3.0. When I have the Facebook app installed, I can log in without any problems.
The problem is when I uninstall my Facebook app and re-install the sample (so it doesn't log in automatically). I try to log in but I can see only a white empty dialog. The only option I have is to close it. Even if I wait 10-15 minutes, the dialog doesn't change.
I tried to debug the Facebook SDK but I couldn't find what's causing the error.
I tested this on LG-E610 (4.0.3) and HTC Sensation (4.0.3).
Is this facebook sdk error or I'm doing something wrong?
Edit: I tested this issue again 10 days later in the same coditions and everything seems to work as expected.
The problem might not be on your side! I have encountered a situation where one and the same request to Facebook would be answered as expected or with an "Internal Server Error 500" depending on my IP (IP/User agent to be exact).
You can be quite certain that nothing is wrong with your configuration and application when:
Your app works from another network (i.e. another IP)
When the sample app from Facebook (i.e. HelloFacebookSample) runs into the same problem.
For Android see: http://developers.facebook.com/docs/getting-started/facebook-sdk-for-android/3.0/
For iOS see: http://developers.facebook.com/docs/getting-started/facebook-sdk-for-ios/
My suspicion is that Facebook puts certain IP/user agent combinations in a temporary black list. The problem is that their generic 500 response is not helpful.
For another reported case see my question at Internal Server 500 from Facebook with sepcific IP/user-agent combination