Live data from Hacker News

Google confirms 'high-friction' sideloading flow is coming to Android

androidauthority.com

731–740 of 762 posts

Re: Google confirms 'high-friction' sideloading flow is coming to Android

#731

Earlier quoted context omitted.

I think it’s fair to say that a SoC should perform better at higher wattages, so my comment is definitely relevant. Regardless, I don’t understand how you can say that I’m moving goalposts when I mention performance per watt, which is absolutely relevant when talking about smartphone SoC performance, and then you bring up battery capacity, which is not.

Your initial question was "How are they on par SoC-wise?" They are on par because they now sometimes beat Apple top of the line A-chips on performance be it single core, multicores or GPU and do so within a power budget which allows the phone they ship in to be competitive screen-on time wise. Apple doesn't have a one generation lead anymore which is a huge change compared to only three years ago. You are moving the…

The whole claim that Qualcomm is on par with Apple predicates upon results from benchmarking tools, which stress CPU and GPU and thus induce peak power consumption.

If we were to look at more thorough reviews, e.g. Geekerwan, they always include TDP and power consumption, because that gives the necessary context to understand the results.

And obviously I’m not denying that Mediatek and Qualcomm have massively improved their designs, but they aren’t on par when we account all the things that matter.

Your argument is that, since manufacturers are putting larger batteries in phones, SoC power consumption shouldn’t matter. That is moving the goalpost, because you introduce a variable that should be irrelevant to SoC performance testing to dismiss my observation.

Re: Google confirms 'high-friction' sideloading flow is coming to Android

#732

Earlier quoted context omitted.

That’s demonstrably untrue. You could say that there are Apple devices that do not work well or don’t work at all without another Apple device, and off the top of my head I would say the only ones are the Watch and the HomePod, but most alternative devices work fine with Apple ones, e.g Chromecast, Garmin watches, Google Home hubs, etc. And even so, the same could be said about Android only features and devices, e.g.…

Demonstrably not true? What did you do with the 200+ Apple-only charging cables?

What are you even talking about? The only Apple exclusive connector in recent memory was Lightning, and it’s been phased out.

Did you get rid of all your micro USB cables and devices once the transition to USB-C began for Android?

Re: Google confirms 'high-friction' sideloading flow is coming to Android

#733
post #376

Earlier quoted context omitted.

Well, formerly you would have been right, but WebUSB and whatnot are gaining a lot more traction. I didn't take WebUSB seriously until I steered someone to flashing a small firmware onto something and they could do it straight from the browser! And it was a nice workflow too, just a few button and a permission click. Two other examples I can think of are flashing Via (keyboard) firmware and Poweramp using WebADB via…

WebUSB is a giant gaping hole in the browser sandbox. Innocent use cases are really nice, I've used WebUSB to flash GrapheneOS on my device, but the possibilities for users to shoot themselves in the foot with nefarious website are almost endless. Consider the fact that Chromium has to specifically blacklist Yubikey and other known WebAuthn vendor IDs, otherwise any website could talk to your Yubikey pretending to be…

It really isn't. Chromium (since 67) does USB interface class filtering to prevent access to sensitive devices. Then there is the blacklist you mentioned.

On top of that, straight from Yubico's site:

".. The user must approve access on a per website, per device basis .."

This isn't any more a security hole than people clicking "yes" on UAC prompts that try to install malware.

Re: Google confirms 'high-friction' sideloading flow is coming to Android

#734
post #628
post #625

Earlier quoted context omitted.

I make the superior picture with my camera but then it sits there on an SD card in the camera. I have to boot a desktop, hope the USB connection works today, find a folder, create and name a folder in the folder, copy the pictures there, find and open something to view and edit the images with, find and open something to upload the images. OR open the camera, take out th SD card, boot up a computer, plug the card int…

> but then it sits there on an SD card in the camera. I have to boot a desktop, hope the USB connection works today [...] OR open the camera, take out th SD card [...] Or open the app on your smartphone ( https://play.google.com/store/apps/details?id=jp.co.canon.ic... ), connect to the camera through WiFi, and copy the photos directly.

We are apparently very spoiled with how smooth some things work on smart phones.

I want dedicated cameras to offer a superior experience. In stead it is quite bad.

In order to publish one should first disconnect the internet?

I have to put down the camera and pick up the competing device?

My absolute favorite annoyance with my cameras is the lack of charging over USB. After taking a good amount of pictures I have to guess if there is enough battery left to transfer the images to the computer.

Not that PCs or laptops offer very good charging power. This because there is little demand.

It seems in order to make the superior experience the camera maker should also make phones and/or laptops? I have no idea really.

All I know is that my phone has 100W charging. I can almost immediately return to the front. The camera does have swappable batteries going for it but that I have to remove it from the tripod to reload it won't win the war.

Re: Google confirms 'high-friction' sideloading flow is coming to Android

#735
post #733

Earlier quoted context omitted.

WebUSB is a giant gaping hole in the browser sandbox. Innocent use cases are really nice, I've used WebUSB to flash GrapheneOS on my device, but the possibilities for users to shoot themselves in the foot with nefarious website are almost endless. Consider the fact that Chromium has to specifically blacklist Yubikey and other known WebAuthn vendor IDs, otherwise any website could talk to your Yubikey pretending to be…

It really isn't. Chromium (since 67) does USB interface class filtering to prevent access to sensitive devices. Then there is the blacklist you mentioned. On top of that, straight from Yubico's site: ".. The user must approve access on a per website, per device basis .." This isn't any more a security hole than people clicking "yes" on UAC prompts that try to install malware.

> ".. The user must approve access on a per website, per device basis .."

Of course, but a phishing website "fake-bank.com" could collect user's username, password, and then prompt them to touch their yubikey. This wouldn't trigger any alarm bells because it's part of the expected flow.

> This isn't any more a security hole than people clicking "yes" on UAC prompts that try to install malware.

Yes it is. The only reason why Yubikeys are immune to phishing and TOTP codes aren't is because a trusted component (the browser) accurately informs the security key about the website origin. When a phishing website at "fake-bank.com" is allowed to directly communicate with the security key there's nothing stopping it from requesting credentials for "bank.com"

Re: Google confirms 'high-friction' sideloading flow is coming to Android

#736
post #718

Earlier quoted context omitted.

It was there for the launch of the App Store with iOS. They didn’t have to worry about backward compatibility, because they took the time to worry about user privacy and app developer overreach from the very start.

A difference is also that Apple has 100% control over the hardware and can enforce their updates much better than Android. Android has to deal with tons of devices, and allow developers to update their tooling while supporting older devices. I actually find it quite impressive how they manage to do that. Must be difficult.

All the more reason to get the design right out of the gate, instead of throwing something out there and hoping to fix it later. Especially something so fundamental, like privacy.

Re: Google confirms 'high-friction' sideloading flow is coming to Android

#737

Earlier quoted context omitted.

> In which category are there better iOS apps? Almost all of the prosumer apps on iOS offer a consistently better experience. This is maybe less relevant on phones than on tablets, but music production, video editing, digital painting and drafting, etc...

Seems super biased comming by someone called SWIFTcoder.

Hah. Username pre-dates the programming language by more than a decade

Re: Google confirms 'high-friction' sideloading flow is coming to Android

#738

Earlier quoted context omitted.

It's true, but the main reason I haven't just switched to an iPhone is the ecosystem that lets me write apps without having to pay Apple money or use their computers. If Google is narrowing their moat on this, there are a lot fewer reasons for me, personally, to stay on the platform.

Sure, but the alternative ain't better for it, no?

I'm not quite sure I catch your meaning; "it" is an unbound pronoun in that sentence.

If I assume "it" means "programming on a mobile device": yes, it is. Apple cares an awful lot about the developer experience, has massive support, and a deep well of shareable knowledge. Google is about the same (the developer experience is a little patchier; I'd generously call Google's approach to devex on Android "bag-of-cats vision" and since one is not developing on, generally, a vertically-integrated tech stack, one has to struggle a bit more to get the tools set up and maintained).

The big selling point for Android is freedom of that stack, and if they throw sand in those gears, the benefits of the vertically-integrated stack that you have to pay-to-play start to become actually enticing.

Re: Google confirms 'high-friction' sideloading flow is coming to Android

#739
post #56

Google's long term strategy with Android is baffling to me. Apple has had better mobile hardware for years. Apple has higher consumer trust. Apple has better app selection (for most people). Apple has been increasingly implementing the core features that differentiate Android devices, like USB-C and RCS. Every Android user lost to the increasing iOS market share is another customer Google has to pay exorbitant fees t…

I don't see any iOS advantage with the apps anymore. That was maybe true in the very beginning, during the gold rush time of the app store. But not since then. In which category are there better iOS apps? Browsers? No, strictly worse. Youtube app? No, worse. Texting? Worse or equal (Whatsapp). Podcast client? I assume worse, since there is no Antenna Pod. Social media apps? The iOS variants of those apps are afaik in…

iOS has the advantage of having a more closed app store, google play will shove whatever ad infested slop in your face and show you thousands of generic ad infested solutions to your problem, whereas iOS will usually have an easier to find not as sucky solution

Re: Google confirms 'high-friction' sideloading flow is coming to Android

#740
post #726

Earlier quoted context omitted.

There's a saying in mobile development that in most companies the Android version of the app is a second class citizen. It usually brings substantially less money and so less money are invested in it. As a result the Android team is often understaffed and the app is almost always behind in feature development, less polished and with overall worse UX and more bugs compared to the iOS app. Also iOS still has a communit…

Since Android has 70% of the world market share, and there are countries where iOS is hardly a presence other than the country's elite population, those are quite a few customers they will be missing on. Maybe they can keep the lights on with those 30%, I guess.

The thing is, iOS users are far more likely to actually pay for something on the app store or pay to remove ads
Post reply on HN