WAI
Status Update
Comments
vi...@google.com <vi...@google.com>
vi...@google.com <vi...@google.com> #2
Fixed by
mm...@commonsware.com <mm...@commonsware.com> #3
Was this released in 7.1.1? I've re-run the sample posted here with 7.1.1 and my own test app, and this issue still seems to persist. Just for completeness, it appears that 7.3.0-alpha01 and 7.2.0-beta01 both appear to work fine.
vi...@google.com <vi...@google.com> #4
7.1.1 only included 2 critical Studio fixes in order to release very quickly with minimum testing, so the fix will be included in 7.1.2. Apologies for the inconvenience.
mm...@commonsware.com <mm...@commonsware.com> #5
Thanks for the update. Will be waiting for 7.1.2.
vi...@google.com <vi...@google.com> #6
"7.1.1 only included 2 critical Studio fixes in order to release very quickly with minimum testing"
Thanks for the info. Where can I find the release notes for 7.1.1? Can't see anything herehttps://developer.android.com/studio/releases/gradle-plugin
Thanks for the info. Where can I find the release notes for 7.1.1? Can't see anything here
re...@gmail.com <re...@gmail.com> #7
ro...@gmail.com <ro...@gmail.com> #8
steamkar id 573918761
so...@gmail.com <so...@gmail.com> #9
support topup
lu...@gmail.com <lu...@gmail.com> #10
I understood. Some users were tricked into setting a malicious camera app as the default and then using it to capture things that should have remained private
Ke...@empulsegaming.com <Ke...@empulsegaming.com> #11
"I fully disagree with how the Android team is implementing this change. Can we at least please have a new developer option to allow us to have the choice back?"
I agree with removing the up front choice BUT, I disagree completely with removing CHOICE COMPLETELY, I also vote for a developer menu option to allow this function to return with the same annoying danger warning messages if directed to do so.
I agree with removing the up front choice BUT, I disagree completely with removing CHOICE COMPLETELY, I also vote for a developer menu option to allow this function to return with the same annoying danger warning messages if directed to do so.
te...@gmail.com <te...@gmail.com> #12
Such a bad idea, one of the founding principles of Android was the open nature and the ability to pick what apps to use for each task. Eliminating these choices makes you just like apple, closed eco system with limited innovation. Its sad a couple of users have fallen for malware, that is not your problem to solve.
si...@gmail.com <si...@gmail.com> #13
This will break a bunch of automation tools I've used over the years, stuff I've invested money and work in. Pretty irresponsible way to dump on your customers.
he...@gmail.com <he...@gmail.com> #14
Remember when Android was actually good for power users?
mr...@gmail.com <mr...@gmail.com> #16
Hey guys, this isn't acceptable. I don't want an iPhone. Do you remember the bad old days where every manufacturer had to fix your broken OS? That's where we're headed again if you keep this up. Rethink this, please, just like you thankfully rethought banning password apps from autofilling.
vo...@gmail.com <vo...@gmail.com> #17
Is there an explanation to justify such an important change and who is responsible for it?
fr...@gmail.com <fr...@gmail.com> #18
Could you please explain the reason for this change? how on earth does it protect the privacy and security of your users? It's not like third party camera apps just magically pop up on a users device, they install them themselves by choice and if they do just pop up on the users devices I think there are some bigger problems to privacy and security
ya...@gmail.com <ya...@gmail.com> #19
This close minded behaviour is highly unlikely of Google. I hope you will rethink this choice.
If you want to protect the privacy and security of users, you should harden your playstore policies instead.
If you want to protect the privacy and security of users, you should harden your playstore policies instead.
da...@gmail.com <da...@gmail.com> #20
Remember when Android was actually good for (power) users?
fe...@gmail.com <fe...@gmail.com> #21
This is unacceptable. What about users' freedom to choose whatever camera app they want to use as the default?
If it's actually about security and/or privacy just add a proper warning instead.
If it's actually about security and/or privacy just add a proper warning instead.
ac...@gmail.com <ac...@gmail.com> #22
It's a shame ... what's next ? Locking everything to the default one ( sms , browser , cellphone ... ) ?
rd...@gmail.com <rd...@gmail.com> #23
If developers want to use the stock camera app, they should instead call IT by its specific package name.
an...@gmail.com <an...@gmail.com> #24
Is this a Google decision or have manufacturers asked Google for it, so users can't override the stock camera? I can see reasons for manufacturers for wanting this, like not wanting camera apps that don't support all the device's camera sensors/features/quality.
go...@gmail.com <go...@gmail.com> #25
This new trend came from apple, and google is adapting...
Thanx god that our xperiaa getring mainlined and we can use GNU/Linux like Arch with gnome, or mobile distros like postmarketos...
Thanx god that our xperiaa getring mainlined and we can use GNU/Linux like Arch with gnome, or mobile distros like postmarketos...
ka...@gmail.com <ka...@gmail.com> #26
Google, please don't become like apple and restrict the end users choice...
ge...@gmail.com <ge...@gmail.com> #27
it would be nice if we could keep an option hidden somewhere that can still keep the functionality and still give us the option if we want to use a 3rd party app.
dy...@gmail.com <dy...@gmail.com> #28
I am absolutely appalled that this is Google's definition of "working as intended." What has happened to this platform? What happened to prioritizing choice and making this OUR device, and not some extension of the manufacturer?
I understand you care about privacy and security, but this is chasing a minor problem and "fixing" it with an inconvenient and ass-backwards solution. If you care about privacy, warn and educate your users on the concerns of allowing those apps camera access in the first place. Any third party camera app can still "harvest EXIF data" if used directly. Any gallery app can still query data from existing pictures. This doesn't solve your problem, it simply puts more burden on entirely unrelated applications just looking for a photo. Ham-fisting a severely limiting solution to solve this problem for you is making users and app developers pay the cost instead of the OS taking responsibility for its own job. Security and user education around application threats are the responsibility of the OS. This doesn't solve the problem and makes our lives harder.
Posing querying and parsing package names looking for camera apps and forcing developers to do this kind of matching is completely against the philosophy Android set out with. What a laughable joke of a proposition.
I understand you care about privacy and security, but this is chasing a minor problem and "fixing" it with an inconvenient and ass-backwards solution. If you care about privacy, warn and educate your users on the concerns of allowing those apps camera access in the first place. Any third party camera app can still "harvest EXIF data" if used directly. Any gallery app can still query data from existing pictures. This doesn't solve your problem, it simply puts more burden on entirely unrelated applications just looking for a photo. Ham-fisting a severely limiting solution to solve this problem for you is making users and app developers pay the cost instead of the OS taking responsibility for its own job. Security and user education around application threats are the responsibility of the OS. This doesn't solve the problem and makes our lives harder.
Posing querying and parsing package names looking for camera apps and forcing developers to do this kind of matching is completely against the philosophy Android set out with. What a laughable joke of a proposition.
dy...@gmail.com <dy...@gmail.com> #29
Also, I hope Google recognizes the irony of including a "backdoor" in their response about this being for security and privacy.
ar...@gmail.com <ar...@gmail.com> #31
I hope even after this gets reverted someone asks about the decision making that lead to this change happen in the first place. Also, what a lame response that "engineers believe it was a security risk", that's just hiding behind "natural forces".
pe...@gmail.com <pe...@gmail.com> #32
To the Google team, please clarify how this change is protecting user’s location privacy, over the location changes that were already introduced in the previous Android 10.
Starting in Android 10, the system redacts the geo-location from all photos, so any app requires the location permission to access such data, which needs to be granted by the user, and in addition the Media Store doesn't hold anymore location data.
The changes made in Android 10 seem to be already addressing all possible issues. And unless a user gives the location permission to any app that eventually picks a camera app, there is no way it could access any location information.
If the issue is about apps which are not targeting Android 10 or 11, then enforce the rule instead of cutting off user's choice.
If the issue is deeper and goes beyond the location permissions, then fix the root cause of the problem, instead of cutting off the possibility of apps becoming a user's main camera choice.
This change can seem anticompetitive as it gives top priority to vendors apps, relegating to a second plane third-party apps, as they cannot be anymore a user's main choice.
Starting in Android 10, the system redacts the geo-location from all photos, so any app requires the location permission to access such data, which needs to be granted by the user, and in addition the Media Store doesn't hold anymore location data.
The changes made in Android 10 seem to be already addressing all possible issues. And unless a user gives the location permission to any app that eventually picks a camera app, there is no way it could access any location information.
If the issue is about apps which are not targeting Android 10 or 11, then enforce the rule instead of cutting off user's choice.
If the issue is deeper and goes beyond the location permissions, then fix the root cause of the problem, instead of cutting off the possibility of apps becoming a user's main camera choice.
This change can seem anticompetitive as it gives top priority to vendors apps, relegating to a second plane third-party apps, as they cannot be anymore a user's main choice.
en...@gmail.com <en...@gmail.com> #33
They added this so Pixel phones can easily use gcam while everybody else using a port (which they really don't want) has a harder time.
d....@gmail.com <d....@gmail.com> #34
Please help us to choose another camera please.
th...@gmail.com <th...@gmail.com> #35
Pack of absolute bastards.
[Deleted User] <[Deleted User]> #36
This is incredibly stupid and is hurting production work teams at my company.
po...@gmail.com <po...@gmail.com> #37
This is now breaking automations in business applications.
ka...@gmail.com <ka...@gmail.com> #38
Comment has been deleted.
ma...@gmail.com <ma...@gmail.com> #39
ro...@gmail.com <ro...@gmail.com> #40
After 10+ years we just suddenly decide for 'safety' to make this change? How irresponsible is it to do this without putting an option in the developer options to allow the change? now i have to unlock the bootloader and install a 3rd party firmware. real cool guys.
b....@gmail.com <b....@gmail.com> #41
Are you morons? Have you ever thought about companies, which want/need a consistent environment. Smartphone cameras are used for much more than only sharing cat videos.
They are in some cases business critical:
* Measurements
* Wound care
* Remote medical diagnostic
* ...
I'm sure it's really funny to get the wrong size or medication, because the stock camera app use hip and fancy AI algorithm.
They are in some cases business critical:
* Measurements
* Wound care
* Remote medical diagnostic
* ...
I'm sure it's really funny to get the wrong size or medication, because the stock camera app use hip and fancy AI algorithm.
Description
Y
Yes
Pixel 2
Step #1: On your test device, disable the built-in camera app
Step #2: On your test device, install Open Camera or another third-party camera app that has support for
ACTION_IMAGE_CAPTURE
Step #3: Run an app that uses
ACTION_IMAGE_CAPTURE
(e.g., tossstartActivity(Intent(MediaStore.ACTION_IMAGE_CAPTURE))
into some scrap Android Studio project)Framework
For the
startActivity(Intent(MediaStore.ACTION_IMAGE_CAPTURE))
call not to crash, since there is a valid camera app that supports thisIntent
action.Common sense.
Android throws an
ActivityNotFoundException
.In the docs , we are told that only system apps would respond to this
Intent
action. My hope was that this would be the case only when a system app was an available option. In the scenario that I described above, it is not.I can certainly understand the argument for trying to block malware from responding to those
Intent
actions. But for users who have settled on using a third-party camera app, to the point of disabling the system app, your policy is significantly harmful to the user experience.Options include:
As the issue title suggests, apply your system-apps-only policy if there are 1+ system apps available for the
Intent
. Otherwise, allow third-party apps.Same as #1, but with an extra warning dialog ("hey, you're going to be using Open Camera for this — is that OK?").
Same as #2, but with that dialog persisting its result, so future similar
Intent
actions go directly to the user-selected third-party app.As it stands, all you are accomplishing is driving more developers to create their own camera-app chooser, just to be able to get past this limitation.
Thanks for considering this!