[android-developers] Digest for android-developers@googlegroups.com - 1 update in 1 topic

Comments: (0)
Tez <earlenceferns@gmail.com>: Feb 27 11:54AM -0800

In an accessibility service, how can I get the name of the current activity
the user is interacting with?
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to android-developers+unsubscribe@googlegroups.com.

[android-developers] Digest for android-developers@googlegroups.com - 4 updates in 2 topics

Comments: (0)
Digipom <digipom@gmail.com>: Feb 26 06:24AM -0800

I've been having some issues with startBluetoothSco() on my Nexus 5 on
Android Lollipop 5.0.1, where startBluetoothSco() will work and my
broadcast receiver will be called with an intent indicating that a
Bluetooth mic is connected, but when a recording is started, the audio is
recorded from the device's main input mic rather than the Bluetooth mic.
This issue is also reproducible on the Nexus 7 and may affect other devices
running 5.0.1 as well.
 
Here is some example test code:
 
http://pastebin.com/aEbEUhfy
 
Does anyone know why this is happening? The same code works fine on earlier
versions of Android, and I can record from the Bluetooth mic there. On
5.0.1, I still get an intent indicating that the mic is connected, but the
device will record from the on-device mic rather than the Bluetooth mic.
 
The sample code requires these permissions in the manifest:
 
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission
android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
<uses-permission android:name="android.permission.BROADCAST_STICKY" />
 
The layout needs one button with android:id="@+id/recordStopButton".
 
I also opened up this bug
report: https://code.google.com/p/android/issues/detail?id=156264
Digipom <digipom@gmail.com>: Feb 26 10:52AM -0800

So the answer, at least for Lollipop, seems to be to
use AudioSource.VOICE_COMMUNICATION instead of AudioSource.MIC, which is
what is used on earlier versions.
 
On Thursday, February 26, 2015 at 9:24:07 AM UTC-5, Digipom wrote:
Digipom <digipom@gmail.com>: Feb 26 10:51AM -0800

So the answer, at least for Lollipop, seems to be to
use AudioSource.VOICE_COMMUNICATION instead
of AudioSource.VOICE_COMMUNICATION instead of AudioSource.MIC, which is
what is used on earlier versions.
 
On Thursday, February 26, 2015 at 9:24:07 AM UTC-5, Digipom wrote:
Madis Pink <madis.pink@gmail.com>: Feb 26 08:13AM -0800

This happens because drawable-nodpi is a more specific configuration
compared to drawable-v21.
(See http://developer.android.com/guide/topics/resources/providing-resources.html#BestMatch
and qualifier order of precedence
in http://developer.android.com/guide/topics/resources/providing-resources.html#table2)
 
I think just naming drawable-v21 to drawable-nodpi-v21 should work as in
that case it is more specific than just drawable-nodpi and should be used
on API>=21.
 
On Wednesday, 25 February 2015 21:45:17 UTC+2, Nathan wrote:
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to android-developers+unsubscribe@googlegroups.com.

[android-developers] Digest for android-developers@googlegroups.com - 4 updates in 4 topics

Comments: (0)
Leo <mr.leolink@gmail.com>: Feb 25 06:16PM -0800

I tried to move an ImageView on touch events by this code:
 
http://pastebin.com/Wr033FfP
 
At first, everything worked well on Nexus 5 (Android 4.4.4 and Lollipop).
But then I tried on older versions of Android like 4.0.4(Galaxy S2) or
Nexus S(4.1.1)... and none of them worked.
 
Then after struggling for a while, I came up with this solution and it
worked well on all devices:
 
(Notice that now, I keep track of the ImageView's matrix object by a local
object instead of getting it via ImageView's getImageMatrix())
 
http://pastebin.com/UyrwivAh
 
I got the solution but I still couldn't get why my former code didn't work?!
 
I tried to research but the only thing made sense was the documentation of
ImageView's getImageMatrix():
 
Return the view's optional matrix. This is applied to the view's drawable
when it is drawn. If there is no matrix, this method will return an
identity matrix. Do not change this matrix in place but make a copy. If you
want a different matrix applied to the drawable, be sure to call
setImageMatrix().
 
Then it made me more confused by saying Do not change this matrix in place
but make a copy, what's the point of doing so? why can't I just do like I
did in the former code? (get the current matrix of the ImageView then apply
translation, then set it back via setImageMatrix() as the documentation
says)
 
Someone please shed me some light, this is too much confusion for me.
Nathan <nathan.d.mellor@gmail.com>: Feb 25 11:54AM -0800

I wanted to know if I can figure out how the usage of Data on Android Wear
influences battery life.
 
I'm not a hardware guy, just want to know it from a software developers. I
do believe Android Wear uses Bluetooth LE. (The rest is a hardware problem
;)
 
Are there some articles I can read on the subject?
 
For example, there has been some great stuff written about internet use and
how it affects the power drain on an Android phone.
http://developer.android.com/training/efficient-downloads/efficient-network-access.html
 
For instance, I would love to know whether its better to send 5 megabytes
of stuff all at once, whether it is bad to send 5K every second all day
long, and so on and so forth.
 
I'm working on a presentation on Android Wear and battery life, and this
could be part of it. But at the moment, I don't know enough on the subject,
and would instead solicit feedback from the audience.
 
Nathan
Speaker at Wearables Tech Con.
http://www.wearablestechcon.com/
(Note use discount code 'Mellor' to save $200).
Nathan <nathan.d.mellor@gmail.com>: Feb 25 11:45AM -0800

Naming the folders
drawable-nodpi-v17
and
drawable-nodpi-v21
did do what I want it to do.
 
Now it looks so much nicer on Android 5.0 than on 4.4.
 
Nathan
 
On Monday, February 23, 2015 at 2:17:30 PM UTC-8, Sérgio Faria wrote:
marten <marten.gajda@googlemail.com>: Feb 25 05:55AM -0800

Thanks for sharing the link. I wasn't aware of this bug report.
 
Yes both apps are mine, but even though they have the signature, some user
complain about this error. Maybe they installed the apps form different
sources, i.e. Amazon and Google Play.
 
cheers
 
Marten
 
Am Freitag, 20. Februar 2015 12:29:18 UTC+1 schrieb Kostya Vasilyev:
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to android-developers+unsubscribe@googlegroups.com.

[android-developers] Digest for android-developers@googlegroups.com - 1 update in 1 topic

Comments: (0)
Raanan Nevet <rnevet@gmail.com>: Feb 24 06:20AM -0800

Has this changed? otherwise shouldn't the documentation reflect this?
 
On Monday, September 13, 2010 at 5:50:29 AM UTC+2, Dianne Hackborn wrote:
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to android-developers+unsubscribe@googlegroups.com.

[android-developers] Digest for android-developers@googlegroups.com - 2 updates in 1 topic

Comments: (0)
Nathan <nathan.d.mellor@gmail.com>: Feb 23 01:44PM -0800

No ideas?
 
In Android Wear, it is definitely using the vector drawable.
 
In Nexus, 9, it is definitely using a raster one and there appears to be
now way to force it.
 
Nathan
"Sérgio Faria" <sergio91pt@gmail.com>: Feb 23 10:02PM

Maybe if you move face.png to drawable-nodpi-v17 it will work
If it doesn't work you can use the inflate method to force it.
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to android-developers+unsubscribe@googlegroups.com.

[android-developers] Digest for android-developers@googlegroups.com - 10 updates in 3 topics

Comments: (0)
Kostya Vasilyev <kmansoft@gmail.com>: Feb 20 03:21AM -0800

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:
erdo <eric@ixpocket.com>: Feb 20 10:21AM -0800

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. By model I mean the M in MVC or the M in
MVVM or the VM in MVVM. (Let's say an account object)
 
You can inject this model class into your views/activities/fragments when
you need it - using dagger or you can just roll your own dependency
injection code via the application class.
 
That means that the fragment/activity classes just manage their lifecycle
and get references to whatever models they need (an account object, maybe a
network state object or whatever) and do as little else as possible.
 
When you update the UI, you just run a syncView() method on the fragment or
your custom view class (my preference, as it removes even more code from
the fragment) that sets the state of all the UI components eg:
textView.setText(account.getAccountName()); you just need to make sure all
the get() methods on your models return immediately.
 
Any network connectivity or other stuff that needs to be done on a separate
thread, I would do from the model class which mostly exists independently
of any activity/fragment lifecycle (saving you a whole heap of lifecycle
trouble).
 
Once the network stuff has returned with data or an error to the model
class, I use the Observer pattern so that the views/activities/fragments or
other models that are interested, get notified of the change to the model
and then update themselves based on the model's new data (see the
syncView() method above). You can roll your own simple observer classes (my
preference) or use something like RxJava or even Otto can be used this way.
Also if you send all your update notifications on the UI thread, you'll
save yourself some headaches when updating UIs based on them.
 
So the models themselves will make use of Volley or Retrofit/OKHttp (both
are pretty good and I would definitely use one of them) and may have
AsyncTasks in there too. You just have to make sure (especially when using
AsyncTasks) that you can independently test the models which means being
able to inject the networking stuff (substituting mocked versions for
tests). The way AsyncTask is designed makes it particularly awkward to
test. You can: Write complicated tests to handle the threading problems
using a latch and so on; Test only using a framework like espresso (but
then you will be testing via the UI and not strictly doing a unit test; Or
you can wrap AsyncTask in your own class that can be used in a synchronous
way for tests - that's what I do and it makes the tests much simpler.
 
If you're fetching lists of stuff, I'd use the model classes to write
straight to a database once the data has been fetched from the network.
ContentLoaders while they do clutter up your fragment/activity code, do
seem nice and performant and have a built in observer style mechanism so
when the data in your database changes, your view gets immediately
refreshed. You do have to write a content provider but personally I think
it's worth it.
 
 
I just realised how complicated all of this sounds, but it is actually so
much simpler than jamming everything in your activity classes, which is
just crazy but very common to see. I think it's a major failing of Android
(as opposed to iOS or windows phone, or maybe most other application
platforms!?) that it seems to have been designed with no thought about the
absolutely fundamental issue of how you should separate models from views
or how you might test your code.
 
 
http://en.wikipedia.org/wiki/Observer_pattern
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf
Kristopher Micinski <krismicinski@gmail.com>: Feb 20 01:14PM -0500

Agreed, thanks for the heads up!
 
Kris
 
 
Kristopher Micinski <krismicinski@gmail.com>: Feb 20 06:10PM -0500

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 app and the network happen with something
pretty straightforward. (As an example, in Volley, the threads are
somewhat hidden in the request order, and you build up request objects
to send to them.)
 
The thing I *don't* want to see is a lot of use of shared variable
concurrency to coordinate stuff with a `Thread` instance that is
passed to the network, but it doesn't seem like that pops up all that
often.
 
Kris
 
 
Kostya Vasilyev <kmansoft@gmail.com>: Feb 21 03:26AM +0400

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, served up by a content provider (most of
the time anyway, when I need simple automatic cursor-based re-query).
 
-- K
 
Kristopher Micinski <krismicinski@gmail.com>: Feb 20 06:48PM -0500

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 cases where Java's threading primitives might have
some performance benefit, but I think for the case of most apps, it's
more important to have something easy to reason about than
hyper-optimized network throughout.)
 
Kris
 
 
marten <marten.gajda@googlemail.com>: Feb 20 12:33AM -0800

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
they install the properly signed version from Google Play.
 
The root of all this is that there is no way to grant a permission that
hasn't been granted at installation time. And Google is making it worse
instead of fixing it. At present the only solution seems to be to use no
permissions at all and that's certainly not what this is intended for.
 
If there is someone from Google in this Forum: How is this intended to work?
 
thanks
 
Marten
 
Am Donnerstag, 19. Februar 2015 19:21:40 UTC+1 schrieb Marina Cuello:
Kostya Vasilyev <kmansoft@gmail.com>: Feb 20 03:29AM -0800

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
mine (and needs a permission declared there) added an identical permission
declaration stanza in his app too.
 
A clever hack, on Android prior to 5.0, it lets the user install mine and
his apps in either order.
 
Since Android 5.0, only one app can be installed at a time -- trying to
install the other one fails with Play error code 505.
 
I don't work for Google, so can only post a link to the bug tracker
-- https://code.google.com/p/android/issues/detail?id=79375 -- and maybe
recommend trying "signature" protection level, since both apps are yours
and (as I understand) you hadn't released the new one yet, so you can still
make that change.
 
-- K
 
On Friday, February 20, 2015 at 11:33:25 AM UTC+3, marten wrote:
Jonathan S <xfsunoles@gmail.com>: Feb 20 12:28PM -0800

uses-permission and permission have to be unique
 
On Wednesday, February 18, 2015 at 10:27:03 AM UTC-5, marten wrote:
andrew_esh <andrew.c.esh@gmail.com>: Feb 20 07:38AM -0800

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. I am
guessing that since that may not be the history, then other app developers
have found a way to avoid this bug. You need to find that method and add it
to your code.
 
The problem may be that the specific stack trace you're looking at is
showing where the problem is triggered, but it is not showing where the
problem gets set up. Maybe android-2.3.4_r1 is the only OS version which
allows a null string to be returned from a certain function call that
you're making. Your code might rely on that string always being non-null,
and passes it into this call stack. The other OS versions don't have the
problem because they don't have the conditions that produce a null string.
 
Your code could test that string for null, and avoid making the call if it
is. If you must make the function call, you could replace the null string
with something else that won't cause the error. Emit a message, so you can
track the problem. Enhance the later code to continue gracefully if the
string was found to be null. This is defensive programming. You're right in
thinking it should not be necessary, but you must also consider the reality
that it is.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to android-developers+unsubscribe@googlegroups.com.

[android-developers] Digest for android-developers@googlegroups.com - 12 updates in 6 topics

Comments: (0)
Kristopher Micinski <krismicinski@gmail.com>: Feb 19 03:03PM -0500

I am trying to get an idea of what most developers use to interact
with web services.
 
The two main patterns I see in apps is to either create:
- Create an AsyncTask to make restful requests, and then do
something with `onPostExecute`, or to
- Create a service, and then have some API between the app and the
service, perhaps backed by a database.
 
I would suspect that for simple cases, the first thing would suffice,
and for more advanced cases, the second might be necessary. I was
wondering if there were any other patterns that app developers used
that I hadn't thought about,
 
Kris
TreKing <trekingapp@gmail.com>: Feb 19 02:13PM -0600

On Thu, Feb 19, 2015 at 2:03 PM, Kristopher Micinski <krismicinski@gmail.com
 
> I was
> wondering if there were any other patterns that app developers used
> that I hadn't thought about,
 
Use a library like Volley or Retrofit.
 
-------------------------------------------------------------------------------------------------
TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago
transit tracking app for Android-powered devices
Kristopher Micinski <krismicinski@gmail.com>: Feb 19 03:30PM -0500

Right, that's a good point I did not mention.
 
I'm interested in knowing what percentage of apps use a framework like
this rather than facilities purely within the "vanilla" Android
framework.
 
I can do some rough calculations in a while by grabbing a bunch of
apps and running some analysis on them,
 
Kris
 
 
Kostya Vasilyev <kmansoft@gmail.com>: Feb 20 01:17AM +0400

A service "turned inside out"
 
A "mediator" class that manages a pool of threads, submits / cancels /
executes task objects, manages the wake lock (based on having tasks).
 
And a service whose only responsibility is to do startForeground /
stopForeground when it's told to.
 
All in the same process.
 
This way I don't have to bind to a service (which is asynchronous) and it's
easier to manage state in the UI, to indicate to the user what the app is
doing, and to queue up tasks when necessary.
 
-- K
 
Kristopher Micinski <krismicinski@gmail.com>: Feb 19 08:32PM -0500

I agree, that sounds like a useful pattern. I *think* that's
relatively close to how Volley is implemented (though I haven't read
the implementation fully), too.
 
Do you have any pointers to open sourced code that would provide an
example of such a behavior? If not, no big deal: I can certainly
write one myself, and am not asking you to open-source code from your
codebase.
 
Kris
 
 
Marina Cuello <marina.eariel@gmail.com>: Feb 19 03:09PM -0300

Hi!
I'm not sure how to help, because've only met this problem when there
are several users set on a device.
 
If I install my app directly from Eclipse with my debug certificates,
then uninstall the app and try to install a production copy, made with
the release certificate, I've got the same error message
INSTALL_FAILED_DUPLICATE_PERMISSION.
 
Until I uninstall the app in every user by hand, I can't install the
new one. At least in your case the error message makes sense :)
 
When I was trying to understand that error message, I've read that it
affected permissions with android:protectionLevel declared as
"signature". Are you using that? Can you change it to "normal" without
affecting your business model?
 
 
Marina
 
Fran Marzoa <fmmarzoa@gmail.com>: Feb 19 09:51AM

Except I am not doing it...
 
"Sérgio Faria" <sergio91pt@gmail.com>: Feb 19 03:55AM -0800

Well, either the stack trace is wrong or the source is not the one I linked
to (android-2.3.4_r1) or you're doing new File((String) null)
 
Let's see:
 
3 at java.io.File.<init>(File.java:139)
138. public File(String path) {
139. init(path);
 
2 at java.io.File.init(File.java:189)
 
186. private void init(String dirtyPath) {
187. // Cache the path and the absolute path.
188. // We can't call isAbsolute() here (http://b/2486943).
189. String cleanPath = fixSlashes(dirtyPath);
 
1 at java.io.File.fixSlashes(File.java:205)
202. private String fixSlashes(String origPath) {
203. // Remove duplicate adjacent slashes.
204. boolean lastWasSlash = false;
205. char[] newPath = origPath.toCharArray();
 
On Thursday, February 19, 2015 at 9:59:30 AM UTC, Fran wrote:
Fran Marzoa <fmmarzoa@gmail.com>: Feb 19 02:01PM

My app has about 20,000 boots a day, and every single crash like this one
is reported to be occurring exclusively with such 2.3.4 Android version.
Every single one, in spite such version represent less than 5% of the
devices were my app is installed. No other Android version is affected at
all. Thus the causal variable is clearly isolated and identified and it is
not within my code.
 
I am not sure if those users are using specifically that 2.3.4_r1 code
neither, but it doesn't matter anyway and investigating it further is
pointless since I cannot change the user's underlying OS version.
 
I will have to live with it, I guess. I googled such problem, find this
thread, and just wanted to point out that this bug is still around.
 
Bests,
 
smichak <smichak.uv@gmail.com>: Feb 19 06:12AM -0800

Hi,
 
I have noticed that in Android Lollipop (API Level 21) there's a
VoiceInteractionService class
(http://developer.android.com/reference/android/service/voice/VoiceInteractionService.html)
which apparently allows an app to setup Hotword Detectors which fire a
callback when a certain hotword is recognized by the VR module. Although
the class is available in the SDK I don't see any guide or detailed
documentation on how to use it. Digging in the AOSP code I found out that
there's a system service for VR but this service is not available for
arbitrary apps, just system or platform signed apps. I guess this service
is used by Google Services for servicing Google Now's voice activation
(a.k.a "OK Google"). If so, I can't understand why this service is
available in the SDK.
 
Can someone from Google provide some information about this? Is there a way
to add Voice Interaction the apps now or in the future? Also, if someone
knows about an alternative Voice Interaction package that may be used I
would be glad to hear about it.
 
 
Micha
ps-geolives <pscheven@gmail.com>: Feb 19 02:23AM -0800

Hello.
 
The bug has been confirmed by Google :
https://code.google.com/p/gmaps-api-issues/issues/detail?id=7619
 
Best regards.
 
Le vendredi 6 février 2015 09:54:50 UTC+1, ps-geolives a écrit :
Miha <miha.valencic@gmail.com>: Feb 18 11:49PM -0800

Hi!
 
I'm reposting this from android-platform, as there was no response. Perhaps
someone here knows how to fix this?
 
I have a system app (signed with platform keys), and this app is injecting
events. It is using uinput and tries to use /dev/input/eventN (where N is a
number) as well.
 
If I run the code as root (i.e. with su), the code can obviously open
/dev/input/eventN and can inject events in there. If the code is run from
the system app, I get permission denied when opening /dev/input/eventN with
open("/dev/input/event1", O_RDWR). Uinput works fine, however, even in
system app.
 
The permissions requested by the system app are:
<uses-permission android:name="android.permission.READ_FRAME_BUFFER"
tools:ignore="ProtectedPermissions"/>
<uses-permission android:name="android.permission.ACCESS_SURFACE_FLINGER"
tools:ignore="ProtectedPermissions"/>
<uses-permission android:name="android.permission.INJECT_EVENTS"
tools:ignore="ProtectedPermissions"/>
<uses-permission android:name="android.permission.BIND_INPUT_METHOD"
tools:ignore="ProtectedPermissions"/>
 
 
For what it's worth, this system app also reads screen (using screencap
binary), and is able to do so. So it is very strange it is not able to open
with r/w /dev/input/eventN.
 
You might wonder what's wrong with uinput if that works. The problem with
uinput is that I have problems injecting touch events. Specifically, I can
not "click" (tap).
I can drag, swipe, inject keyboard events, but clicking (tapping) just does
not work. It seems as if it is stuck with long press. It does not register
the final event, where ABS_MT_TRACKING_ID is set to 0xffffffff.
 
The code I'm using for "click" (tap) is:
// pointer down
send_event(EV_ABS, ABS_MT_SLOT, 0);
send_event(EV_ABS, ABS_MT_TRACKING_ID,
m_tracking_id++ % 65535);
send_event(EV_ABS, ABS_MT_TOOL_TYPE, MT_TOOL_PEN);
 
// pointer coordinates
send_event(EV_ABS, ABS_MT_POSITION_X, x);
send_event(EV_ABS, ABS_MT_POSITION_Y, y);
send_event(EV_ABS, ABS_MT_TOUCH_MAJOR, m_tracking_id % 2 ? 0x3c : 0x30);
send_event(EV_ABS, ABS_MT_PRESSURE, m_tracking_id % 2 ? 20 : 25);
send_event(EV_SYN, SYN_REPORT);
 
// pointer up
send_event(EV_ABS, ABS_MT_TRACKING_ID, -1);
send_event(EV_SYN, SYN_REPORT);
 
Any help or pointers greatly appreaciated.
 
Regards,
Miha.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to android-developers+unsubscribe@googlegroups.com.

[android-developers] Digest for android-developers@googlegroups.com - 7 updates in 5 topics

Comments: (0)
Sheng-Dean <littledot5566@gmail.com>: Feb 18 08:47PM -0800

Hi everyone,
 
I'm trying to extend the RecyclerView.Adapter class however I noticed that
all of the notifyDataSetChanged() and notifyItemChanged/Inserted/Removed()
method are declared final.
 
Looking into the source code, these notify methods simply notify the
RecyclerView's observer.
 
Can any of the Android SDK developers kindly explain why this decision was
made? What are the use cases you want us to avoid?
 
Thank you for reading!
freakingtux <kees.jongenburger@gmail.com>: Feb 18 11:48AM -0800

On Monday, February 16, 2015 at 11:28:51 PM UTC+1, TreKing wrote:
 
> I, personally, would not consider a "list of installed apps" as "private
> information", assuming you're not including personally identifying
> information for the given user along with said list.
 
Perhaps if you only installed apps from the google store and feel they know
already what you are running. If like some others you have installed
f-droid and are running your own application that *is* your own business
and nobody, not google and not you competitor has any business looking at
and using that information. So I clearly feel this information indeed is
private. The dialog that request such permissions are written in such a way
that they keep coming back unless you click the "right" answer witch is
also pretty annoying.
Marten Gajda <marten@dmfs.org>: Feb 18 03:58PM +0100

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 you can't install the app getting the error
INSTALL_FAILED_DUPLICATE_PERMISSION.
This is very annoying and I'd like to know that the suggested
solution/workaround to this is.
 
We have an Open Source task app that provides access to the tasks via a
ContentProvider. The concept pretty much equals the CalendarProvider. We
also have a (not yet Open Source) sync app that can sync to this task
app (or its ContentProvider).
The problem is that (in contrast to the CalendarProvider) our users
usually install the sync app first. That means the permissions of the
task app are not known when the sync app is installed. So they are not
granted automatically when the task app is installed afterwards.
 
Until Android 5 the solution was to define the same permissions in the
sync app. But that doesn't work any more in some cases. If the user
compiles the task app himself he can not use our sync app at the same
time, because they are not signed by the same key.
 
How can we achieve that we protect access to the task ContentProvider by
permissions still allowing them to use a self compiled version?
 
Even if both apps are signed by the same key it doesn't seem to work in
some cases (does Android 5 also require both apps to be from the same
source?)
 
A similar issue exists when another developer tries to build a sync app
that can sync to our task app. He can not add the same permissions,
because he can't use the same signing key. But if he can't add the same
permission definition his app won't get the permission if it's installed
before the task app is installed.
 
What's the solution of this mess?
 
thanks
 
Marten
 
--
Marten Gajda
Schandauer Straße 34
01309 Dresden
Germany
 
tel: +49 177 4427167
email: marten@dmfs.org
twitter: twitter.com/dmfs_org
 
VAT Reg. No.: DE269072391
Fran <fmmarzoa@gmail.com>: Feb 18 03:45AM -0800

It seems this problem persists more than three years after. I am
experiencing the same problem right now, all of them with Android 2.3.4
 
 
On Sunday, June 5, 2011 at 4:21:31 PM UTC+2, Derek wrote:
Fran <fmmarzoa@gmail.com>: Feb 18 03:46AM -0800

My stack dump, BTW:
 
0java.lang.NullPointerException1 at java.io.File.fixSlashes(File.java:205)2
at java.io.File.init(File.java:189)3 at java.io.File.<init>(File.java:139)4
at com.splunk.mint.DataFlusher$1.void run()(Unknown Source)5 at
java.lang.Thread.run(Thread.java:1019)6 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1088)
7 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:581)
8 at java.lang.Thread.run(Thread.java:1019)
 
On Sunday, June 5, 2011 at 4:21:31 PM UTC+2, Derek wrote:
"Sérgio Faria" <sergio91pt@gmail.com>: Feb 18 02:10PM

Given the stack above, it seems you're doing new File(null)
 
https://android.googlesource.com/platform/libcore/+/android-2.3.4_r1/luni/src/main/java/java/io/File.java
 
Rahul Kaushik <rahulkaushik85@gmail.com>: Feb 18 11:45AM +0530

one more thing meanwhile my hard disk got crashed where i generated my
keystore
 
Thanks
 
On Fri, Feb 13, 2015 at 11:18 AM, Rahul Kaushik <rahulkaushik85@gmail.com>
wrote:
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to android-developers+unsubscribe@googlegroups.com.

[android-developers] Digest for android-developers@googlegroups.com - 4 updates in 4 topics

Comments: (0)
Nathan <nathan.d.mellor@gmail.com>: Feb 17 02:32PM -0800

Since VectorDrawable is only in Android 5.0+, and one would presumably use
plain old raster drawables before then, I came up with a scheme.
 
I put face.png in drawable-nodpi.
I put face.xml in drawable-v21
 
Then, when I need the drawable in my custom view, I call.
 
Drawable drawFace =getResources().getDrawable(R.drawable.face);
 
I sure thought I was clever.
 
So of course, this will retrieve a VectorDrawable if it is running on
Android 5.0 or later, and a BitmapDrawable if it is running on 4.4 or
earlier, right?
 
Nope.
 
I debugged on a Nexus 9. The type of the returned Drawable was
BitmapDrawable.
 
To add to the mystery, I debugged on Android Wear device with Android 5.0
 
The drawable comes up as a VectorDrawable, just as I wanted.
 
Why wouldn't that happen on a tablet with Android 5.0? The targetSDK is 21.
The BuildTools version is 21.1.1. The minimum SDK is 17.
 
The VectorDrawable class has only a default constructor. I don't know how
to force a VectorDrawable to load if I went that route.
 
Nathan
JackN <jack@jacknorth.com>: Feb 17 01:26PM -0800

Free from sdk version too. At least so far since api v 1.5
 
On Tuesday, February 10, 2015 at 10:52:58 PM UTC-8, rahul kaushik wrote:
 
JackN <jack@jacknorth.com>: Feb 17 11:08AM -0800

According to your link, you should be telling the users that you are taking
and storing their confidential info on your servers. Do you disclose that
fact to your users?

Also, you might want to be careful when listening to the advice of some of
the amatuers on this board.

 
On Monday, February 16, 2015 at 2:11:30 AM UTC-8, Nitin choudhary wrote:
 
JackN <jack@jacknorth.com>: Feb 17 11:04AM -0800

" If the team wins the losing team will follow them on Instagram" = "app
interferes with or accesses another service or product in an unauthorized
manner." - perhaps
 
On Sunday, February 15, 2015 at 9:02:32 AM UTC-8, Atif Farrukh wrote:
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to android-developers+unsubscribe@googlegroups.com.