I'm seeing this with android:protectionLevel=normal too.
Since Android doesn't grant permissions that had not been declared yet,
this forces the user to install apps declaring / using the permission in a
certain order.
This is a pain for the user, so the developer of one app that works with
You know, I don't. My apps aren't open source, and I came up with it
myself, not borrowed from a library.
But it's not rocket science, I'm sure you understand the pattern.
-- K
On Friday, February 20, 2015 at 4:39:32 AM UTC+3, Kristopher Micinski wrote:
I agree, that sounds like a useful
Hi Marina,
we're using android:protectionLevel=dangerous because that's what we
think is suitable for personal data like tasks. Also, it's what the
CalendarProvider uses for the permissions to read and write calendars.
At present the major issue is that some users get this error even though
The main hypothesis I'm wondering about is how developers pass data
from their app to the network. Since any use of the network
necessarily involves threads, there are a variety of ways this could
occur.
Most of the ways with which I'm familiar utilize methods where the
communication between the
uses-permission and permission have to be unique
On Wednesday, February 18, 2015 at 10:27:03 AM UTC-5, marten wrote:
Hi all,
we've some problems with Android 5. There seems to be a new policy that
requires two apps that define the same permissions to be signed by the
same key. Otherwise
For me, all network activity is performed by tasks which are executed by
executors on a pool of threads.
Not Java executors, but something a bit more flexible for my needs --
priorities, cancellation, per-thread affinity based on each task's account,
etc.
The data is written to a database,
Right, the way I understand it is that this (task based model) is the
pervasive for Android development. I would suspect that the only
people not using this model are those that are incorrectly using raw
threads because they haven't picked up on the right Android
facilities.
(I'm sure there are
Good analysis and reasoning. It leads to identifying a specific version of
the OS.
Let me add to the reasoning: If this was a bug in android-2.3.4_r1,
wouldn't many other apps that call the same function also trigger this bug?
Then the history would show a 2.3.4_r2 release with this bug fixed.
Agreed, thanks for the heads up!
Kris
On Fri, Feb 20, 2015 at 6:21 AM, Kostya Vasilyev kmans...@gmail.com wrote:
You know, I don't. My apps aren't open source, and I came up with it myself,
not borrowed from a library.
But it's not rocket science, I'm sure you understand the pattern.
-- K
Sorry for the huge post, but for what it's worth, every app that I do
nowadays has the same general pattern...
I basically have a model class(es) that incorporates any logic or data that
you don't want cluttering up your views/activities/fragments and where you
would do any networking stuff.
10 matches
Mail list logo
