141–150 of 211 posts
I suppose this will kill multi-emulators like RetroArch. No-longer will they be able to load arbitrary ROMs from a microSD card or other generic storage.
Earlier quoted context omitted.
The second difference is, you can replace it - https://microg.org/
MicroG still talks to Google services. It takes their code off your device but doesn't relieve you of the primary issue, that everything is dependent on Google's cloud services to work, and that they can still track everything you sent to them.
Earlier quoted context omitted.
You're upset about them requiring hardware attestation in SafetyNet (I am too) so you move to a platform that is way less flexible and way more closed? Not a troll, I'm really curious.
I can give an anecdote. I love most things about iOS design more than Android, and I've used both, but have stuck with Android over the last 7-8ish years. Mainly because of the amount that I could customize things, freely make little app projects, install custom ROMs, etc. Over the last few years, it's gotten inconvenient to tinker, and I just don't find myself bothering with it anymore. I've run into issues where ce…
You seem to state it as a fact but I believe it is your opinion .
Earlier quoted context omitted.
Wouldn't the solution be to allow people who have legitimately unlocked their boot loader to also install a custom attestation root so that safety net can still say “the software running on this phone is the software the user intended and not a malicious 3rd party”? Or maybe safety net is not so much about user safety as it is about platform lockdown and vendor safety. The number of times I’ve been laughed out of a p…
Bootloader unlock is under user control by definition - it won't happen unless you're physically interacting with the device. The legitimate case for safety net is platform lockdown for things like financial apps. Banks and other financial services like to provide some form of insurance to users wrt. losing money in a security breach, and they can't do this unless the app really is being run on a pristine, locked-dow…
Root exploits more common, but bootloader exploits aren't unknown. String them both together and you can remotely root a device, unlock the bootloader, install another OS, and relock the bootloader. All of this without removing apps or data; do it properly (custom recovery for flashing the new OS) and all the user knows is that the device wasn't working for a while (until they notice the giant new notification Google services puts up now, but some users don't even know what notifications are and either won't notice or will ignore it) https://github.com/segv11/boot-unlocker
Earlier quoted context omitted.
I bought a Nokia 6.1 around 2 years ago, which is part of the Android One program and it worked well! Had all security monthly updates, the system is clean and stable, updated to major versions of Android smoothly without any issue. If I can, I will buy another Android One phone. There is an horror story about an Android One Xiaomi phone, but Nokia delivered the promise with the 6.1, according to my experience
> There is an horror story about an Android One Xiaomi phone Which one? I had a Xiaomi Mi A1 and nowadays I have a A2, both are fine Android One phones that still receives updates (in the case of A1, only security ones, but the A2 received a Android 10 update). Yeah, Xiaomi may take a while to update their phones in Android One program, but otherwise it is fine.
They had to stop 3 or 4 times the Android 10 deployment because of bugs and issues found by users after updating on their phones.
Good to know that it was an isolated case
Earlier quoted context omitted.
An application can require MANAGE_EXTERNAL_STORAGE permission to access all files.
I have a feeling that certain apps will end up forcing their users to accept the popup for this permission in order to continue scanning their storage for "bad" filenames. (A few mobile games rolling their own "protection" by looking for TWRP-related folders, for example)
> Note: The MANAGE_EXTERNAL_STORAGE permission allows apps to access potentially sensitive data on shared storage. In an upcoming policy announcement, look for Google Play to provide guidelines for apps that need this permission.
Earlier quoted context omitted.
I can give an anecdote. I love most things about iOS design more than Android, and I've used both, but have stuck with Android over the last 7-8ish years. Mainly because of the amount that I could customize things, freely make little app projects, install custom ROMs, etc. Over the last few years, it's gotten inconvenient to tinker, and I just don't find myself bothering with it anymore. I've run into issues where ce…
What makes iOS elegant over Android in your opinion ? You seem to state it as a fact but I believe it is your opinion .
- OS Frameworks are not designed for the next year's IO, rebooting last years best practices, rather have long term roadmaps.
- The build system has stayed mostly the same, instead of having had multiple reboots
- C and C++ are integrated with the rest of tooling instead of feeling like an burden that has to be supported to keep game devs happy
- Everything that matters on iOS development is available in XCode, instead of being a mix of Studio templates, stuff dropped in Github that we are supposed to build ourselves and apparently official APIs (e.g. Oboe, Vulkan)
- Back to frameworks, while iOS offers high level frameworks for common workflows, Android offers Lego blocks that everyone fits in different ways with lengthy discussions on what is good Android code, MVP and whatever is the fad of the month on /r/androiddev
- When Apple does game development sessions, they actually talk about game development tech and do provide related tooling, Google talks about Play Store console and advertising for gamers. Notice that main GDC 2020 theme for the Google talks was to try to show that they are listing and trying to change, pity it came 10 years later.
- Most APIs in iOS seem to have had some though placed into them, in Android you have stuff like Animations that have had multiple instantiations, or others that have deprecated stuff even before reaching a proper release.
- When Google decided to drop Eclipse they had nothing to offer for NDK devs, almost two years later JetBrains decided to create CLion and then they had a solution. Otherwise most likely there still wouldn't exist an alternative to this day.
Earlier quoted context omitted.
It's not clear that push notifications have to be centralised. The OS could coalesce requests for notifications while still querying multiple sources, thus minimizing the time that radios have to be powered on.
I was involved in designing a POC that proved this many years ago now (but after Doze appeared on Android, causing power saving issues). Note this was all for Android though, and I think Apple's restrictions make it very difficult to do this there. There is a nice model for federating push services, and it worked. If you give apps a push "token" that takes the form of a URI or email-like address, the token can be nam…
I really don’t understand why mobile OSes don’t just adopt the Push API wholesale. Android especially. It’s such a mess having each app do its own thing and then have all kinds of problems with power saving measures; why not instead let the OS declare the push service to use (Google phones use FCM, Samsung phones use a Samsung push service, &c.), and apps just use what they’re given?