Support https in the SDK for testing purposes [35877061]

Assigned

Feature Request

Status Update

No update yet.

Description

al...@gmail.com

created issue #1

Dec 28, 2008 06:53PM

“The development web server does not support HTTPS connections.
It ignores the ‘secure’ parameter, so paths intended for use
with HTTPS can be tested using regular HTTP connections to
the development web server.”

Google App Engine documenation,

http://code.google.com/appengine/docs/configuringanapp.html#Secure_URLs

It would be nice if the dev server did honor the ‘secure’ parameter and
allowed you to test how your site behaves over both http and https.
Sometimes you would like to serve different content when the same page is
accessed over http and over https. https support in the SDK would come
handy to test such a setup in advance.

Here is an example of why one might want to make the same page behave
differently when requested over https. The security requirements of my
https-only site prohibit automatic redirects from http URLs to their https
counterparts. If the

http://example.appspot.com URL works, some people will
use it. As a result, even when the users navigate to my site from a safe
source (by clicking on a bookmark, typing in a URL or following a link from
another https page), they would still be vulnerable to active attacks. As
their browser requests a page over unencrypted HTTP, the redirect to the
https URL could be intercepted and a fake page could be injected instead by
an attacker. Many users would not pay attention that they were using an
unencrypted version of the site until it is too late. So instead of a
redirect, the http:// version of my site will present an error message
explaining that you should only use it over https.

Comments

js...@gmail.com <js...@gmail.com> Jul 21, 2009 05:31PM

Assigned to js...@gmail.com.

na...@gmail.com <na...@gmail.com> #2Mar 14, 2011 07:51AM

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

ne...@gmail.com <ne...@gmail.com> #3Jan 14, 2012 10:44AM

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.

lu...@ciandt.com <lu...@ciandt.com> #4Nov 13, 2015 07:21PM

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"

va...@gmail.com <va...@gmail.com> #5Nov 13, 2015 10:10PM

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

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

vl...@webocrat.com <vl...@webocrat.com> #6Nov 14, 2015 08:55AM

+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

ji...@manicode.com <ji...@manicode.com> #7Jul 13, 2016 06:58AM

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

br...@gmail.com <br...@gmail.com> #8Sep 7, 2016 08:38PM

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

rh...@gmail.com <rh...@gmail.com> #9Jan 29, 2017 05:50PM

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.

dc...@gmail.com <dc...@gmail.com> #10Aug 14, 2017 05:18PM

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!

le...@gmail.com <le...@gmail.com> #11Dec 28, 2017 08:49PM

@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

lu...@ciandt.com <lu...@ciandt.com> #12Dec 29, 2017 01:30AM

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

le...@google.com <le...@google.com> #13Mar 28, 2018 07:19PM

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.