Live data from Hacker News

Taking the final wrapper off of Android 7.0 Nougat

android-developers.blogspot.com

141–150 of 250 posts

Re: Taking the final wrapper off of Android 7.0 Nougat

#141

Earlier quoted context omitted.

I have an Android ADP1 --- one of the original development phones, the HTC Dream with the custom paint job. It's got 192MB of RAM and a single-core 528MB ARM11. It ran Cupcake, aka Android 1.5 (although I've since upgraded it to, If you ignore the hilarious security bugs --- like the fact that, as shipped, they forgot to disconnect the keyboard from a root shell, so that if you typed 'reboot' into an email hilarious…

I also had ADP1 - and I think that the latest official update was to Donut, aka Android 1.6. Not that it matters much today...

Yeah, I've got Donut on it now.

Unfortunately its https library uses some obsolete crypto technique --- TLS 2? --- and as a result it can't connect to anything on the internet, not even to fetch updates from the App Market (not the Play Store!). I can't even log in to Google.

I did have Gingerbread on it at one point but it was very unhappy.

I found a partial Debian port but there's still not really enough RAM for that. I wonder if there's a NetBSD port...

Re: Taking the final wrapper off of Android 7.0 Nougat

#142
post #51
post #35

No Android 7 on my Nexus 5 might just be what pushes me to iOS. I've gone from being an Android evangelist to being an Android apologist ("Yeah, battery life sucks. Google has failed to fix it after X years") to now being, frankly, pissed off that my expensive phone is going to be left behind.

The alternative is the iOS update process, which has the result of non-techies complaining that their iPhone 4 is now slow after the update, and the techies they know pleading with them not to update even though the number gets bigger.

Another alternative would be to keep releasing security updates. If open source projects can manage more than three years support, it's not out of the question for Google to do it, at least for the major versions.

Re: Taking the final wrapper off of Android 7.0 Nougat

#143
post #62

Earlier quoted context omitted.

The iPhone SE is similarly priced and iOS devices receive updates for more than 3 years. iPhone 5 for instance got and runs fine iOS 9, 4 years after release.

iOS 9 runs hilariously badly on the iPhone 5.

It runs just fine on my iPhone 5 and it's my daily device.

Re: Taking the final wrapper off of Android 7.0 Nougat

#144

Earlier quoted context omitted.

I also had ADP1 - and I think that the latest official update was to Donut, aka Android 1.6. Not that it matters much today...

Yeah, I've got Donut on it now. Unfortunately its https library uses some obsolete crypto technique --- TLS 2? --- and as a result it can't connect to anything on the internet, not even to fetch updates from the App Market (not the Play Store!). I can't even log in to Google. I did have Gingerbread on it at one point but it was very unhappy. I found a partial Debian port but there's still not really enough RAM for th…

Yeah, I also tried Cyanogenmod Eclair and Froyo on it, but it was an excelent way to waste a lot of time watching things happen in slow motion. So I flashed it back to Donut and few weeks later got another phone, that ran Froyo properly.

I didn't know that the App Market doesn't work anymore - about 18 months back, my brother was still using it (as a backup phone, obviously).

Re: Taking the final wrapper off of Android 7.0 Nougat

#145

Some of those screenshots make my eyes bleed, particularly the one with the multiple-windows with one of the windows having the painful app selector that pretends to be a window selector. When will we see Android 7 on a third party device?

We just analyzed Android manufacturers [1] and found they tend to update in two groups: 3 months after release (Motorola, LG, HTC) and 6 months after release (Samsung, Sony, Huawei). This of course ignores Nexus devices by those manufacturers.

[1] https://www.apteligent.com/2016/08/apteligent-data-report-an...

Re: Taking the final wrapper off of Android 7.0 Nougat

#146
post #44

Meanwhile many phones (especially vendor-locked ones like the Droid Turbo...) are still stuck on Lollipop.

According† to https://developer.android.com/about/dashboards/index.html The recent Marshmallow has 15.2% market share Lollipop (14.1% + 21.4%) = 35.5% (the greatest share) KitKat has 29.2% (the next greatest share) Jelly Bean† still has (6.0% + 8.3% + 2.4%) = 16.7% Earlier than Jelly Bean is 3.4% of the total share. Jelly Bean was first unveiled in June 2012, four years ago. I think given the development model: large…

We decided to build our own dashboard since Google's is updated only about once a month. It also doesn't include data from non Google Play devices:

https://data.apteligent.com/android/

Re: Taking the final wrapper off of Android 7.0 Nougat

#147
post #70
post #57

Earlier quoted context omitted.

There is one awesome new feature that is not mentioned on most "best new features" list: built-in night mode (blue light filter). Works much better than similar apps from the store - those work by placing a translucent overlay window on top of everything else, which gives everything (including black!) a reddish hue. The new built-in filter, on the other hand, just removes blue, and blacks remain black.

I didn't know about this and now I am really interested in the update. I've been using one of the overlay ones for a while and it is kind of annoying.

I just upgraded to Android 7.0. Night Mode is still there! You can access it by enabling the system UI tuner.

Just swipe down from the top of the screen to reveal the quick settings, and then press and hold the Settings icon (gear) for a few seconds and release. This will enable the UI tuner.

Swipe down from the top again, then tap "EDIT" in the bottom right corner. There should be a tile for "Night mode", which you can drag and drop into the quick settings panel for easy toggling.

Re: Taking the final wrapper off of Android 7.0 Nougat

#148

Earlier quoted context omitted.

That was true with Marshmallow. With Nougat, no background tasks will be run at all while the screen is off – except for Google services, or if they keep the CPU on 100% of the time with a wake lock. JobScheduler also doesn’t allow continuous tasks, but only short tasks – so you can’t actually keep a low-cost socket open.

> With Nougat, no background tasks will be run at all while the screen is off – except for Google services. Untrue. First, mobile Doze doesn't kick in immediately when the screen is off. Second, mobile Doze apparently doesn't stop all background tasks except "Google services" from running, since "wake locks" from apps for background tasks are still supported.

Is that true? Will my email client stop notifying me of new email?

That doesn't sound appealing at all.

Re: Taking the final wrapper off of Android 7.0 Nougat

#149

Earlier quoted context omitted.

> With Nougat, no background tasks will be run at all while the screen is off – except for Google services. Untrue. First, mobile Doze doesn't kick in immediately when the screen is off. Second, mobile Doze apparently doesn't stop all background tasks except "Google services" from running, since "wake locks" from apps for background tasks are still supported.

Is that true? Will my email client stop notifying me of new email? That doesn't sound appealing at all.

> Is that true? Will my email client stop notifying me of new email?

There are mechanisms to get high-priority notifications, and methods to do background work that are batched on increasingly long intervals to save battery life (both the batching and the increasing intervals serve that purpose), so that shouldn't be an issue. Notifications that need to be immediate have a path, and ones that don't should still happen, just not immediately.

Re: Taking the final wrapper off of Android 7.0 Nougat

#150
post #55

Earlier quoted context omitted.

This is basically what iOS has done from the start. If you don't see the app in front of you, iOS will very quickly kill it if it has any background tasks. It's a leaky abstraction, but honestly I like the implicit promise/guarantee between the scheduler and the user. I only get annoyed when I want some batch task like uploading photos, but even then it's not too hard to leave the phone powered on and unlocked on my…

Except when you try to ensure someone gets notifications while the phone is in an intranet. Or when you try to transmit notifications without going through Google/Apple servers, because those require you to control the messaging server (due to API auth limitations), which does not work with distributed systems. A messaging app that only works when the screen is on is useless.

Why not use Apple's servers to deliver a ping, and then the app checks with your own server what the content of the message should be?

That way, you get realtime event notifications without the privacy risk of exposing content to Apple's servers.

Post reply on HN