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

Android Oreo

android.com

Post reply on HN
Print view View original

591–600 of 658 posts

Re: Android Oreo

#591

Post by mmcnl »

josteink wrote: post #423
klondike_ wrote: post #67

Earlier quoted context omitted.

Carriers generally have deals with other companies for preinstalled apps which may or may not still be active by the time it comes around for an update. Also they have to test the devices, but considering the sheer number of Android devices they probably prioritize new high end devices first. This problem is made worse on Verizon and Sprint which use CDMA 3G networks, as opposed to the worldwide GSM standard. Also th…

> Also they have to test the devices Why? The whole point of GSM is that carrier and phone can (and should) be entirely disconnected, decoupled and only connected through the means of whatever SIM the user puts in his phone. The notion that a carrier needs to be involved in the making of a phone makes about as much sense as if my ISP needed to test and "approve" what Ethernet hardware I use at home. It's frankly none…

It is none of their business, but they desperately want a piece of the pie so they brand their phones (and probably sell them at a small discount - this is the value proposition here). Branding also results in shifting responsibilities from OEM manufacturer to carrier with regard to testing and stuff.

Also, plenty ISPs actually do sell branded wireless routers with branded firmware, so it's not uncommon practice in other neighboring industries.

Re: Android Oreo

#592

Post by artimaeis »

Spivak wrote: post #301
LeifCarrotson wrote: post #187

Earlier quoted context omitted.

> You can change that: don't buy a new phone every six months, and buy from a maker that supports your phone longer. I cannot change that. The ~5,000 I have spent on smartphones and laptops in the past 10 years is hardly enough. My buying choice, yours, and the GP's are just not strong and valuable enough to cause a manufacturer to pander to our desires. The economies of scale and the greater money available from the…

That's not really true on Laptops. Apple, Lenovo, and Dell all make sturdy high-end upgradable repairable laptops. Not the kinds of products you'll see at your local West Fry though.

I'm a huge fan of Apple products in general - and firmly believe their laptops are the best on the market.

But there's incredibly little ground to call any of their current laptop lineup upgradable or repairable. I'm not sure there's a single upgradeable component left on any laptop they currently offer. The Macbook and the Macbook Pro have both moved to soldered CPU, RAM, and flash memory. The Macbook Air I believe still has a replaceable SSD but it has the proprietary connectory. To further complicate things - the batteries in the Macbook and Macbook Pro are both heavily glued in, so even that's difficult to replace.

Re: Android Oreo

#593

Post by kllrnohj »

mjevans wrote: post #274
kevincox wrote: post #132

Earlier quoted context omitted.

You can disable "Battery Optimization" per app, so this isn't very restrictive. It just applies by default.

I'd like to do that, but when I 'exit' an app and/or swipe it off of the list of program cards I want it to ACTUALLY exit (at least within 30 seconds).

> swipe it off of the list of program cards I want it to ACTUALLY exit

Swiping it away instantly kills the app unless it has a foreground service with an associated notification.

Re: Android Oreo

#594

Post by dcow »

avar wrote: post #574
kuschku wrote: post #382

Earlier quoted context omitted.

Yes, and you're okay with having 20 to 30 notifications at all times just to run open source apps, or would you say "this is too annoying, I'll switch back to the closed ones that spy on me". If you want the open source products to win, they need to be able to provide the same usability as the proprietary solution. This is not possible here - you need Google's FCM or you get major disadvantages, and this is problemat…

This doesn't inherently have anything to do with open source, but the problem that whatever license the apps on the phone are under they can't all be implementing their own push/pull message queue, having 30 open network connections constantly waking up the phone is going to drain the battery. If I install 100 apps that have their own messaging implementation should the phone just not be showing that to me, even thou…

There are a few things here. From a technical level, how do you think GCM/FCM is implemented? A socket is hardly a scarce resource and keeping 2 open is only 1/65535 more "expensive" (from a kernel standpoint not power/energy) than multiplexing two streams on one connection. It's possible FCM uses some micro polling strategy so that the radio can sleep for short bursts, but I don't see why the same mechanism can't be exposed to other apps if that was the case.

Second, from a product level there is a double standard now. Apps that build infrastructure using Google's platform services don't have to put a persistent notification in front of users and clutter the phone ui. Apps that choose not to depend on google (the "open source" as it pertains here but you're right it's not limited to open source apps) do. That's a pretty obvious power play.

If you want to see all the stuff going on in the background why are things that buddy up with google exempt from that in your eyes? I could flood your phone with a high priority FCM message every 500ms effectively making my app run all the time and you wouldn't know. There will be apps that do it (as there are with APNS on iOS) and it is in fact far worse for battery life. Maybe we differ on this point but there are certainly things I want happening in the background that don't need a ui. That's the precedent on the desktop anyway.

BTW The ordering of FCM messages is not guaranteed so they're not even as useful as a TCP connection.

Re: Android Oreo

#595

Post by andrewaylett »

flukus wrote: post #330
rdsubhas wrote: post #141

Not saying that everything else is bad, but one thing that strikes me is how much they have run out of interesting things now that they had to use fillers[1] like: Tooltips Support for tooltips (small popup windows with descriptive text) for views and menu items. Normally, this would be relegated to a git changelog in the support library. But this is on the global marketing landing page. I like to imagine a fictional…

How do tooltips even work on a touch based OS?

Just put LineageOS on my Note 3 and it turns out the touch screen is sensitive enough to implement a "Touchscreen hovering" feature.

Re: Android Oreo

#596

Post by dcow »

dcow wrote: post #78
tree_of_item wrote: post #63

Earlier quoted context omitted.

Elsewhere to what? What are you gonna do, run Windows Mobile?

I like native app development because it's not a browser. Android was the most honest manifestation of that on mobile (iOS is basically a "client OS"). I look towards domains where people are still putting powerful applications on connected hardware. Mobile is starting to look like a commodity web experience with half the history of JS, so why not just use that?

Point being the delta between what a native app and what a browser app can do has all but disappeared. BT and Graphics are the last few notable things and both will be supported by browsers soon (webgl already is and webbt is incoming). I'm not saying go use JS.. I very much do not enjoy it. Im asking why we need to build native when there's increasingly less to justify the overhead.

Re: Android Oreo

#597

Post by DCKing »

irq-1 wrote: post #587
DCKing wrote: post #544

Earlier quoted context omitted.

To be honest, I think Google has LG, HTC, Sony, Nokia, Lenovorola, and almost every other Android manufacturer in the pocket here. These companies don't have the capabilities to independently make a competitive OS and app ecosystem and will have to comply with Google wherever it goes. With the exception of LG, all of these companies have even significantly dialed down their efforts to customize Android from AOSP or "…

Couldn't Google use an immutable HAL as a way to make updates themselves? Let users drop manufacturer customizations and get stock android on an older phone.

They might. In an edit above, I remarked that for such a system to exist indeed Project Treble is a necessity. But taking centralized control over the way Android updates will be a very ballsy political move by Google to make.

Some smaller vendors might appreciate that these responsibilities are taken away from them. Sony, HMD/Nokia and Lenovo/Motorola are basically only adding some apps, themes and tweaks to AOSP at this point anyway, but do tend to have relatively good update reputation (or used to). But other vendors will not appreciate giving away this control at all. Some vendors are likely partially motivated to not have devices updated in the first place.

So will Google make such a ballsy move? They themselves barely have good business reasons to do so. Android completely dominates the market anyway, without Google upsetting the politics amongst the vendors and pouring money into doing things that vendors refuse. It seems Android's bad reputation in regards to updates doesn't really hit anyone that hard.

Having said that, Project Treble does seem to be a move in that direction. Maybe Google cares enough about theirs and Android's reputation, or maybe they even care enough about being responsible. Maybe they'll make "Windows Update for Android" an opt-in thing for vendors. Maybe there are other ways they can create a more responsible market (and better repution for Android) without upsetting vendors. Let's hope they find a way at least.

Re: Android Oreo

#598

Post by calferreira »

madeofpalk wrote: post #220
klondike_ wrote: post #11

Project Treble is the most important thing in this release >The biggest change to the foundations of Android to date: a modular architecture that makes it easier and faster for hardware makers to deliver Android updates. With any luck, this will end the huge security/update problem Android has. Right now an update is dependent on the chip manufacturer's drivers, then the OEM adding them to the ROM with their custom "…

I remember many years ago when a few carrier and chipset execs stood up on Google I/O stage and announced a new program to ensure Android devices get updated quicker. Nothing came out of that. The proof here will be when they ship. Thankfully, 'Google Play Services' and distributing more and more services through the Play Store is a step in the right direction.

As an Android developer this is a big pain in the arse if you intend to develop apps using google apis.

The development is easier, but if you plan to distribute on other stores, google play services are useless and will make your development more time consuming as they are exclusive to devices with google play store.

Re: Android Oreo

#599

Post by jdc0589 »

pjmlp wrote: post #463
jdc0589 wrote: post #430

Earlier quoted context omitted.

i haven't read up on fuchsia/magenta too much yet, but my impression is that it's going to be a much larger shift in general. If Google can take some less drastic strides to fix this problem before a huge change like fuchsia, theres probably a better chance for an easy(er) transition.

There cannot exist an easy transition because they are completely different, Java/Kotlin/C++ vs Dart for user space, Linux vs Magenta for the kernel and drivers.

this is why I should stop commenting I stuff I haven't gotten super familiar with. I didn't know Dart was the choice for user space. I suppose they could theoretically include an compatibility layer for java/kotlin userspace apps, but that seems like a lot of baggage depending on what the real goal is.

Re: Android Oreo

#600

Post by moosingin3space »

Vinnl wrote: post #461
dcomp wrote: post #108

The most interesting part is the way they are planning on tackling fragmentation in O onwards with Project Treble [0] If your device ships with O it should be running an immutable semantically versioned HAL. In essence you should be able to be able to flash AOSP on every new device. No matter what the vendor does. Edit: I can see it now, in the technical specs of each device you will see a list of HAL Versions. The n…

As someone who knows nothing about this, I wonder (and hope) if this is helpful for UBPorts/Halium. https://ubports.com/ https://halium.org/

Intuitively, it seems that it would be since it provides a HAL that these projects can target.
Post reply on HN