Documentation about media3 , Android 13 and dismissible foreground notification

Documentation about media3 , Android 13 and dismissible foreground notification
I recently came across this video about migration to Android 13
https://youtu.be/wBx3-ZObxY8?t=158
The new android 13 will be available soon and the new feature that it has is dismissible foreground notification  , this is a critical feature for background music player apps . Although it has been mentioned the mediasession notifications are exempt from the new notification permissions there are few doubts that we have

will the notification be dismissible  even when the song is being played
how will it be handled when the song is stopped
few other which we came across similar to these

https://github.com/androidx/media/issues/205
https://github.com/androidx/media/issues/175
A proper documentation will be helpful
PS: the primary objective of foreground service was to indicate a service is running, with the help of notification as mentioned here
https://developer.android.com/guide/components/foreground-services
Foreground services perform operations that are noticeable to the user.
Foreground services show a [status bar notification] so that users are actively aware that your app is performing a task in the foreground and is consuming system resources
so if the notification is dismissible how different does it become from a background service and if the service is "tied" to the notification how do we handle the closing of our service and the app, (should we use some thing similar to this )
https://stackoverflow.com/questions/6330200/how-to-quit-android-application-programmatically
or any other standard that android will prescribe.

If you are using  MediaSessionService or MediaLibraryService from the Media3 library in its default configuration, then the service always creates a media session and posts a media style notification either by using startForeground(int, Notification) (when playing) or an ongoing notification with the NotificationManagerCompat (when paused).
The idea of the Media3 library is to smooth out the differences regarding API versions. So strictly speaking it should just work for you in the default configuration and you don't need to care about API levels yourself. If it doesn't work then please file a bug.
So a first step is using Media3 on an Android 13 device and see how this works. You can use the session demo app for this if you haven't migrated your app to Media3 yet.

has is dismissible foreground notification , this is a critical feature for background music player apps

Like you say, there is a mini player for each active media session. The mini player can't be dismissed.

will the notification be dismissible even when the song is being played

The mini player can't be dismissed. It is removed when you remove the notification with the session attached to it.

how will it be handled when the song is stopped

When playback is paused, the service is taken off the foreground and a notification is posted with the notification manager. The mini player is still not dismissible

so if the notification is dismissible how different does it become from a background service

There is a mini player that is not dismissible.

how do we handle the closing of our service

Not sure I understand and how this is different on Android 13 but you can call for instance stopSelf() to close the service. Given you have overriden onDestroy() and clean all your resources there, the player is stopped and released which makes the media session remove the notification by default. This also removes the mini player.

and the app

You can override service.onTaskRemoved(intent).

When playback is paused, the service is taken off the foreground and a notification is posted with the notification manager. The mini player is still not dismissible

I just kind of give up of restoring the state of my app from dead state with this dangling notification (e.g. When pausing a playback, killing the app, then going to play from notification).
So I decided might be best that if I paused a playback, and when user dismiss the app, it should also kill that notification player.
How do I override this behavior and just dismiss the notification?

How are these two use cases related?
Even if you do not implement playback resumption from BT you can keep your app playing in the background when the users exits the app.
I'm not trying to convince you for one or the other UX option. My point is that stopping the service when the user dismisses the app is not related to support playback resumption from BT..
From the PlaybackService of the demo app:
  override fun onTaskRemoved(rootIntent: Intent?) {
    if (!player.playWhenReady) {
      stopSelf()
    }
  }

Please also pay some attention to this comment.

@marcbaechinger – We aim to provide the following UX for our users:

Only dismissable notifications should be shown. When a user explicitly dismisses the notification, the playback should be paused or stopped.
If the user kills the app from recent apps, all notifications should be removed.

Currently, I'm facing challenges with achieving the first requirement. Based on your comments and observations of the app's behavior, it seems that achieving this may not be possible. I'm curious to understand the impact of setting setOngoing(false) and why it doesn't make the notification dismissable. Is there any way to create a non-ongoing notification for media3 library users without custom implementation?
Regarding the solution you provided with stopSelf() and mediaSession.release(), it helped me achieve the second requirement. However, if the app is reopened immediately (within 5 seconds of being killed), the app fails to play the media. I'm encountering errors stating "mediaController is not connected," which suggests that the previous mediaController instance remains in memory after killing the app. Would you recommend having a single mediaController per media item or a single mediaController per app? The latter approach has been working fine until now. We are experiencing these issues after updating the targetSdk.

Upon conducting further testing, I have discovered that the "mediaController is not connected" issue occurs when the back button is pressed repeatedly to close all activities. It appears that in such cases, the onTaskRemoved method of the service is invoked, while the application remains in the memory.

Based on your comments and observations of the app's behavior, it seems that achieving this may not be possible.

This is based on a foreground service requiring a notification when running in the foreground.

Based on your comments and observations of the app's behavior, it seems that achieving this may not be possible.

This is based on a foreground service requiring a notification when running in the foreground.

Shouldn't users have the ability to dismiss the notification and forcefully terminate the app from which the notification originated?
I believe that displaying persistent notifications may result in users uninstalling our app and could have a negative impact on our brand reputation. Is there a version of MediaSessionService and MediaLibraryService that can be removed from the foreground when the user exits the app or selectively made foreground?
I wonder how WhatsApp & YouTube do it. Both do it well and they don't show any notification at all.

Shouldn't users have the ability to dismiss the notification and forcefully terminate the app from which the notification originated?

Not by the library. I agree that an app should be able to do this if it really wants to.
With the current default implementation, I think you can do this by a custom action  that is placed on the notification and tears down the service.
you can also override MediaSessioService.onUpdateNotification (see below).
Aside from that: Are you able to get an event from the OS notifying the the swipe gesture when the foeground notification is dismissed on all API levels? As far as I can tell this is not possible on the most recent API levels. If you find a system API that we can use, then it would make sense that we expose this API to apps. I think there isn't such an API that is available on all API levels though. If you can educate me about such an API being available, we can make this an enhancement to expose the API so you would be able to destroy the service yourself. I don't think we will implement the behavior described by you as a default.

I wonder how WhatsApp & YouTube do it.

These apps always have an activity in the foreground when they are playing.
The default implementation of MediaSessionService is currently mainly for background playback which requires the most difficult logic. We are aware that there are use cases that do not involve background playback that we do not cover yet.
However, if you have an app that doesn't do background playback then you can solve this without a foreground service but instead always be bound to the service. That's a valid approach and should be comparably easy to implement. If you want to do this, then you can override MediaSessioService.onUpdateNotification and implement your own logic that never puts the service into foreground and hence never posts a notification.

Thank you, @marcbaechinger, for providing a prompt and detailed explanation. I appreciate your suggestion to try overriding the onUpdateNotification() method, and I will give it a try.

@marcbaechinger, Isn't deleteIntent meant to be used for handling notification dismissals? Looks like it is available since API 1. Am I missing something?
https://developer.android.com/reference/android/app/Notification#deleteIntent

Another related issue is the race condition between the onUnbind() (in my case ~ 100 ms after mediaBrowser.release()) and onTaskRemoved(). If the onTaskRemoved() comes first and it calls stopSelf() then the onUnbind() never gets called and I'm stuck with a disconnected notification. Then I need to click on the notification to launch the app that restores the service.
A working workaround is to track the number of bound clients and call stopSelf() when the last one is unbound in case the onTaskRemoved() was called beforehand.

Hi, thanks for response. I use Pixel 6a with Android 13.
Of course, I only try to stop the service and release the player if playWhenReady == false and onTaskRemoved() is called.
If onTaskRemoved() that calls stopSelf() is called before the last client manages to unbind then we get into state where notification is still present but it's broken. Usually this happens if there are multiple media sessions live, otherwise the onUnbind() outspeeds the onTaskRemoved() and everything is fine.
The easiest way to experience this broken notification is to move releaseBrowser() from onStop() to onDestroy() in MainActivity of media-session demo app.

We have updated the guide pages on developer.android.com. Specifically these three pages are extended and adjusted to the newest release:

https://developer.android.com/guide/topics/media/session/mediasession
https://developer.android.com/guide/topics/media/session/mediasessionservice
https://developer.android.com/media/implement/surfaces/mobile

I'm closing this issue which is about documentation.
@JureSencar If your case still is a problem, can you please file a new issue specifically around your case?


added handling for WNOHANG

There was a misleading return of state if you passed WNOHANG, it returned "exited". But waitpid() returns 0, which means that nothing happened. So I added an extra state "running", which is now returned instead of "exited"
Fixed syntax error from previous pr #291

Merging.  Thank you!

I also fixed the LDoc documentation, and added a NEWS item in the following commit b9a6921d.

Thanks, I didn't get where I could change the LuaDoc


mypy: pglookout/webserver.py [BF-1560]

Also in this commit:

Alphabetically sort configuration keys in the README. This has the effect of grouping related keys closer.
Add missing key: replication_catchup_timeout

Codecov Report
Patch coverage: 100.00% and project coverage change: +1.29 :tada:

Comparison is base (305df9d) 68.00% compared to head (139ada0) 69.29%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #101      +/-   ##
==========================================
+ Coverage   68.00%   69.29%   +1.29%
==========================================
  Files          10       11       +1
  Lines         972     1013      +41
  Branches      170      169       -1
==========================================
+ Hits          661      702      +41
  Misses        253      253
  Partials       58       58

Impacted Files
Coverage Δ

pglookout/config.py
100.00% <100.00%> (ø)

pglookout/webserver.py
93.33% <100.00%> (+0.35%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

ℹ  For the reviewers: Please note this one is based on #96 .

This PR and the other ones related to type hinting will be handled in https://github.com/aiven/pglookout/pull/106.


STP-3181: Updated language in ConMan intro topic

Summary and Scope
Removing the new in release 1.5 verbiage in the ConMan introduction topic for CSM 1.2+ releases.
Issues and Related PRs

Resolves STP-3181

Testing
N/A
Tested on:
N/A
Test description:
N/A
Risks and Mitigations
None.
Pull Request Checklist

[ ] Version number(s) incremented, if applicable
[ ] Copyrights updated
[ ] License file intact
[ ] Target branch correct
[ ] CHANGELOG.md updated
[ ] Testing is appropriate and complete, if applicable
[ ] HPC Product Announcement prepared, if applicable

/backport release/1.2


Provided IPA doesn't work with Impactor

The (c7f49ca) provided IPA throws the following error when signing with Impactor:

If you're building on Xcode 10, you can go to Product > Archive and archive the project successfully.  - After this, right click the archive and Show in Finder.
Next, Show the Package Contents of the File and navigate to the Products/Applications directory where you can find Undecimus.app.
Create a folder named Payload and copy Undecimus.app into the Payload folder.
Next, compress the file and rename the compressed file to Undecimus.ipa.

If you look at the actual "ipa file" I think you'll see why: it's not an ipa. We had previously hosted the latest unc0ver release at https://github.com/pwn20wndstuff/Undecimus/blob/master/Resources/Undecimus.ipa but we've started using GitHub releases now, and so we replaced the old IPA with a text file that we have set up to redirect any lost puppies who happen to find the old link online somewhere to what they're looking for.
Unfortunately, we can't change the name or extension of Undecimus.ipa, or else the link will also change.


left join preload with without distinct returns wrong number of rows

Environment

Elixir version: Elixir 1.2.3
Database and version: psql (PostgreSQL) 9.4.4
Ecto version (mix deps): 1.1.5
Database adapter and version: postgrex 0.11.1
Operating system: Mac OS X 10.11.4 (El Capitan)

Current behavior
from users in User,
  left_join: subscriptions in assoc(users, :subscriptions),
  preload: [subscriptions: subscriptions]

Will not return duplicates while:
from users in User,
  left_join: subscriptions in assoc(users, :subscriptions),
  preload: [:subscriptions]

will.
Is this expected behaviour?
If the first example is combined with a limit the number of result will be less than the limit even if the total number of rows are greater than the limit.
They all generate the same SQL (execept for the extra columns when preloading with the join):
SELECT
  u0.\"id\", u0.\"token\", u0.\"icloud_ref\", u0.\"name\", u0.\"role\", u0.\"blocked\", u0.\"block_reason\", u0.\"inserted_at\", u0.\"updated_at\", u0.\"team_id\"
FROM
  \"users\" AS u0
LEFT OUTER JOIN
  \"subscriptions\" AS s1 ON s1.\"user_id\" = u0.\"id\"

Adding distinct: users.id removes the discrepancy (and duplicates)
Expected behavior
I expected a :left_join to return duplicates if the left table has several rows per right table independent of the :preload statement.

Yes, that's expected behavior. When you preload in the first case, Ecto is
going to merge all duplicate entries. In the second one, Ecto is doing two
queries, one for fetching all users and another for fetching preloads. If
you want to keep duplicates, then you likely don't want to use preload at
all. For example:
from users in User,
left_join: subscriptions in assoc(users, :subscriptions), select:
{users, subscriptions}
--
José Valim
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D

@josevalim I think this behaviour is very counter intuitive, I found myself with the exact same problem, I didn't know what was going on... I expected the same thing as @ramhoj .
Is it documented? The only related doc I found is this:
https://hexdocs.pm/ecto/Ecto.Query.html#preload/3
"(...) Therefore, instead of returning number_of_posts * number_of_comments results, like a join would, it returns only posts with the comments fields properly filled in. (...)"
but in my opinion it doesn't describe this situation. Maybe it makes sense to state it explicitly in the docs that duplicates are removed?


Created a basic automation

Based on expect
Pull Request Checklist
Author

[x] Built code and tested locally
[x] Removed any TODOs, etc.
[x] Metioned the issue this PR closes
[x] Good description of what the PR does written

Reviewer

[ ] Built and tested code locally
[ ] Fully understood the PR
[ ] All open conversations resolved

Script collection for device setup and commissioning
It has been developed on and for Linux, but adjusting it for MacOS should be possible.


Set HostUsers=false for unprivileged build pods + UserNamespaces

If the UserNamespacesStatelessPodsSupport feature is enabled (known in 1.25 and later, since https://github.com/kubernetes/kubernetes/pull/111090), set HostUsers=false for unprivileged build pod specs, in addition to continuing to set the non-standardized annotation that older versions of CRI-O could be configured to accept instead.

/retest-required

/remove-lifecycle stale

/remove-lifecycle stale

Yep, holler if it needs a rebase.

/assign @coreydaley
for lgtm

/approve
/lgtm

/label px-approved
/label docs-approved
/label qe-approved

@nalind It looks like you need to setup a bug in JIRA for this to be merged (and possibly backported?)

@nalind It looks like you need to setup a bug in JIRA for this to be merged (and possibly backported?)

Created BUILD-596.  It won't make sense on anything earlier than 4.12, since 4.11 was based on Kubernetes 1.24, which doesn't know about the feature.

/retest

/retest

/retest

@coreydaley PTAL

/test e2e-aws-ovn-proxy

/retest

@coreydaley PTAL

/approve
/lgtm

Holding because https://kubernetes.io/blog/2023/09/13/userns-alpha/ notes that the feature gate is being renamed in 1.28, and I don't think this is getting merged until 4.15 at least.
/hold


PETSc broken on aarch64-darwin

Describe the bug
Building PETSc fails on aarch64-darwin.
Steps To Reproduce
Steps to reproduce the behavior:

Check we're on a recent commit

> nix-instantiate --eval -E '(import <nixpkgs> {}).lib.version'
"22.05pre356557.74b10859829"

Try to build the default PETSc derivation: nix-shell -p "petsc" The ./configure step fails with the message "Cannot determine Fortran module include flag". If we rebuild the derivation with

nix-build /nix/store/swcdfv4pn4g23gsg1jppn8xs8algrj1s-petsc-3.16.4.drv --keep-failed

and check the configure.log file, there are errors similar to what is seen in #158730.
I am about to submit a fix similar to https://github.com/NixOS/nixpkgs/pull/158992.
Expected behavior
The derivation should build.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
aarch64-darwin system.
Notify maintainers
@cburstedde
Metadata
 - system: `"aarch64-darwin"`
 - host os: `Darwin 21.1.0, macOS 12.0.1`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.4`
 - channels(root): `"nixpkgs-21.11pre332093.7fad01d9d5a"`
 - channels(jack): `"nixos-22.05pre356435.7f9b6e2babf, nixpkgs-22.05pre356557.74b10859829"`
 - nixpkgs: `/Users/jack/.nix-defexpr/channels/nixpkgs`

Fixed by https://github.com/NixOS/nixpkgs/pull/161451
Thanks!


[New game]: Car Traffic Game

🎮 Game Request
Game logic and basic description
A car game, where you have to avoid the traffic such that your own car does not collide with other cars.
Point down the features
Game points
you have to control your own car using A and D keys, just as you would in an actual PC game.
Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @SoarinSkySagar !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

Hey @SoarinSkySagar!
We are already having a similar game request in #991 👀
Make sure you come up with a cool unique idea 😀
Waiting for your new game idea 💗.

Hey @SoarinSkySagar ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


Support for Detach Tracking State

Is there a way to create a Detached TrackingState?
I'm running into a problem where I want to detach a graph of objects but the service/repo seems to only detach the top level entity.  When I go to save the entity it complains that another entity with the same id already exists but it should be part of the detached object graph.
My reason for doing this (and perhaps there is a better way, which I'm very open to) is that I want to track/record the changes to certain fields of my entity into another table (ChangeHistory).  In order to do that in my API controller I do the following.
               var original = _bulletService.GetById(dto.Id);
               _bulletService.Detach(original);
               if (original == null)
                   return NotFound();

               var bullet = EntityFactory.Parse(original, dto);
               _bulletService.ApplyChanges(bullet);
               _bulletService.Update(bullet);
               await _unitOfWork.SaveChangesAsync();
               _bulletService.AcceptChanges(bullet);

               //-- Save changes to Bullet
               var transactionId = Guid.NewGuid();
               var timeStamp = DateTime.Now;
               var changes = _bulletService.GetChanges(transactionId, timeStamp, original.CompositeKey, _currentUser, original, bullet);
               if (ListUtils.IsNonEmptyList(changes))
               {
                   changes.ForEach(x => _changeRecordService.Insert(x));
                   await _unitOfWork.SaveChangesAsync();
               }

The Parse function creates a copy of the original with the dto information overlain but does not overwrite the original to be used later as in a comparison.
If I could mark each entity in original as not tracked or Detached then I could avoid the error.

@tonysneed is there anything he do here with Trackable?

Detaching entities is an EF Core feature, and the default behavior is non-recursive, meaning they are detached one at a time. If you want to detach all the entities that are being tracked by EF, you will need to do this yourself from within your service. See this SO answer for an example.

Closing for now. Please re-open if needed.


Extern for the delegate used to hook new command line additions.

[x] @waneck

Just externing a new delegate added in UnrealEngine. See my WM_COPYDATA branch on that repo for details.

Looks good! :+1:
Feel free to merge once the changes are in


Mention that arrow functions don't need return

As far as I'm aware this only applies to single-line arrow functions. Observe:

Indeed, this PR is incorrect. The expression-bodied case is already covered by the existing text.

I've corrected the mistake. In master, the example does demonstrate that return is not required for the expression-bodied case, but it does not demonstrate that return is required for the statement-bodied case.

Yes, but the point of this project is not to educate on all aspects of JS, not even all aspects of ES6. The point of this project is to highlight in a high-level way what new stuff people can get with ES6. There's tons of nuances to ES6 that aren't even remotely covered here. That's the job of comprehensive ES6 books. FWIW, I have a running list of them here: https://gist.github.com/getify/7ae82fdc2e86bf66bcba

I'll leave it to you to decide whether this is a nuance or a pretty essential part of how arrow functions work. I would say it's on the same level of importance as the sentence "Unlike functions, arrows share the same lexical this as their surrounding code."

I would say it's on the same level of importance as

The reason I disagree is that "lexical this" is actually a new feature being added to the language -- in fact, it's the primary design motivation for arrows, not just a side effect -- so it clearly deserves to be highlighted. By contrast, the need for return in some cases like with { .. } is a side-effect of grammar rules. return obviously isn't being added to the language here.

I made a slight tweak to the description of statement and expression bodies to make this a little clearer in 3d885921c2052befcef84db28c3b34fc038fd2a5.