Got my bronze charging tag today. What makes it special for me is that I am the first to bag it (though it took more than double of expected questions).
Surprising I guess since charging is something that everybody had to do
Aside, in line with discussion yesterday, charging had nearly the same number of questions compared to whatsapp :)
Thanks to all you guys who help me fit in @MatthewRead: You may possibly recollect, "deletion of posts", incident which you handled very well, to my advantage ..Thanks
As per this Stack Overflow answer, Android apps using FLAG_SECURE in their activities are protected from screenshots being taken by the system.
However, this is not a hard guarantee. In Android Studio, I can still take screenshots of such "secure" apps with the button pointed out in this SO ans...
@MatthewRead I'm surprised that taking the screenshot from the debugger works.
They changed the way it all works since I was working on the Android graphics subsystem, but my understanding is that secure windows are rendered into a separate framebuffer, which is composited by the display controller hardware.
the "why are you taking my money" guy is back
I feel like the best thing to do is edit his question to say "how do I cancel a subscription in google play" and answer with a link to the support site. What do you think?
@beeshyams I don't think that's true, because you'd just get huge empty boxes instead of the text.
I hate on web fora where they use the spoiler feature just to hide large text blocks, because you have no idea whether the text is actually going to have a spoiler or not
@DanHulme: Visually unappealing maybe distracting also, but not everybody would be interested in the sections mentioned, those interested can click to read
Otherwise the huge length devalues the key element of answer and I don't favor omitting those sections for the completeness they provide
Let's talk about sets, baby
Android's backup service has a concept called a set: the set of all data backed-up from one device (on one transport, but that's a detail). Each set is identified by a unique string, such as the IMEI on the device. When an app (or the list of installed apps) is backed...
it's not just bold text, it's actually larger and better spaced
@Izzy Greenify has support for Tasker? Didn't know.
Raw concept (untested): Use tasker and Greenify. Profile something like "When app X is running › Greenify Playstore". When greenified, it won't do updates. — Izzy18 hours ago
As your device is rooted, you could use the Xposed module DisableFlagSecure:
An Xposed Framework module that disables FLAG_SECURE on windows system-wide. This lets you take screenshots and do screen capture in apps that normally won't let you. (That said, you probably don't want to leave this...
Just in case anyone here has an idea: Strange permissions in several apps (I've posted that on SO as it better fits where people have the "dev background" ;)
And I can give numbers, if anyone is interested ;)
Just google a few of that list after prefixing them with com.android., and you will find plenty of those logcat entries.
Btw: According to my (growing) stats, about 1/3 of all apps are somehow glued to the Google ecosystem. More than 10% are "hard glued" (i.e. either won't install at all or simply not run unless you've got GApps on the device). Shocking.
@Izzy Shocking? nope! I'm actually speculating (pun) that by the time Android P or Q would be launched, almost everything in AOSP would have been moved to proprietary Play Services in the name of solving the problem of keeping OS of every device in the world updated. The only thing vendors would have to do for qualifying their device for Play Services would be to test stability of wallpapers in all orientations. I guess that ~10% shows the results for early experiments of this plan. :P
--- Okay. This is strange to me. I'm trying `fastboot oem lock` (yes, lock, not unlock) and it outputs: > Device state transition will erase userdata. > Are you sure you want to continue this transition?
I don't understand this. Why would locking the bootloader should wipe data?
@Firelord Well, those "soft glues" don't bother me too much: I don't care e.g. whether an app can access my Gmail data, as I don't have Gmail installed. And OK, I can't use in-app payment via vending.BILLING. Other parts can be worked around, and so I e.g. can use GCM (thanks to microG) – and even was able to work around the "hard glue" of MAPS_RECEIVE via the maps API of the microG predecessor NOGAPPS. What really bothers me is vending.CHECK_LICENSE: no way around that except for LuckyP
@Firelord "primarily opinion-based" – but I say so, yes. If I bought an app, I've a right to use it, right? So what if, for privacy reasons, I don't want GApps on my device – but want to use "that app"?
Yeah, the licence checking Amazon does for example is annoying as heck. I had an app called Gentle Alarm that turned out to not be so gentle -- it tried to do a licence check and failed for some reason, so I couldn't open the app or shut off the alarm but the service kept running. Had to do a battery pull
@MatthewRead It appears that flipping the last byte of that partition can enable and disable FRP since it changes OEM Unlock bit. Well it doesn't hurt either if you zeroed the whole partition but have a backup of it, just to remain at safe side. // I spent hours in analysis only to find in the end that it is already covered here: forum.xda-developers.com/nexus-6/help/…
That link begins with information which conflicts with my observations. I was able to unlock the bootloader without enabling "OEM unlock" from developer settings. I was able to do flashing from fastboot and flashed stock images multiple time. At one time, I tried to check about FRP and noticed that after a reset, Android required me to verify the ownership at *supposed* first boot. --- All of this info is in consonance with the Android Police article linked in your answer.
Now, the XDA article I linked says that OEM unlock must be enabled to have the bootloader unlock but that's contradict…
Ah, OK. I think when FRP was added to the L dev branch, it wasn't disabled when you did that
And I wouldn't find it hard to believe that an OEM failed to make the bootloader check that OEM Unlock was enabled. They mess this stuff up all the time
@Izzy Android source code and official reference says that their permissions are prefixed with android.permission, not com.android. Could you check once again?
The example links I gave also show that clearly – e.g. "android.permission.READ_INTERNAL_STORAGE, android.permission.WRITE_INTERNAL_STORAGE" for RaspManager.
android.permission.SYSTEM_OVERLAY_WINDOW for GPS HUD, same thing.
Also, if those apps had declared them, that means their Manifests must have them as <permission …, not just <uses-permission …, right?
Not that I'd check some thousands APKs for it, but I could check a few examples.
GPS HUD: only uses-permission (not a single one declared on its own)
As per this Stack Overflow answer, Android apps using FLAG_SECURE in their activities are protected from screenshots being taken by the system.
However, this is not a hard guarantee. In Android Studio, I can still take screenshots of such "secure" apps with the button pointed out in this SO ans...
As your device is rooted, you could use the Xposed module DisableFlagSecure:
An Xposed Framework module that disables FLAG_SECURE on windows system-wide. This lets you take screenshots and do screen capture in apps that normally won't let you. (That said, you probably don't want to leave this...
Android Enthusiasts
Android Enthusiasts