Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android P

blog.google

Post reply on HN
Print view View original

71–80 of 316 posts

Re: Android P

#71

Post by jbredeche »

Zarel wrote: post #45
51Cards wrote: post #7

Earlier quoted context omitted.

I was the same. The moment I saw the three icons gone I rolled my eyes. I thought it was pretty user friendly as is. That said once demoed I am interested to try it. I would like to have an option to toggle back though if desired because... When I see UI changes like this my initial concern is not for myself but for my 75 year old mother. It has taken her years to be able to move through Android with some efficiency…

I installed the beta the moment I heard the keynote say I could immediately. The new swipe-up-from-Home UI is off by default. I had to turn it on in Gestures. By default, it's the old three-button UI: Back, Home, App switcher.

Thank you, I was wondering why I didn't see the new nav!

Re: Android P

#72

Post by tomp »

rtpg wrote: post #58
tomp wrote: post #34

Earlier quoted context omitted.

I wonder how many of these features could be implemented (far sooner) if a universal UI scripting language was available for users...

You know, I'm pretty sure anyone could have built these apps on Android You can overwrite the screen in Android. You can replace the home screen in Android. You can scrape running apps in Android. There's a high degree of flexibility Unfortunately this is probably one of those problems where the cost of building the app is relatively high (because the domain is complicated to get right!) and it would be hard to make…

Building an app is way too much barrier to entry... What I wish is something like, right-click or swipe down to open console, enter some script (or copy-paste/import a highly starred from a public repository), close console, ta-da. If the API was flexible enough, the scripts would mostly be short and obviously non-exploiting (i.e. a script for graying-out the screen shouldn't use the internet API) so they would be very easy to review, modify, and manage otherwise.

Re: Android P

#73

Post by tomp »

fooker wrote: post #60
tomp wrote: post #34

Earlier quoted context omitted.

I wonder how many of these features could be implemented (far sooner) if a universal UI scripting language was available for users...

How would such a language define which UI elements to operate on?

Some sort of sensible API I guess... Or something automatically generated, like Excel macros, that you can then inspect, understand and modify... If it came with "infinite" undo and some sort of playground/sandbox, people could literally experiment with very low cost.

Re: Android P

#74

Post by gruez »

kuschku wrote: post #42
JoshTriplett wrote: post #5

While I appreciate the concept of learning things like "common next steps" to make a device more usable, going by the history of devices like Google Home or the Google Assistant, I also wonder how much of this is going to depend on "give us all your usage history" settings and simply stop working with those settings disabled. The Google Assistant is already unusable without a pile of search history settings enabled;…

Google already has all your usage history. You can view it yourself by dialing # #INFO# # aka # #4636# # and then selecting "Usage data". You’ll see all apps you’ve used, for how long you’ve used them overall, how many times, and when the last time was. EDIT: *#*#4636#*#* This goddamn markup on HN is utterly broken, I wish it would someday get fixed. But no, of course not.

You can disable google play's access to it by turning off "usage access" in app permissions.

Re: Android P

#75

Post by gruez »

angry_octet wrote: post #51

Lots of slick UI stuff, but no meaningful updates to things that are well overdue: - Encryption of specific secrets for each app. - Fine grained control of what information is shared with apps. - Ability to selectively deny particular data (and have the app keep working, e.g by giving it an empty contacts list, fake phone ID, etc). - Ad and js blocking capable browser. Why should installing e.g. the facebook app, all…

>Encryption of specific secrets for each app.

you mean something like ios keychain? what does this do that can't be achieved using disk encryption + sandbox?

>Ad and js blocking capable browser.

firefox for android

Re: Android P

#76

Post by rtpg »

tomp wrote: post #72
rtpg wrote: post #58

Earlier quoted context omitted.

You know, I'm pretty sure anyone could have built these apps on Android You can overwrite the screen in Android. You can replace the home screen in Android. You can scrape running apps in Android. There's a high degree of flexibility Unfortunately this is probably one of those problems where the cost of building the app is relatively high (because the domain is complicated to get right!) and it would be hard to make…

Building an app is way too much barrier to entry... What I wish is something like, right-click or swipe down to open console , enter some script (or copy-paste/import a highly starred from a public repository), close console, ta-da. If the API was flexible enough, the scripts would mostly be short and obviously non-exploiting (i.e. a script for graying-out the screen shouldn't use the internet API) so they would be v…

Hmm for this specific case I think that there might be a lot of of edge cases, just a gut feeling

But I would totally be for some much simpler packaging scheme for native apps/"scripts". It's kinda insane how much money is going into Android from Google but all the dev tools are basically just Java stuff. I really wonder what Android could be if a more lisp-y approach existed as well

Re: Android P

#77

Post by kuschku »

izacus wrote: post #47
kuschku wrote: post #43

Earlier quoted context omitted.

But they should have. Ending support just one version before basically immortality for the phones is just a bad joke. Especially when the only available alternative starts at 3 times the price. $900 for the smallest Pixel in Germany, fuck that.

Treble requires SoC vendors to provide drivers with explicit support. SoCs from Nexus devices aren't supported by Qualcomm so they simply can't be upgraded.

And yet Google managed to get Treble support on the Pixel devices over a year after release...

With enough money, it was apparently possible.

Re: Android P

#78

Post by derptron »

tomp wrote: post #72
rtpg wrote: post #58

Earlier quoted context omitted.

You know, I'm pretty sure anyone could have built these apps on Android You can overwrite the screen in Android. You can replace the home screen in Android. You can scrape running apps in Android. There's a high degree of flexibility Unfortunately this is probably one of those problems where the cost of building the app is relatively high (because the domain is complicated to get right!) and it would be hard to make…

Building an app is way too much barrier to entry... What I wish is something like, right-click or swipe down to open console , enter some script (or copy-paste/import a highly starred from a public repository), close console, ta-da. If the API was flexible enough, the scripts would mostly be short and obviously non-exploiting (i.e. a script for graying-out the screen shouldn't use the internet API) so they would be v…

You seriously think a mass consumed electronic device is going to have that feature?

The developer options in android are a hidden feature for pity's sake.

Re: Android P

#79

Post by ISL »

Ten years ago, when we launched the first Android phone—the T-Mobile G1—it was with a simple but bold idea: to build a mobile platform that’s free and open to everyone.

To what quantitative fraction is Android still free and open (as in speech), and how much of it has been moved into closed-source containers?

Post reply on HN