Obsolete
Status Update
Comments
ra...@google.com <ra...@google.com> #2
Agreed, you can download photos via the Google Drive API but this hasn't been incorporated into the Photos API yet...
el...@gmail.com <el...@gmail.com> #3
There's already an issue tracking the missing EXIF data here: https://issuetracker.google.com/111228390
Regarding the file at original quality - this is something that's on our list and will be addressed soon, please stay tuned. I'll update this bug once we have an update to share.
Regarding the file at original quality - this is something that's on our list and will be addressed soon, please stay tuned. I'll update this bug once we have an update to share.
el...@gmail.com <el...@gmail.com> #4
We have just released a new version of the Google Photos Library API that supports now this feature.
You can now use the "d" base URL parameter to download the original photo. See the base URL parameter guide for more details:https://developers.google.com/photos/library/guides/access-media-items#image-base-urls
Thanks for your patience!
See our release notes for further detail:https://developers.google.com/photos/library/support/release-notes#2018-07-31
You can now use the "d" base URL parameter to download the original photo. See the base URL parameter guide for more details:
Thanks for your patience!
See our release notes for further detail:
ma...@gmail.com <ma...@gmail.com> #5
I've been testing downloading images using the "d" parameter, but the files returned are not the original files that were uploaded. The release note above reads "d download parameter, to download the original image". The link to the developer documentation doesn't say that the "original" image will be downloaded. Please can you confirm if the d parameter should download the original image that was uploaded to the api, or if this behavior has since changed.
Description
My app has a
TileService
, and the quick tiles are used for toggling on and offVpnService
s. For that, I have code like this:Basically, I try to start the service in the usual way, but if that fails because the app is backgrounded, then I start a transparent activity to start the service for me. This has worked well for some time. The result is that the quick tile toggles on or off, the same way that toggling on and off bluetooth or airplane mode or the flashlight works. Most importantly, the quick settings panel does not collapse, since it's a toggle switch.
In Android 14, this stopped working, because of this code in TileLifecycleManager.java:
As you can see,
BIND_ALLOW_BACKGROUND_ACTIVITY_STARTS
is no longer passed to the service when theSTART_ACTIVITY_NEEDS_PENDING_INTENT
change flag is enabled, which it is for API 34 and up.Note that using
startActivityAndCollapse()
isn't a viable option, because that collapses the quick settings panel. The whole idea is for this to function like any other quick settings tile toggle switch and not collapse, which is how it's worked for years.I believe this is largely a mistake. The documentation for this change states:
Yet, with this change, that doc is no longer honored, as
startActivity
now fails in API 34, despite there being aTileService
bound by the system, exactly as the doc described.This further seemed to be a last minute mistake made, as the isn't listed on the Android 14 compatibility flag page . It looks like maybe the initial goal was to enforce the deprecation of
START_ACTIVITY_NEEDS_PENDING_INTENT
compat flag actuallystartActivityAndCollapse(Intent intent)
, taking anIntent
rather than aPendingIntent
as in the new API, but overall change has the likely unintended side effect of also removing the ability to start an activity without collapsing the quick settings panel.So, this seems to be a bug that can hopefully be rectified during the Android 14 cycle ASAP.