Send email from alias domain [35889105]

Assigned

Feature Request

Status Update

No update yet.

Description

mk...@gmail.com

created issue #1

Feb 10, 2011 04:03PM

We are have domain registered as Google Apps account, let it be

corpdomain.com, also it have registered alias

productdomain.com.

Productdomain.com is an independent project with own user base. And it sends some emails when users register or got updates. That mean that we want to send automatic emails from no-reply@productdomain.com. But I cann't add this email as administrator to GAE as I cann't login under this Google Account. Even if I can send invite to no-reply@productdomain.com I'm open email in Google Mail interface as no-reply@corpdomain.com and click to invitation GAE adds new administrator as no-reply@corpdomain.com.

So, I wish that alias domains can be added to GAE safe list and application can send emails from appropriate email address.

I lurked Groups archive and found other email that asks for this feature:

-

http://groups.google.com/group/google-appengine/browse_thread/thread/ee0bb8715fca5f48/
-

http://groups.google.com/group/google-appengine/browse_thread/thread/89f2f236afc4f013/

Comments

pe...@google.com <pe...@google.com> Jul 23, 2011 01:07AM

Assigned to pe...@google.com.

ma...@longhome.co.uk <ma...@longhome.co.uk> #2Sep 3, 2011 11:54PM

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

po...@gmail.com <po...@gmail.com> #3Jan 19, 2012 03:02PM

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.

pr...@google.com <pr...@google.com> #4Jan 19, 2012 04:06PM

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"

pe...@pepto.de <pe...@pepto.de> #5Feb 13, 2012 12:15AM

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

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

lu...@gmail.com <lu...@gmail.com> #6May 12, 2012 01:59PM

+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

ko...@koma.be <ko...@koma.be> #7Feb 26, 2013 07:17PM

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

gr...@vig.co.nz <gr...@vig.co.nz> #8Aug 10, 2013 08:00AM

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

jj...@jameslow.com <jj...@jameslow.com> #9Aug 10, 2013 08:15AM

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.

jj...@jameslow.com <jj...@jameslow.com> #10Sep 15, 2013 07:23AM

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!

da...@elstensoftware.com <da...@elstensoftware.com> #11Dec 6, 2013 05:29PM

@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

jo...@gmail.com <jo...@gmail.com> #12Mar 25, 2014 07:11PM

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

st...@lightningrodgames.com <st...@lightningrodgames.com> #13Mar 25, 2014 07:31PM

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.

jo...@gmail.com <jo...@gmail.com> #14Mar 25, 2014 07:38PM

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.

je...@gmail.com <je...@gmail.com> #15Mar 25, 2014 07:40PM

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

af...@topsolutions.pt <af...@topsolutions.pt> #16Mar 25, 2014 07:46PM

Google will come through. They always do!

po...@gmail.com <po...@gmail.com> #17Mar 25, 2014 07:52PM

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.

ma...@mattburns.co.uk <ma...@mattburns.co.uk> #18Mar 27, 2014 02:41PM

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.

[Deleted User] <[Deleted User]> #19Mar 27, 2014 02:42PM

@Google Any updates here?

jj...@jameslow.com <jj...@jameslow.com> #20Apr 12, 2014 07:43PM

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

mr...@gmail.com <mr...@gmail.com> #21Sep 2, 2014 12:26PM

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.

sh...@gmail.com <sh...@gmail.com> #22Nov 16, 2014 05:42AM

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.

sh...@gmail.com <sh...@gmail.com> #23Nov 16, 2014 05:53AM

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.

ni...@gmail.com <ni...@gmail.com> #24Dec 14, 2014 11:32PM

WearableListenerService doesn't react on data changes after updating to sdk 31

ju...@irungaray.com.ar <ju...@irungaray.com.ar> #25Apr 10, 2015 07:27PM

Hey @comment#23 I can confirm the fix doesn't work. Tested on Pixel 6 Pro running Android 13 and a Pixel Watch running WearOS 3.5, things are working great if my app targets API 32 but doesn't when targetting API 33 using com.google.android.gms:play-services-wearable:18.0.0.

After 4 months of testing, it looks like it's broken.

[Deleted User] <[Deleted User]> #26Jun 28, 2015 02:12PM

It's something on your end because the fix works.

ab...@gmail.com <ab...@gmail.com> #27Jul 5, 2015 03:33PM

Well that's possible but I've tested things carefully and targetting API 32 immediately fixes the behavior so I'm confident this is the root cause of the issue

ro...@gmail.com <ro...@gmail.com> #28Jul 29, 2015 03:52PM

Can you share the configuration code you have for the affected service from your AndroidManifest.xml file?

[Deleted User] <[Deleted User]> #29Aug 14, 2015 09:19AM

Sure thing, you can find them both in the commit that rolls back to targetting API 32: https://github.com/benoitletondor/PixelMinimalWatchFace/commit/604bdc2b640431a1216653c65f3bb86feda9a124

so...@aw2023.com <so...@aw2023.com> #30Dec 16, 2015 06:56PM

Sorry, wrong link:

ma...@mattburns.co.uk <ma...@mattburns.co.uk> #31Dec 17, 2015 12:23PM

It's weird. I checked the codebase, and I don't see why it'd not be working.

Are you 100% sure that the apk deployed was not an old one with the
old library version for example?
Since there's been some issues with that in past Android Studio versions
and AGP, and since I'm not sure if it's fully fixed and which versions did,
I'd try to run the clean Gradle task, and then run the install task from
command line, and also make sure you're not trying the wrong
buildType/variant.

Please keep us updated.

On Sun, Oct 23, 2022 at 3:56 PM <buganizer-system@google.com> wrote:

- Show quoted text -

js...@google.com <js...@google.com> Mar 30, 2017 03:48PM

Reassigned to gc...@google.com.