Caching should be documented [35886021]

Feature Request

Status Update

No update yet.

Description

sd...@gmail.com

created issue #1

Oct 13, 2009 02:48PM

If I set a Cache-Control header sufficiently far in the future for a
response, then the App Engine infrastructure should act as if there were a
caching reverse-proxy server in front of my app.

The next request for the same URL should be served directly from the cache
without an instance of my app being started.

The amount of cache space, should be determined by App Engine, as memcache
space is. Responses with cache-control headers could be sampled by App
Engine; those with the most frequent requests would stay in cache longer.

The advantages would be: 1) less cpu/memory usage by my app to serve what
are basically static resources; 2) higher requests per second without
running more instances; 3) cached content served by Google's geographically
dispersed, low-latency edge servers.

This is a model familiar to many web developers and requires no extra APIs,
or even documentation. It is good practice to cache-control headers.

Comments

sd...@gmail.com <sd...@gmail.com> #2Sep 14, 2010 07:46PM

Thanks for the report. I will route this to the appropriate internal team and update this when I hear back from them.

f....@gmail.com <f....@gmail.com> #3Sep 15, 2010 10:16PM

One more detail, Data Layer event calls from the watch to the phone (running Android 13) do work on if the listener is in an Activity or Fragment.

sd...@gmail.com <sd...@gmail.com> #4Oct 18, 2010 03:50PM

Also, I'm seeing this message in the Logcat:

"2022-06-12 18:47:15.156 1841-4562/? W/PackageManager: Intent does not match component's intent filter: Intent { act=com.google.android.gms.wearable.BIND_LISTENER"

sd...@gmail.com <sd...@gmail.com> #5Oct 19, 2010 09:26AM

Experiencing the same issues, please see my other report for any useful logs:

https://issuetracker.google.com/issues/235673375

sd...@gmail.com <sd...@gmail.com> #6Dec 18, 2010 10:25PM

+1, can confirm it doesn't work on Android 13:=

2022-07-15 11:26:15.023   589-5347  PackageManager          pid-589                              W  Intent does not match component's intent filter: Intent { act=com.google.android.gms.wearable.BIND_LISTENER cmp=xxx/xxx.WatchMessageReceiver }
2022-07-15 11:26:15.023   589-5347  PackageManager          pid-589                              W  Access blocked: ComponentInfo{xxx/xxx.WatchMessageReceiver}
2022-07-15 11:26:15.023   589-5347  ActivityManager         pid-589                              W  Unable to start service Intent { act=com.google.android.gms.wearable.BIND_LISTENER cmp=xxx/xxx.WatchMessageReceiver } U=0: not found

sd...@gmail.com <sd...@gmail.com> #7Dec 18, 2010 10:36PM

Note that I've been able to make it work by:

Adding <action android:name="com.google.android.gms.wearable.BIND_LISTENER" /> in the intent filter
Removing <data android:scheme="wear" android:host="*" />

But I feel like this is not something we should do

sa...@gmail.com <sa...@gmail.com> #8Dec 19, 2010 02:03AM

I'm really afraid Android 13 might get released as-is, breaking WearOS app communication 😨😨

sd...@gmail.com <sd...@gmail.com> #9Dec 19, 2010 12:53PM

If you're not targeting API 33 you're not affected by the bug. So it's a big bug, and yes we of course expected more from Google, but you can always target the api level later when it's fixed.

But I agree this is kind of desperating that more than 1.5 month after the first report nothing has changed.

gr...@google.com <gr...@google.com> Dec 30, 2010 01:48AM

Assigned to gr...@google.com.

ja...@gmail.com <ja...@gmail.com> #10Aug 12, 2011 08:24PM

As an interim update on this issue: we've been already working on the fix that should be available by Android 13 release. The fix requires thorough testing, I'll keep this bug updated as soon as we have more to share. Thanks!

ja...@gmail.com <ja...@gmail.com> #11Sep 16, 2011 01:45PM

@comment#9 The Play Store will eventually require targeting API 33, then 34, etc, so accepting this regression in a customer release would be a time ticking bomb for Wear OS apps.

Thank you for the update @comment#10

pr...@google.com <pr...@google.com> #12Oct 19, 2011 04:33PM

Reassigned to pr...@google.com.

Hey @

comment#10

, do you have any news to share?

Android 13 is out today and we still have no patch unlike what you said a month ago

sd...@gmail.com <sd...@gmail.com> #13Nov 20, 2011 11:56PM

I have no words for this. Android 13 is labeled "stable" but the Wearable API just doesn't work. Can't this issue be given higher priority? If you want to push WearOS you need to make sure it works normally.

ja...@gmail.com <ja...@gmail.com> #14Nov 26, 2011 05:50PM

This issues has been already given high priority (updated external priority on this bug to reflect internal status). The fix is on the way and going through the final rounds of testing, so the roll out is slated to next couple of weeks.

To reiterate what have been mentioned earlier on this bug: this issue affects only apps targeting Android 13, so the apps won't break unless you bump targetSDK version to 33. In case if you want to start working on app compatibility for Android 13 behaviour changes, you could use Compatibility framework to toggle on/off the changes individually for isolated testing.

ja...@gmail.com <ja...@gmail.com> #15Nov 27, 2011 01:59PM

comment#14

as much as I agree that is not a blocking bug, you need to understand that:
- The report is 2 months old
- Google chose to release Android 13 with that bug
- There's no mention of this bug on the documentation so you can totally bump your targetSdk without noticing it

So thank you guys for working on this but it's still not a valid excuse for taking that long for such an important issue. Now that being said, let us know when a fix is available

pr...@google.com <pr...@google.com> Apr 12, 2012 12:11PM

Status: New

be...@gmail.com <be...@gmail.com> #17Mar 9, 2013 04:34PM

That must be some really intense testing as we are 10 days later and still nothing on sight. I don't want to be a P2 issue if that's what a P1 is.

fr...@gmail.com <fr...@gmail.com> #18May 7, 2014 01:54AM

Is there an update on by when can we expect a fix for this? We are blocked on the app release which is targeting Android 13. We can't roll out if it doesn't support wear os app.

ab...@gmail.com <ab...@gmail.com> #19Jun 6, 2015 11:55PM

@Google Any updates here?

jp...@pettitt.net <jp...@pettitt.net> #20Jun 2, 2016 11:38PM

I have to imagine this needs to be fixed, at least, for the launch of the Pixel Watch.

[Deleted User] <[Deleted User]> #21Aug 1, 2016 03:18PM

My bet is that Google still targets API 32 (or even lower) internally so they don't care and didn't even saw the issue before our report.

[Deleted User] <[Deleted User]> #22Apr 18, 2022 05:17PM

Well, according to

https://issuetracker.google.com/issues/235538840#comment14 the fix must be in testing for over 5 weeks now. I guess it should be done soon™ /s.

he...@gmail.com <he...@gmail.com> #23Aug 2, 2024 09:13PM

This issue is fixed. The fix has been rolled out via GMSCore and will also require using the latest com.google.android.gms:play-services-wearable:18.0.0 release.

Note that you don’t need to add BIND_LISTENER manually, it has been deprecated for a long time and it continue to remain so (read more at https://android-developers.googleblog.com/2016/04/deprecation-of-bindlistener.html).

Appreciate all the feedback and patience.

Message last modified on Aug 3, 2024 12:07AM