WAI
Status Update
No update yet.
Comments
am...@google.com
am...@google.com
Hello
This feature request has been forwarded to the product management team. You can track this thread to post any further comments or check the updates regarding this feature request. However we can't provide you with any ETA at this point.
This feature request has been forwarded to the product management team. You can track this thread to post any further comments or check the updates regarding this feature request. However we can't provide you with any ETA at this point.
am...@google.com
+1, We cannot create AJAX requests to APIs on a subdomain that are behind IAP because of this. The IAP seems to ignore the "Allowed JavaScript Origins" in the OAuth Client ID settings, it should be sending an Access-Control-Allow-Origin: <list of allowed origins> on the 302 redirect.
Example:
Failed to loadhttps://api.staging.example.com/endpoint : Redirect from 'https://api.staging.example.com/endpoint ' to 'https://accounts.google.com/o/oauth2/v2/auth?client_id=.. .' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://staging.example.com ' is therefore not allowed access.
Example:
Failed to load
s....@gmail.com
We ran into the same problem, which seems to make IAP unusable when serving an API.
Hopefully this can be solved quickly
(GCP support ticket [#16518176])
Hopefully this can be solved quickly
(GCP support ticket [#16518176])
am...@google.com
Hi, I also ran into the problem of CORS not supporting IAP. Here's my workaround, in case anyone else finds it useful.
In the same GCP project I have two App Engine services:
- A UI server
- An API server
The UI server makes calls to the API server. To get around the CORS problem, I use Routing with a dispatch file:
https://cloud.google.com/appengine/docs/standard/python/how-requests-are-routed#routing_with_a_dispatch_file
Normally, when the UI server wants to call API server, it callsapi-dot-MY_PROJECT.appspot.com
In this workaround, the UI server calls itself with a specified path ("/api"):MY_PROJECT.appspot.com/api
Since the UI server is calling itself, CORS does not apply.
In the same GCP project I have two App Engine services:
- A UI server
- An API server
The UI server makes calls to the API server. To get around the CORS problem, I use Routing with a dispatch file:
Normally, when the UI server wants to call API server, it calls
In this workaround, the UI server calls itself with a specified path ("/api"):
Since the UI server is calling itself, CORS does not apply.
er...@spotangels.com
:+1:
rk...@gmail.com
+1
sc...@gmail.com
+1. The dispatch rules workaround is helpful but obviously not ideal and doesn't handle Kubernetes use cases.
ch...@gmail.com
+1. This is a big problem for us. We're trying to hit our API server (which is behind IAP) from embedded JS hosted on a domain that we trust but do not control. Currently impossible even with the suggested workaround.
sy...@gmail.com
How do spotify and other music streaming apps work around doze mode, their app use network even when phone is in doze mode. or is this a privilege?
Because for me nothing seems to work :
1 Wake Locks
2 White listing
3 Foreground service separate process (the services lives its task location tracking gets killed)
Because for me nothing seems to work :
1 Wake Locks
2 White listing
3 Foreground service separate process (the services lives its task location tracking gets killed)
an...@gmail.com
I'd like to have some answers too, this is driving mi nuts. I need to perform periodic network calls 24/7 for a research purpose app on wear os, it is not going to be published on the store. On a huawei watch 2 I can run it using a foreground service on a separate process and wakelocks, the same app on a ticwatch (we need to change model since the huawei watch 2 is discontinued) does not work in doze.
mn...@gmail.com
ma...@gmail.com
This really needs to be fixed, I have about 100 support tickets from users complaining that our radio station app stops playing between 2 and 20 minutes. We should be able to request a permission to disable doze mode for the app when they launch it. This has taken my app from a 5 star to a 2.5 star. My previous app was built with a much older version (no longer supported) and it didn't have this issue.
ma...@gmail.com
This problem needs to be resolved by the google team or at least provide some workaround to solve this issue.
Thanks in advance..
Thanks in advance..
[Deleted User] <[Deleted User]>
I am only now, in the last few months since updating to target API 33, seeing issues here.
As more and more of my users move to newer API levels more and more of them are having this issue.
In my case it is even worse than just the background location updates not firing.
Even after opening the app up again manually while the foreground service is still running and should be sending updates, the app never sees a new location and my users are blocked from making any action in the app due to being outside of a set area.
As more and more of my users move to newer API levels more and more of them are having this issue.
In my case it is even worse than just the background location updates not firing.
Even after opening the app up again manually while the foreground service is still running and should be sending updates, the app never sees a new location and my users are blocked from making any action in the app due to being outside of a set area.
an...@neodigital.de
Comment has been deleted.
ka...@gmail.com
[Deleted User] <[Deleted User]>
6 Years and still no reply from Google.
Seems smaller apps with this issue are not considered worth it enough to warrant any action.
We follow all docs and best practices yet get the default response which is contradictory to the docs we follow and do not get the same performance as the big companies.
Seems smaller apps with this issue are not considered worth it enough to warrant any action.
We follow all docs and best practices yet get the default response which is contradictory to the docs we follow and do not get the same performance as the big companies.
Description
Test process:
Run a foreground service with a persistent notification.
Put the phone in deep sleep using ADB.
After a few seconds the service requests location updates using FusedLocationProviderClient with high accuracy.
When the phone is awake, location updates are received in time. When the phone is in deep sleep, at most one update is received, and in some cases none. Here are the issues I'm facing:
* First issue:
When doing a basic high accuracy request (all other parameters left unchanged) from a foreground service, only one update is received on a Nexus 6P (Android O DP3), a Nexus 5 (Android 6.0.1) and a Pixel (Android 7.1.2). No other update is sent in the next 5 minutes, even with a smallest displacement of 0.
* Second issue:
When I specify an interval for the request, no update is received at all on the Nexus 6P (Android O DP3) and the Nexus 5 (Android 6.0.1), regardless of the duration of the interval and even with a max wait time.
On the Pixel (Android 7.1.2), one single update is received pretty quickly (similar to when no interval is specified), and then nothing else.
GPS was on on all phones during testing. Everything works well when the phone is awake. Behavior seems identical when targeting api levels 25 and 26.
Reading all the documentation regarding location updates and deep sleep, it seems that a foreground service should get the updates as reliably whether the phone is in deep sleep or not, especially with intervals specified, so this behavior doesn't seem to be intentional, especially since other things like network access still work properly.
I enclosed a test project where you can start a foreground service that requests location updates after 15 seconds (leaving some time to put the phone in deep sleep) and logs the results.