• Breaking News

    [Android][timeline][#f39c12]

    Thursday, February 6, 2020

    Home Unlabelled Android Help What should I buy Thursday (Feb 06 2020) - Your weekly device inquiry thread!

    Android Help What should I buy Thursday (Feb 06 2020) - Your weekly device inquiry thread!

    February 06, 2020

    Android Help What should I buy Thursday (Feb 06 2020) - Your weekly device inquiry thread!

    What should I buy Thursday (Feb 06 2020) - Your weekly device inquiry thread!

    Posted: 06 Feb 2020 03:11 AM PST

    Credits to the team at /r/PickAnAndroidForMe for compiling this information:

    Note 1. Join us at /r/MoronicMondayAndroid, a sub serving as a repository for our retired weekly threads. Just pick any thread and Ctrl-F your way to wisdom!

    Note 2. Join our IRC, and Telegram chat-rooms! Please see our wiki for instructions.

    submitted by /u/AutoModerator
    [link] [comments]

    Motorola Razr fails to reach 100,000 folds in our test

    Posted: 06 Feb 2020 08:19 PM PST

    Google Maps is turning 15! Celebrate with a new look and features

    Posted: 06 Feb 2020 03:04 AM PST

    "Sunfish" is the Google Pixel 4a with the Qualcomm Snapdragon 730

    Posted: 06 Feb 2020 11:50 AM PST

    Surface Duo spotted in the wild with possible front-facing flash

    Posted: 06 Feb 2020 08:10 PM PST

    Sources: Internal YouTube Music gains music library upload as Play Music transition nears

    Posted: 06 Feb 2020 12:07 PM PST

    Android on Twitter: "Something exciting is just around the corner. See you at Unpacked, @SamsungMobile: https://t.co/FU3iJCnf77… "

    Posted: 06 Feb 2020 10:22 AM PST

    Malicious Optimizer and Utility Android Apps on Google Play Communicate with Trojans that Install Malware, Perform Mobile Ad Fraud

    Posted: 06 Feb 2020 02:42 PM PST

    Google removes Androidify avatar maker from Play Store, still available online

    Posted: 06 Feb 2020 03:30 PM PST

    China's mobile giants(Xiaomi, Huawei Technologies, Oppo and Vivo) to take on Google's Play store

    Posted: 06 Feb 2020 04:20 AM PST

    How many Android devices get OS updates: 2020 edition (including mini Q+A from Greg Kroah-Hartman, stable kernel maintainer)

    Posted: 06 Feb 2020 03:55 AM PST

    Hi r/android.

    In 2019, I made a thread that explored the relationship between Android devices and OS updates. Namely how many devices go from one Android version to another.

    I'm back again to explore whether there have been any changes in this regard. I also have a mini Q+A to some questions I asked Greg Kroah-Hartman.

    Let's dig in.

    2016: Nougat (Android 7.0/7.1)
    2017: Oreo (Android 8.0/8.1)
    2018: Pie (Android 9)
    2019: Android 10

    All data is provided by GSMArena

    Phones released (Android only):

    2017: 458
    2018: 418
    2019: 417

    Methodology:

     

    These tables contain two values based on the way GSMArena's data is reported.

    Total devices: This is calculated by selecting the year the device was launched (such as 2017) and the OS version and taking the total value reported by GSMArena. This may include devices that were upgraded from prior versions of Android

     

    Unique devices: This is based on a calculation, taking the following example:

    In 2017, GSM reports 443 were running Android 6.0 (Marshmallow).

    In 2017, GSM reports 327 were running Android 7.0/7.1 (Nougat).

    If we take 413-327 we get 86 "unique" devices.

     

    This is not a perfect formula, but based on /u/false_precision's comment here from last year it's best to provide two sets of statistics.

     

    Devices launched in 2017

    OS Total Unique
    7.0/7.1 327 87 (443-327)
    8.0/8.1 91 4 (91-87)
    9.0 47 0
    10.0 3 0

     

    Devices launched in 2018

    OS Total Unique
    7.0/7.1 413
    8.0/8.1 339 74 (413-339)
    9.0 105 31 (105-74)
    10.0 20 0

     

    Devices launched in 2019

    OS Total Unique
    7.0/7.1 418 N/A
    8.0/8.1 416 N/A
    9.0 365 61 (416-365)
    10.0 79 18 (79-61)

     

    Analysis

    It appears that even today, there is a consistent trend that the number of devices that get an OS update decreases with each new Android release. It is to be expected, for example, that of the 79 devices that got Android 10.0 that were launched in 2019, even fewer will get Android 11.0.

     

    Android's quest for improvement

    The Android team have undertaken a variety of initiatives recently to try and improve this situation, these include:

    Project Treble (launched in 2018 with Android 8.0)

    Core Kernel requirements (As of Android 9.0 devices must use specific versions of the LTS kernels)

    Apex packages (launched with Android 10.0)

    Stable AIDL (launched with Android 10.0)

     

    More changes are being worked on with each new Android release with the hope that system updates become easier and (hopefully for us), more frequent.

     

    A Q&A with Greg Kroah-Hartman

    Being the stable Kernel maintainer, I decided to ask Greg some questions about his observations on this topic. Here are the questions and answers, presented in their original format.

    Note: Permission was granted by Greg to reproduce his responses here.

    Me:

    It was announced a while back that the stable kernels (at least some versions) would get "ELTS" - 6 years vs 2 you used to provide. Is that helping the ecosystem, in terms of devices actually getting kernel updates, and is that also helping these devices get newer Android versions?

    Greg:

    Yes it is. It's a requirement for each new Android release to bump the kernel version as well to take the new "ELTS" releases as well.

    Me:

    Security patches may be elusive - how many devices actually take the patches you post in each kernel release and apply them to their own kernels? A device may have a security patch level but might not have applied all the changes you post (instead, they may be selective).

    Greg:

    There are lots of devices and companies already doing this. I publically call out both Sony and Essential for doing this for a few years now, their devices update to the latest LTS ".y" release every month or so, getting all of the new fixes. So does the Pixel devices, they have been doing that for the past year with great results. Some companies have not been taking them, and I am working with Google to fix that, hopefully will have something public to say about that "soon".

    Me:

    Google's undertaken a number of initiatives: A GSI, Treble, HIDL's/HALS, VTS, APEX packages and so on. How is this helping from your perspective (I'm not sure how deep your understanding of the Android ecosystem goes).
    For example, with the new EAS merged into kernel 5.0, how many devices will actually take advantage of that?

    Greg:

    That "feature" was already in the android-common kernels for 4.4, 4.9, and newer releases so devices have had this feature for years now. Now taht it is the mainline kernel, they get it "for free" without having to do any big backports or working around how upstream changes things at times. So this is a success story, the feature is merged, all new devices get it, and everyone is happy :)

    Me:

    Is Qualcomm and other vendors to blame for the lack of updates? I can understand if the silicon provider only supports 1 kernel, (say 4.4), it can be hard to forward port changes to say 4.9 or 5.4, as the kernel churns through millions of lines of code across vast time spans the older kernels may become harder to manipulate in a fundamental way (such as providing EAS to the 4.4.y branch).

    Greg:

    Doing updates of the weekly releases is "trivial" to do so. I work with a bunch of SoC companies and they give me monthly reports saying how the merges have gone, and if there was any problems. Usually they say "we ran into this issue, but you fixed it the next week already so it wasn't an issue".

    So there should not be any excuse to not be giving those weekly releases to devices and users. Again, many companies have been doing this for a while, hopefully more will in the future. But, for moving to a new major kernel release, that's a much "harder" thing to do.

    These SoC kernels have millions of lines added to them, so moving forward can be difficult depending on what they have modified. For some SoC vendors, it's not tough at all, I did it for one major chip in a week.

    And this is the same thing that SoC vendors do for new chip versions, they drag all of their old stuff forward for the new chip and go from there. As for why they don't do that, well, talk to them. It's hard to get a straight answer, but usually it comes down to "resources to do it and support it". But, if they worked upstream first, they would get this for free, but that's a different story that I constantly tell them...

    Me:

    Is this a planned obsolescence and monetary-driven decision or a technical one? You have very generously decided to donate time to supporting older kernels (I know Ben Hutchings still supports 3.18 and offers 6 years support and is doing the CIP for 'super LTS'). However, regardless of this, it may be the simple case that supporting devices for longer is just not a viable profit motivated business decision. It's easier to offer 2 years and move onto the new shiny device.

    This leads to a magnitude of potential e-waste, as recently Sonos apologized for declaring older devices will stop getting updates.

    Greg:

    I don't see any planned obsolescence at all here. Supporting these kernels for a long time is good as there are devices using them and we want people to keep them alive.

    Although I will argue that this model is not the best one, and some companies agree. One "big" company told me something along the lines of "we are going to support this device for the next 20 years, and will be keeping it alive with new updates and new releases of software for at least the first 18 years.

    To somehow think that we ship it once and try to support old code for 20 years is laughable." So that's the best way to do this, but it takes a different mindset to do so.

    Me:

    Is there anything you, or we, can do in reality? I was hoping after all the recent changes in Androids architecture ROMs would be 'easier than ever', and with the GSI/Treble adoption in the ecosystem devices could get secure, third party updates (at least via ROMs) for much longer. However locked bootloaders (and companies like Huawei who refuse them or Xiaomi whose process is complex) prevent this from flourishing.

    Greg:

    Locked bootloaders have nothing to do with anything else, talk to the companies about that. Treble/GSI has helped out immensely, and see the "update to a new build on the fly for one boot" feature that was recently announced as proof of that (sorry can't remember the real name [OP edit: I believe this is the A/B updates or DSU]).

    But that has nothing to do with the kernel at the moment, however I do have long-term plans on how to do this all better with the kernel for Android vendors and am working directly with Google and the SoC companies about it. Hopefully that will be announced for the next release of Android, but can't say for sure...

    Me:

    What I am not seeing from 'the ground' is any actual changes to the 'status quo', Android has, and still has, an update/longevity problem. I feel (from my perspective) Google tries to influence changes (yay! Greg KH/Sasha Levin does 6 year LTS, problem solved!) but that's not really the case. Google has implemented many initiatives to try and encourage longevity, however as far as I know the Pixels are the only devices that get the longest support, and that's still terrible.

    Greg:

    it is a big problem solved in that you now have a kernel that can be kept up to date and secure through the support lifetime of the product, which never happened before. So that's a huge change that people seem to ignore. Pixel 1 survived with a fully-supported LTS kernel release for its entire lifetime. That's a first. It was a good phone, I still use one for testing.

    Me:

    I'd love if you were able to comment publicly on who is pretty good and whose pretty terrible in terms of device/kernel support - I remember you saying you're not providing updates just so nobody adopts them, but there is a lack of transparency as to what kernels each device runs, what patches they take (because the kernel version number doesn't tell the whole picture).

    Greg:

    Again, Sony and Essencial are two good examples, as are the Pixel devices. I haven't studied too many other companies in the past year to say that those are the only ones, but I am pretty sure they are not.

    Me:

    This is an area of active interest to me, I'd love to get more information (such as a kernel version per device compilation list).

    Greg:

    That would be a great list to have, and I have not seen it nor do I know how to go about making it :(

    Me:

    Hopefully one day we'll see OS updates from Google themselves, rather than relying on third parties that have no business interest in providing updates. From a security standpoint, my device has a lot of information, not getting security updates makes me wince, every device is capable of monthly 5 year long updates from a hardware standpoint, but it seems money rules over technicalities.

    Greg:

    That's what a lot of the Treble/GSI work is for, to allow Google to do OS updates without worrying about the lower level stuff. And that has helped out a lot with more devices being updated to the newer Android release faster than ever. It's still a work in progress, but things are much better than they were even 3 years ago, not to mention 5 years ago :(

    Me:

    This raises a question of what the kernel version string in Android actually means. As far as I know, just because they report 4.4.y doesn't really tell the user too much.

    Greg:

    It says more than that, look at a kernel version, it should show the .y number as well, which means a lot. But outside of that, yes, there are millions of lines of code changed on top of a kernel.org release for these devices. A "typical" Qualcomm SoC adds about 3.5 million lines, and that device is only running about 4 million lines, so you are really running a "Linux-like" device.

    Me:

    I do wonder if it's possible to look at the public kernel source tree (which is required under GPL AFAIK) and create some sort of 'hash' based off of that to try and figure the exact kernel (+ patches) being used. Maybe this can then be collected on a per device basis and reported publicly.

    Greg:

    Patches are all different, but yes, you can do this. I dig in vendor kernels all the time and find "interesting" things they have, and more importantly for security, have not done. There's a number of company's devices I just will not use because of that :)

    Me:

    I would love to see a 'ecosystem health' report, now that Google stopped providing the developer dashboard reports. This includes OS version, security patch level, kernel version, kernel updates frequency etc. I am sure all this information can be collected automatically (and would be surprised if it wasn't!).

    Maybe making an application people can install could be a good idea? I've wanted to gain more insights into this for a number of years now (especially regarding kernel versions which might be useful for you to know).

    Greg:

    Doesn't the benchmark apps collect kernel versions and the like already?

    Me:

    However, I do need to do more research into this (I'm still learning how Android works from this perspective) to understand how the trees are modified by each party (SOC, OEM etc) before it reaches the end user.

    One day I would love to be able to boot 5.x straight from Linus' tree and have everything 'just work', but I suppose we're still a ways off from that =). I have no more questions for now, thanks for being so responsive.

    I suspected Treble (et al) was going to be a 'long road' type of situation as OEMs adapt to the changes (some of which only applied for devices launching with a particular version of Android, as defined by the CDD).

    Greg:

    It has "just worked" for Android for a number of years now, it is all in the SoC support that things get messy. Mainline boots Android for a long time, and still does today.

    Conclusion

    To me, it feels all of this work Google started with Treble in 8.0 and continued in subsequent releases is 'laying the foundations' towards improving Android's update reputation, or lack thereof.

    It is however a massive disappointment they discontinued their developer dashboard. Google must have statistics about the distribution of Android's OS, the various kernels devices are running, what mainline patch level they're using, which devices actually take Kernel LTS patches and what security patch level's users are running.

    The lack of transparency makes threads like this one guess work at best. I do wish there were datasets posted by various developers who have the capability to actually report on this information so we can get a better picture of the actual ecosystem health.

    If it transpires that the majority of users run an old kernel, old security patch, old OS and don't get support from an OEM then it shows Google still has work to do in this area. Here's hoping in 2021 we can notice some improvement.

    Thanks to Greg for his responses to my questions.

    submitted by /u/thecodingdude
    [link] [comments]

    Small phone users unite! Upcoming "actually-compact" phone from Unihertz the Atom XL

    Posted: 06 Feb 2020 08:56 AM PST

    Samsung Galaxy Unpacked 2020 | Pre-Register Now | Samsung UK

    Posted: 06 Feb 2020 01:00 AM PST

    Oppo Find X2 coming on February 22

    Posted: 06 Feb 2020 12:20 PM PST

    This is why Poco hasn’t launched a Snapdragon 865 or 855 phone yet

    Posted: 05 Feb 2020 10:22 PM PST

    ZTE Axon 10s Pro official listing reveals SD865, LPDDR5, USB 3.0, Wi-Fi 6 and more

    Posted: 06 Feb 2020 07:09 AM PST

    Exclusive: This is Motorola’s Next 5G Phone with a Curved “Waterfall” 90Hz Display

    Posted: 05 Feb 2020 08:44 PM PST

    The Banned Smartphone TEARDOWN! - Huawei Mate 30 Pro [JerryRigEverything]

    Posted: 06 Feb 2020 09:39 AM PST

    What's up with phones giving up on notification LED?

    Posted: 06 Feb 2020 01:22 AM PST

    for example new xiaomi phones K30/poco X2

    They slap there IPS panel so no always on display either.

    Is there some other popular way to see missed stuff that I am not aware?

    Surely we are talking cents in cost to have multicolor LED somewhere.

    submitted by /u/waregen
    [link] [comments]

    I appreciate how repairable and modular the Moto E5 Play/Cruise on the inside.

    Posted: 05 Feb 2020 09:32 PM PST

    In addition to the phone having removable battery and is fastened by small Philips-head screws. Inside, most of the parts are replaceable, without the need for soldering or removal of adhesives.

    The power and volume control are on its own flex cable. The charging port/microphone are on its own separate daughterboard, and is connected via a flex cable. Removing the motherboard and daughterboard only requires small Philips-head screws.

    Oh and if you need to replace the parts, you can find them on eBay/Aliexpress for about $5. It's like this phone is meant to last long/to be repaired.

    You might say all low-end phones are like that. But not so, at least on Samsung's J series. The charging port and volume controls are built into the motherboard. If those goes bad, and you need to replace them. Either be good at micro-soldering, or replace the whole board altogether.

    This phone is nothing special. It's just a low-end phone that I got for free, from Cricket. But, I do appreciate how serviceable it is.

    submitted by /u/MNLYEvangelista
    [link] [comments]
    Read more
    at

    No comments:

    Post a Comment

    Fashion

    Beauty

    Travel