Anyone know if there's a way to get the Oreo "Recent apps" feature back? The new one is fairly terrible in my opinion, it now takes many more swipes to get back to the app I want.
Introducing Android 9 Pie
341–350 of 367 posts
Re: Introducing Android 9 Pie
#342Earlier quoted context omitted.
> Because Linux APIs were never really intended to be called by NDK developers But pretty much all the "unintended" uses of Android APIs (undocumented or not) have been the most original and best-integrating apps I've seen. It's a pity.
Would you please offer an example of such an app and its outstanding features?
I wouldn't say "outstanding", I'd say original. For example the app that mapped the Samsung Bixby button to something else, Greenify, Island and Helium. There are others, but these came to my mind first.
Re: Introducing Android 9 Pie
#343I wonder if Google's own apps are exempt from adaptive battery? I continue to have problems with Google's apps soaking my phone's battery. Reset the phone, and I get 6 days of standby (this is LineageOS). Install Google apps, and it's now 4 hours. Wakelock detector says the apps Inbox, Google, and Google Contacts are the top offenders with dozens of wakes keeping the phone awake between 40% and 99% of the time. Super…
That wakelock detector is probably showing wrong data (especially on newer API levels). Can you try something more advanced like Battery Historian (in dev tools) to see what's waking up the CPU? (And no, Google apps are beholden to all power saving restrictions like other apps - Play Services being the exception because it services functionality that must work at all times.)
Battery Historian isn't really helping pin this down. CPU is running the whole time over night, ~5%/hr drain doing nothing. Kernel only uptime has hundreds of events per minute with reason "unknown". Userspace wakelocks total less than 16s every 20 minutes with no app I recognize named (Babel_ConcService is the top offender). Top app is blank as is Long waklocks and Screen. Doze is "light" all night.
Kernel Wakesources:
Ranking | Name | Duration / Hr | Count / Hr | Total Duration | Total Count
0 | event1 | 17m59s340ms | 23457.57 | 3h2m57.557s | 238578
1 | event5 | 17m32s350ms | 23463.47 | 2h58m23.053s | 238638
2 | alarmtimer | 1m47s350ms | 53.59 | 18m11.818s | 545
3 | wlan | 45s341ms | 58.99 | 7m41.149s | 600
4 | bluetooth_timer | 23s642ms | 194.68 | 4m0.462s | 1980
Kernel Wakeup Reasons:
Ranking | Name | Duration / Hr | Count / Hr | Total Duration | Total Count | Show Count vs Time
0 | unknown | 57m26s285ms | 11789.25 | 9h44m10.852s | 119904 |
App Wakeup Alarms:
Ranking | Name | Uid | Frequency (count/hr) | Count
0 | GOOGLE_SERVICES | 10033 | 60.66 | 617
1 | com.android.providers.calendar | 10004 | 0.20 | 2
Time Spent In Each App State:
Name | Uid | Top / Hr | Foreground Service / Hr | Top Sleeping / Hr | Foreground / Hr | Background / Hr | Cached / Hr
GOOGLE_SERVICES | 10033 | 7s202ms | 59m52s311ms | 0ms | 486ms | 0ms | 0ms
bbc.mobile.news.ww | 10109 | 5s312ms | 0ms | 0ms | 0ms | 762ms | 16m48s169ms
net.sourceforge.opencamera | 10097 | 5s71ms | 0ms | 0ms | 0ms | 0ms | 59m54s209ms
com.google.android.tts | 10072 | 4s910ms | 88ms | 0ms | 0ms | 0ms | 59m54s200ms
com.cyanogenmod.trebuchet | 10026 | 3s247ms | 0ms | 59m44s851ms | 0ms | 0ms | 11s900ms
Anyway, battery life goes to about 4 days standby if I put the phone in airplane mode. Or if I reset the phone and then on next boot I don't enter my Google account info. I have one bugreport where the discharge rate varied between 15% and 40% per hour, but there's no battery data due to overflow (?) looks like I'm only getting 3-4 hours of detailed data after a reboot.
Re: Introducing Android 9 Pie
#344Earlier quoted context omitted.
Android may have always been available at no cost, but it was never free. Always assume if you are given a service gratis, that _you_ are the product being sold. This doesn't just apply to Android, but to gmail, Drive, Docs, etc.
Free (Libre) Software is very often gratis as well, and generally breaks the "if you're not the customer..." rule. In the case of Android, there are community-maintained forks that do not include any of the Google stuff.
It might be true that libre software can break that rule. AOSP isn't libre, and the libre forks are so hobbled by limited access to Apps and the Play Store that there IS a cost to using them: the cost of losing very useful features that are only available in AOSP.
Re: Introducing Android 9 Pie
#345Earlier quoted context omitted.
Android may have always been available at no cost, but it was never free. Always assume if you are given a service gratis, that _you_ are the product being sold. This doesn't just apply to Android, but to gmail, Drive, Docs, etc.
That being said - for the end user Android isn't free. It's a part of a device sale that they're paying for.
There's a difference between the product made by a manufacturer, and the OS distributed by Google (their "service"). If we are talking about Google's incentives, than we have to look at their relationship with Android as a product. They are giving away Android to manufacturers for free. It's _Google_ that has the incentive to sell the users' data. That we purchase devices preloaded with Android doesn't pass that sale off to Google (like it would to Microsoft with a Windows computer), so it doesn't take away their incentive. So for the purposes of determining at what social cost you use Android, it might as well be gratis.
Re: Introducing Android 9 Pie
#346Earlier quoted context omitted.
Android may have always been available at no cost, but it was never free. Always assume if you are given a service gratis, that _you_ are the product being sold. This doesn't just apply to Android, but to gmail, Drive, Docs, etc.
guess the same must be true for Linux, gIMP, emacs, vim, gcc, clang, LibreOffice.
There is a cost to using FOSS, though it's much less sinister than that of using Android or Google Apps. You are giving up convenience in exchange for software that respects you. In terms of the user becoming the product, I suppose that would be harder to argue. Maybe one could say the users become co-opted to promoting the cause/agenda of FOSS.
Re: Introducing Android 9 Pie
#347I was just hoping for them to retire those stupid round adaptive icons. They did not. Also it's not clear if the old style of switching "opened" apps will still be there? Because the new one with the full screen preview seems more flashy but less practical(think alt+tab vs win+tab on Windows).
I think the idea was good, it's just too bad so many apps (many by Google) went the lazy path of leaving the icon as-is and adding a white background layer. Also note that they're only circular on Pixel.
To be fair the API given is pretty c*p when you have to target older Androids as well (and don't want to give them an uglier icon). If I remember right I had to simplify the icon as well (remove transparency I think) because Android doesn't like many things that are okay in svgs.
Re: Introducing Android 9 Pie
#348Earlier quoted context omitted.
Yes I would forgive anyone who used pre-s6 devices to think Samsung is some lackluster copycat with slow TouchWiz UI and terrible useability
Why not just flash the ROM and install vanilla Android instead of settling for TouchWiz and other third party bloatware?
Because there is no vanilla Android ROM that works perfectly out of the box on all devices and you need a device with a unlocked bootloader to even that get far.
Re: Introducing Android 9 Pie
#349Earlier quoted context omitted.
That being said - for the end user Android isn't free. It's a part of a device sale that they're paying for.
There's a difference between the product made by a manufacturer, and the OS distributed by Google (their "service"). If we are talking about Google's incentives, than we have to look at their relationship with Android as a product. They are giving away Android to manufacturers for free. It's _Google_ that has the incentive to sell the users' data. That we purchase devices preloaded with Android doesn't pass that sale…
Note that 'their "service"' includes the Play Store, which is a not insignificant revenue generator for Google.
Re: Introducing Android 9 Pie
#350Earlier quoted context omitted.
> Because Linux APIs were never really intended to be called by NDK developers, only the POSIX subset and Android public native APIs. That's not even slightly true? Android doesn't pretend to be anything but a Linux system, with all the Linux details shining through in all their glory. There is a seccomp policy that blacklists some syscalls, but it's only 17 out of 271 for ARM64 and it's things like setuid or reboot…
You can try to do it, but good luck guaranteeing that your APK doesn't crash and burn across Android OEMs and people want to still give you money. These are the only APIs devs are officially allowed to touch. https://developer.android.com/ndk/guides/stable_apis Anything else is "works on my phone" kind of thing.
No, that's just wrong.
It becomes your responsibility to ensure your syscalls match and are available on the kernel you're actually running on which you may be confusing with "not allowed to use".
And very nearly all of the time this is a complete waste of everyone's time since the syscalls are a direct mirror of what's in libc anyway just with libc doing the compatibility for you.
But just to really prove that you can absolutely syscall on Android, one of the largest, most widely deployed & shipped NDK/SDK apps does it to workaround a missing futimes in bionic: https://cs.chromium.org/chromium/src/base/os_compat_android....