[android-developers] Re: sharing jars across applications
add it to the system libraries Do you mean framework.jar? On Jul 21, 8:55 pm, Nikolay Elenkov nikolay.elen...@gmail.com wrote: On Sun, Jul 22, 2012 at 11:56 AM, Ubuntu guy sam_...@yahoo.co.in wrote: To be more specific, this is a platform library provided by the OEM (as an sdk add-on), So is the platform library ACTUALLY shared across applications? Unless you are building your own ROM and add it to the system libraries, not really. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: sharing jars across applications
On Sun, Jul 22, 2012 at 3:20 PM, Ubuntu guy sam_...@yahoo.co.in wrote: add it to the system libraries Do you mean framework.jar? Not necessarily, but same idea. System libraries (including framework.jar) are preloaded by the OS and shared by all applications. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Usage of DisplayMetrics
On Sat, Jul 21, 2012 at 8:02 PM, Jim Graham spooky1...@gmail.com wrote: I'm not sure I understand Are you saying that display.getWidth and display.getHeight don't return valid numbers? Or did I miss something? I am saying that I don't recommend using them, and I have no good strong use cases for them. And if that's the case, why even have them in the developers guide? If I was putting together the 1.0 SDK today, I would think hard about whether or not these go into the SDK. I don't recommend using them. Do you have a specific use case where you think they are the right way to go? -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
TransactionTooLarge means that the data being sent through the IPC call is
too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is if
the process is at an oom_adj level that is safe to kill by the OOM killer.
Just running a background service means it is safe to kill; the service
itself will be restarted if you have indicated this is what you want. This
is not a new situation that your app needs to deal with -- its process
could always have been killed while in this state if memory was needed
elsewhere (for example if the user launches a game that uses a lot of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as you
describe it -- yes your process gets killed, but this is a normal part of
operation you should be dealing with, and if you can't recover when it is
restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.com wrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to
ComponentInfo{com.example.android.app/com.example.android.app.receiver.SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309):
android.os.TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:346)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.Binder.execTransact(Binder.java:367)
07-21 23:57:40.286: W/BroadcastQueue(309): at
dalvik.system.NativeStart.run(Native Method)
07-21 23:57:40.286: W/ActivityManager(309): Scheduling restart of crashed
service com.example.android.app/.service.MainRunningService in 5000ms
To be honest, I've tried to read about the TransactionTooLargeException,
but I don't feel any wiser!
On Friday, July 20, 2012 11:23:11 PM UTC+1, Andy dev wrote:
Thanks. I'll keep looking for a solution then!
On Friday, July 20, 2012 11:04:13 PM UTC+1, Kostya Vasilyev wrote:
Yep, I can confirm this with my own foreground service on 4.1.1 (Galaxy
Nexus).
-- K
2012/7/21 Andy dev andrewpmo...@gmail.com
Anyone at least confirm what I'm doing looks ok - even if you don't
know the reason why. Just as a sanity check?
On Thursday, July 19, 2012 10:19:22 PM UTC+1, Andy dev wrote:
I've got a service running (an accessibility service called
MainRunningService) and also use an alarmmanager within my app.
On ICS when a user pulled up the task list and swiped the app away the
service kept running, but the user interface was cleared from the stack.
On jelly bean I'm finding this to be a little different. It seems like
it kills off the service and then restarts it even if I've got an icon in
the notification bar and I've got the app set to run in the foreground.
This is killing off all my current app state and causing it to stop
working.
Re: [android-developers] Call web service that returns an object
Thank you for your hint i got it corrected as follows SoapObject response = (SoapObject)envelope.bodyIn; SoapObject c2 = (SoapObject)response.getProperty(0); tv.setText(Category + c2.getProperty(0)); On Saturday, July 21, 2012 8:28:53 PM UTC+3, TreKing wrote: On Sat, Jul 21, 2012 at 3:25 AM, Mohammed Zarqa mmza...@gmail.com wrote: the returned object is a class (Category) and contains ID as integer, Name and description so what should i do to sync the category class defined in both web service and the android app. Parse the data you get to retrieve the individual properties of your custom object class, then create an instance of that class and set the properties. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Documentation for adb shell getevent / sendevent
hello, is there any documentation on the format of the getevent and sendevent shell commands? specifically the ones for touchevents. or is this device-dependent? it is a bit hard to guess what those ids are doing. thanks! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
I'm also seeing my application get killed even while it has a foreground
service.
It appears to happen on the next sendBroadcast() - which is an
implementation detail of how some of my components interact, and has
nothing to do with the service's startForeground() state. The service
remains in foreground state at this point (and is supposed to last about a
dozen seconds more).
Instead, the process gets killed, and I'm also seeing an
android.os.TransactionTooLargeException in the logcat.
The exception looks to me like an unfortunate and unexpected side effect of
the process getting killed.
The broadcast in question is sent farly often, its data payload is only a
few dozen bytes, and so it never triggers this exception under normal
circumstances.
-- K
2012/7/22 Dianne Hackborn hack...@android.com
TransactionTooLarge means that the data being sent through the IPC call is
too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.com wrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to
ComponentInfo{com.example.android.app/com.example.android.app.receiver.SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309):
android.os.TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:346)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.Binder.execTransact(Binder.java:367)
07-21 23:57:40.286: W/BroadcastQueue(309): at
dalvik.system.NativeStart.run(Native Method)
07-21 23:57:40.286: W/ActivityManager(309): Scheduling restart of crashed
service com.example.android.app/.service.MainRunningService in 5000ms
To be honest, I've tried to read about the TransactionTooLargeException,
but I don't feel any wiser!
On Friday, July 20, 2012 11:23:11 PM UTC+1, Andy dev wrote:
Thanks. I'll keep looking for a solution then!
On Friday, July 20, 2012 11:04:13 PM UTC+1, Kostya Vasilyev wrote:
Yep, I can confirm this with my own foreground
[android-developers] Re: Jelly bean swiping task away from task list kills service
Oh boy, I very much don't like the sound of that. Not particularly looking forward to getting a JB OTA update anymore after all the other backwards compat problems already reported by users. Pent -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Using android.R.id.title and getParent to remove TitleBar
On Sat, Jul 21, 2012 at 11:09 PM, Vance Turnewitsch betweenthehi...@gmail.com wrote: Is what I am doing safe? Not really. It could break on past versions of Android, future versions of Android, manufacturer-modified versions of Android, etc. Simply do not have a title bar managed by the system and put it inside your own app's UI instead. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Kostya, after tracking mine down more, it seems to be exactly the same.
It doesn't actually get killed until I get a broadcast. I'm not sending
them I'm receiving them from things like the SMS service, the battery level
the screen state etc, but any of those I've registered for cause the issue.
I'm not exactly sure which transaction is even going on at this point.
Dianne, thanks for your reply I really appriciate it, especially given your
position in the android team. I'll try and work on cutting down my code
into a manageable example as it's several hundred classes at the moment
(it's the app Light Flow in the market). I do hold quite a bit in static
variables, does any of that make a difference in this situation?
On Sunday, July 22, 2012 11:14:16 AM UTC+1, Kostya Vasilyev wrote:
I'm also seeing my application get killed even while it has a foreground
service.
It appears to happen on the next sendBroadcast() - which is an
implementation detail of how some of my components interact, and has
nothing to do with the service's startForeground() state. The service
remains in foreground state at this point (and is supposed to last about a
dozen seconds more).
Instead, the process gets killed, and I'm also seeing an
android.os.TransactionTooLargeException in the logcat.
The exception looks to me like an unfortunate and unexpected side effect
of the process getting killed.
The broadcast in question is sent farly often, its data payload is only a
few dozen bytes, and so it never triggers this exception under normal
circumstances.
-- K
2012/7/22 Dianne Hackborn hack...@android.com
TransactionTooLarge means that the data being sent through the IPC call
is too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.com wrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to
ComponentInfo{com.example.android.app/com.example.android.app.receiver.SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309):
android.os.TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
2012/7/22 Pent supp...@apps.dinglisch.net Oh boy, I very much don't like the sound of that. Not particularly looking forward to getting a JB OTA update anymore after all the other backwards compat problems already reported by users. You can look forward to 4.1.2, 4.2 or 5.0... Pent -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Usage of DisplayMetrics
On Sun, Jul 22, 2012 at 12:06:30AM -0700, Dianne Hackborn wrote: Do you have a specific use case where you think they are the right way to go? I use them for determining the maximum preview size for the camera preview. Whether that's the right way to go or not, I can't say, but it works nicely, and it's very simple. Just loop through the output of camera.getSupportedPreviewSizes() and pick the last one where the supported width and height are both lower than the display's width and height. The Developer's Guide (at http://developer.android.com/guide/topics/media/camera.html) only says something like set preview size [etc] here. ... nothing about not using display.width() and display.height() to find the upper limits, and nothing about a different way to do so, either. The book, Pro Android Media, does the same for determining the upper limits for the preview size, and then, as I did, loops through the supported preview sizes to find the max value. It seems to work fine, at least, for the devices I've tested it on. In camera.parameters, there's a getPreferredPreviewSizeForVideo. but that's the ideal size for supporting video recording. I haven't read anything that says that you should just assume that the display size is one of the supported preview sizes, nor would I make such an assumption (though it does at least *appear* to be true). So everything seems to point back to using display.width() and display.height() along with camera.getSupportedPreviewSizes() and a for loop to determine the maximum preview size for a given device. So, correct me if I'm wrong, but that would seem to be at least one valid use. And in this case, it seems to be not only the right way, but THE way. Later, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)MiSTie #49997 Running Mac OS X Lion spooky1...@gmail.comICBM/Hurr.: 30.44406N 86.59909W The iPad is a status symbol for yuppies. The Android is for people who actually want something that works. Android Apps Listing at http://www.jstrack.org/barcodes.html -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Usage of DisplayMetrics
How about View width and height instead of Display? On Sunday, July 22, 2012 12:31:21 PM UTC+1, Spooky wrote: On Sun, Jul 22, 2012 at 12:06:30AM -0700, Dianne Hackborn wrote: Do you have a specific use case where you think they are the right way to go? I use them for determining the maximum preview size for the camera preview. Whether that's the right way to go or not, I can't say, but it works nicely, and it's very simple. Just loop through the output of camera.getSupportedPreviewSizes() and pick the last one where the supported width and height are both lower than the display's width and height. The Developer's Guide (at http://developer.android.com/guide/topics/media/camera.html) only says something like set preview size [etc] here. ... nothing about not using display.width() and display.height() to find the upper limits, and nothing about a different way to do so, either. The book, Pro Android Media, does the same for determining the upper limits for the preview size, and then, as I did, loops through the supported preview sizes to find the max value. It seems to work fine, at least, for the devices I've tested it on. In camera.parameters, there's a getPreferredPreviewSizeForVideo. but that's the ideal size for supporting video recording. I haven't read anything that says that you should just assume that the display size is one of the supported preview sizes, nor would I make such an assumption (though it does at least *appear* to be true). So everything seems to point back to using display.width() and display.height() along with camera.getSupportedPreviewSizes() and a for loop to determine the maximum preview size for a given device. So, correct me if I'm wrong, but that would seem to be at least one valid use. And in this case, it seems to be not only the right way, but THE way. Later, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)MiSTie #49997 Running Mac OS X Lion spooky1...@gmail.comICBM/Hurr.: 30.44406N 86.59909W The iPad is a status symbol for yuppies. The Android is for people who actually want something that works. Android Apps Listing at http://www.jstrack.org/barcodes.html -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Usage of DisplayMetrics
On Sun, Jul 22, 2012 at 7:46 AM, RichardC richard.crit...@googlemail.com wrote: How about View width and height instead of Display? Precisely. It matters not a whit how big the display is. What matters is how big the preview SurfaceView can be, after taking everything else into account. So, correct me if I'm wrong, but that would seem to be at least one valid use. And in this case, it seems to be not only the right way, but THE way. The Camera AOSP app appears to use DisplayMetrics once, to determine the screen density. It does not use getHeight() and getWidth(). If it were THE way, the Camera app would be using it; otherwise the Camera app would not work. DisplayMetrics seems to be infrequently used overall in the AOSP apps, and even then is used primarily for density. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
2012/7/22 Andy dev andrewpmo...@gmail.com
Kostya, after tracking mine down more, it seems to be exactly the same.
It doesn't actually get killed until I get a broadcast. I'm not sending
them I'm receiving them from things like the SMS service, the battery level
the screen state etc, but any of those I've registered for cause the issue.
Well, my code sends broadcasts between the app's components, which is very
nearly synchronous, so I could not tell the difference.
I actually created and ran a small test, and can confirm this behavior with
100% certainty.
-- K
I'm not exactly sure which transaction is even going on at this point.
Dianne, thanks for your reply I really appriciate it, especially given
your position in the android team. I'll try and work on cutting down my
code into a manageable example as it's several hundred classes at the
moment (it's the app Light Flow in the market). I do hold quite a bit in
static variables, does any of that make a difference in this situation?
On Sunday, July 22, 2012 11:14:16 AM UTC+1, Kostya Vasilyev wrote:
I'm also seeing my application get killed even while it has a foreground
service.
It appears to happen on the next sendBroadcast() - which is an
implementation detail of how some of my components interact, and has
nothing to do with the service's startForeground() state. The service
remains in foreground state at this point (and is supposed to last about a
dozen seconds more).
Instead, the process gets killed, and I'm also seeing an
android.os.**TransactionTooLargeException
in the logcat.
The exception looks to me like an unfortunate and unexpected side effect
of the process getting killed.
The broadcast in question is sent farly often, its data payload is only a
few dozen bytes, and so it never triggers this exception under normal
circumstances.
-- K
2012/7/22 Dianne Hackborn hack...@android.com
TransactionTooLarge means that the data being sent through the IPC call
is too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.comwrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to ComponentInfo{com.example.**android.app/com.example.**
android.app.receiver.**SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309): android.os.**
TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at android.os.BinderProxy.*
*transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.app.**
ApplicationThreadProxy.**scheduleReceiver(**
ApplicationThreadNative.java:**767)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
BroadcastQueue.**processCurBroadcastLocked(**BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
Re: [android-developers] Usage of DisplayMetrics
On Sun, Jul 22, 2012 at 07:55:59AM -0400, Mark Murphy wrote: On Sun, Jul 22, 2012 at 7:46 AM, RichardC richard.crit...@googlemail.com wrote: How about View width and height instead of Display? Precisely. It matters not a whit how big the display is. What matters is how big the preview SurfaceView can be, after taking everything else into account. That's probably what I'm not clear on What is everything else in this case? If display.getWidth and display.getHeight report that my tablet's display size is 1280x752 (which, I just discovered, is NOT what Settings--About Tablet--System Information--display pixels reports---it reports 1280x800) ... h so which is right? I see what this is all about now. So display.getWidth/Height reports the wrong numbers, and View.getWidth() and View.getHeight() returns the correct display size? So basically, I just need to do this in my app: :%s/display/View/g right? I'm working on image processing right now, but I'll make that change the next time I edit anything on the Java side. Thanks, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)MiSTie #49997 Running Mac OS X Lion spooky1...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W Do not look into waveguide with remaining eye! Android Apps Listing at http://www.jstrack.org/barcodes.html -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Usage of DisplayMetrics
On Sun, Jul 22, 2012 at 8:21 AM, Jim Graham spooky1...@gmail.com wrote: That's probably what I'm not clear on What is everything else in this case? It doesn't matter. Put your SurfaceView in your layout, then calculate your preview size based upon the SurfaceView's size. I see what this is all about now. So display.getWidth/Height reports the wrong numbers, and View.getWidth() and View.getHeight() returns the correct display size? No, View's getWidth() and getHeight() return the size of the SurfaceView. You could have a 2px by 2px SurfaceView. You could have a 1080p SurfaceView. The screen size does not matter -- the SurfaceView's size does. Moreover, you are *passed* the height and width to use in surfaceChanged() of your SurfaceHolder.Callback. You do not even need to call getWidth() and getHeight() on the SurfaceView. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] USB support for All Android Devices...........
*Hi all, I am using HCL ME U1(Android-4.0.3) tablet for my tablet development. My question is All the android-4.0.3 IceCream Sandwitch device irrespective of vendor will support UsbManager and UsbAccessory library?? Because i have included USB_Host_shiel-2.0 library into Arduino-1.0.1 IDE and I can able to run demokit_20.pde sample on the Arduino UNO with host shield. https://github.com/felis/USB_Host_Shield_2.0 //This libray i have included in my arduino lDE. I have some sample application on my tablet, but when i connect my USB host shield with android device ,the tablet (or) Arduino with USB_Host_Shield is not recognized each other..Please tell me the reason if anybody knows? Thanks, Mahes. * -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: USB support for All Android Devices...........
Please take the heading as ADK support for all android-4.0.3 devices Thanks, Mahes On Sunday, July 22, 2012 7:03:16 PM UTC+5:30, Kumar Maheswaran wrote: *Hi all, I am using HCL ME U1(Android-4.0.3) tablet for my tablet development. My question is All the android-4.0.3 IceCream Sandwitch device irrespective of vendor will support UsbManager and UsbAccessory library?? Because i have included USB_Host_shiel-2.0 library into Arduino-1.0.1 IDE and I can able to run demokit_20.pde sample on the Arduino UNO with host shield. https://github.com/felis/USB_Host_Shield_2.0 //This libray i have included in my arduino lDE. I have some sample application on my tablet, but when i connect my USB host shield with android device ,the tablet (or) Arduino with USB_Host_Shield is not recognized each other..Please tell me the reason if anybody knows? Thanks, Mahes. * -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
I always wondered about this feature... i found out Foreground services
keep on running by accident... kinda surprised me since you then have to
make sure the code knows how to retain information the Service is
responsible of if the UI is brought back up.
Is any of this documented anywhere? i couldn't find any reference to it
(barely any reference to what swiping an app away from the Recents list
does actually)
On Sunday, July 22, 2012 10:19:23 AM UTC+3, Dianne Hackborn wrote:
TransactionTooLarge means that the data being sent through the IPC call is
too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.com wrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to
ComponentInfo{com.example.android.app/com.example.android.app.receiver.SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309):
android.os.TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:346)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.Binder.execTransact(Binder.java:367)
07-21 23:57:40.286: W/BroadcastQueue(309): at
dalvik.system.NativeStart.run(Native Method)
07-21 23:57:40.286: W/ActivityManager(309): Scheduling restart of crashed
service com.example.android.app/.service.MainRunningService in 5000ms
To be honest, I've tried to read about the TransactionTooLargeException,
but I don't feel any wiser!
On Friday, July 20, 2012 11:23:11 PM UTC+1, Andy dev wrote:
Thanks. I'll keep looking for a solution then!
On Friday, July 20, 2012 11:04:13 PM UTC+1, Kostya Vasilyev wrote:
Yep, I can confirm this with my own foreground service on 4.1.1 (Galaxy
Nexus).
-- K
2012/7/21 Andy dev andrewpmo...@gmail.com
Anyone at least confirm what I'm doing looks ok - even if you don't
know the reason why. Just as a sanity check?
On Thursday, July 19, 2012 10:19:22 PM UTC+1, Andy dev wrote:
[android-developers] HtcLinkifyDispatcher.apk messing default app association
Thanks to the geniuses of this world, on some HTC phones (in the US only it seems), HTC has modified the default Intent Chooser to comply with some Apple absurd patents: http://www.theverge.com/2012/5/16/3024889/htc-one-x-evo-4g-lte-custom-android-build-apple-patent-linkify The consequence is that the user is presented with a custom Intent Chooser without the Use by default for this action check box. It also has some side effect: I'm using this code to get the default video player app if any: Intent intent = new Intent(Intent.ACTION_VIEW); intent.setDataAndType(Uri.parse(http://1.2.3.4/video.avi;), video/*); ResolveInfo resolveInfo = context.getPackageManager().resolveActivity(intent, PackageManager.MATCH_DEFAULT_ONLY); It works fine on all device but when that HtcLinkifyDispatcher.apk is installed, above resolveInfo will point to HtcLinkifyDispatcher itself which when launched, display the custom HTC intent chooser. This makes knowing the default app for video impossible to know as this damn thing hooked the system. As anyone dealt with this and found a workaround, or should I say to my users to live with it (always seeing the HTC app chooser when clicking a video in that case), or to root their phone to uninstall the damn APK ? I would test this myself but the APK seems to be only installable on HTC devices as it uses android:sharedUserId=android.uid.system Many thanks to Apple and HTC for this mess :p. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Usage of DisplayMetrics
On Sun, Jul 22, 2012 at 5:21 AM, Jim Graham spooky1...@gmail.com wrote: That's probably what I'm not clear on What is everything else in this case? If display.getWidth and display.getHeight report that my tablet's display size is 1280x752 (which, I just discovered, is NOT what Settings--About Tablet--System Information--display pixels reports---it reports 1280x800) ... h so which is right? Given that you can have an arbitrary set of system controls around the screen, carving out an arbitrary amount of space from the size available to apps, that can be shown or hidden at arbitrary times, what does display size mean? (Not to mention more complicated organizations like say the screen being split to show multiple applications. Or other decorations within the window like the action bar.) The right way to do this is to put your UI up, giving the information to the system about how it should be shown, and letting it go through a layout with the screen to finally position and size your view that displays your content of interest, retrieving the size there. I see what this is all about now. So display.getWidth/Height reports the wrong numbers, and View.getWidth() and View.getHeight() returns the correct display size? It doesn't report the wrong numbers, it just can't guarantee to report the actual size that your view showing its content will have. Plus, you really want to be driven by being *told* the size of your view, since this can change over time, and you want to respond when it does. Pulling a size from somewhere and assuming that is fixed is a rigidity in your app that you should avoid. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] System.gc() causing slowdown from the second start of Activity
I know that System.gc() is needless and discouraged, and I don't try
to suggest otherwise, but the point is that it shouldn't cause issues
either (i.e. it should be useless at most).
If I add the following code to my Activity.onPause(), then my
application will be slow after the second start of the activity:
if (isFinishing()) {
System.gc();
}
I.e. the framerate in my GLSurfaceView will be reduced by 50%. If I
remove the System.gc() call, everything is totally fine, no matter how
many times I start the activity again (i.e. start it again after it
was finished()).
The relevant source codes here:
http://stackoverflow.com/questions/11601914/system-gc-causing-slowdown-from-the-second-start-of-activity
Please help! GC is discouraged but shouldn't mess up the View/Layout
destroying system of Android.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: System.gc() causing slowdown from the second start of Activity
Run the profiler.
On Sunday, July 22, 2012 5:41:55 PM UTC+1, Tamás Kovács wrote:
I know that System.gc() is needless and discouraged, and I don't try
to suggest otherwise, but the point is that it shouldn't cause issues
either (i.e. it should be useless at most).
If I add the following code to my Activity.onPause(), then my
application will be slow after the second start of the activity:
if (isFinishing()) {
System.gc();
}
I.e. the framerate in my GLSurfaceView will be reduced by 50%. If I
remove the System.gc() call, everything is totally fine, no matter how
many times I start the activity again (i.e. start it again after it
was finished()).
The relevant source codes here:
http://stackoverflow.com/questions/11601914/system-gc-causing-slowdown-from-the-second-start-of-activity
Please help! GC is discouraged but shouldn't mess up the View/Layout
destroying system of Android.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: System.gc() causing slowdown from the second start of Activity
Do you mean TraceView?
I tried with Debug.startAllocCounting, Debug.startMethodTracking(...),
made a lot of reports, but the result is the same:
practically same % spent in all methods. Just everything is slower in
absolute time during the GLSurfaceView rendering.
For example, the GL effects I use take more time, but the distribution
of method times is exactly the same. To be brief, everything is
slower, proportionally.
Memory allocation is fine, no leak, no increase in heap...
On Jul 22, 7:17 pm, RichardC richard.crit...@googlemail.com wrote:
Run the profiler.
On Sunday, July 22, 2012 5:41:55 PM UTC+1, Tamás Kovács wrote:
I know that System.gc() is needless and discouraged, and I don't try
to suggest otherwise, but the point is that it shouldn't cause issues
either (i.e. it should be useless at most).
If I add the following code to my Activity.onPause(), then my
application will be slow after the second start of the activity:
if (isFinishing()) {
System.gc();
}
I.e. the framerate in my GLSurfaceView will be reduced by 50%. If I
remove the System.gc() call, everything is totally fine, no matter how
many times I start the activity again (i.e. start it again after it
was finished()).
The relevant source codes here:
http://stackoverflow.com/questions/11601914/system-gc-causing-slowdow...
Please help! GC is discouraged but shouldn't mess up the View/Layout
destroying system of Android.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: System.gc() causing slowdown from the second start of Activity
In fact, traceview seems to report IDENTICAL times absolutely too,
which is strange, because if I use SystemClock.uptimeMillis() for
measurent, then I get higher values. And REALITY shows too that
methods take more time. But traceview reports contain same absolute
values --- I guess because traceview already reduces FPS, so the
results are not credible as absolute values. And as percents, they are
the same.
On Jul 22, 7:29 pm, Tamás Kovács falcon.firebre...@gmail.com wrote:
Do you mean TraceView?
I tried with Debug.startAllocCounting, Debug.startMethodTracking(...),
made a lot of reports, but the result is the same:
practically same % spent in all methods. Just everything is slower in
absolute time during the GLSurfaceView rendering.
For example, the GL effects I use take more time, but the distribution
of method times is exactly the same. To be brief, everything is
slower, proportionally.
Memory allocation is fine, no leak, no increase in heap...
On Jul 22, 7:17 pm, RichardC richard.crit...@googlemail.com wrote:
Run the profiler.
On Sunday, July 22, 2012 5:41:55 PM UTC+1, Tamás Kovács wrote:
I know that System.gc() is needless and discouraged, and I don't try
to suggest otherwise, but the point is that it shouldn't cause issues
either (i.e. it should be useless at most).
If I add the following code to my Activity.onPause(), then my
application will be slow after the second start of the activity:
if (isFinishing()) {
System.gc();
}
I.e. the framerate in my GLSurfaceView will be reduced by 50%. If I
remove the System.gc() call, everything is totally fine, no matter how
many times I start the activity again (i.e. start it again after it
was finished()).
The relevant source codes here:
http://stackoverflow.com/questions/11601914/system-gc-causing-slowdow...
Please help! GC is discouraged but shouldn't mess up the View/Layout
destroying system of Android.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] LVL + proguard: Google play answers Market not Managed
Hello, I´ve always used Android LVL + proguard without issues. After upgrading my apps to android 4 and above (V13), I´ve started having issues with LVL answers. If I test my app straight from Eclipse, using a test signature, everything works as expected. On the other side, after compiling using proguard Google Play answers Market Not Managed (code 3). I´ve verified it logging answers on com.android.vending.licensing.LicenseValidator.verify() I haven´t changed my config.txt on proguard, I have double checked that proguard is pointing to the correct config.txt and also I´ve manually updated my android target on project.properties (this is something I haven´t found on documents but is necessary). Any ideas on what could be causing this issue? Just to let you know, my config.txt is almost the same google creates as standard on ADP. Thanks, Gabriel Simões -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: OEM-Official ADB USB Driver support (rant)
Well there's two problems: One: the device does not show in $ ADB devices Two: There's of course no log info or anything that could help decipher what's going on, at least that I know of. On Saturday, July 21, 2012 10:00:19 AM UTC-7, Nikolay Elenkov wrote: On Jul 22, 2012 12:05 AM, JP wrote: On Saturday, July 21, 2012 1:13:27 AM UTC-7, Nikolay Elenkov wrote: Back on topic, the USB driver in the SDK works fine with the N7. Update the SDK and select the driver folder in device manager. Not for me, not. (USB debugging enabled) Oh well. What exactly is the problem? That driver is pretty generic and works with pretty much everything, all you need to do is add the manufacturer and device ids to the ini file. The entries for N7 are already there in the latest version. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: OEM-Official ADB USB Driver support (rant)
On Jul 23, 2012 3:08 AM, JP joachim.pfeif...@gmail.com wrote: Well there's two problems: One: the device does not show in $ ADB devices Two: There's of course no log info or anything that could help decipher what's going on, at least that I know of. Does Windows register a new device when you plug it in? Did you point device manager to the driver location? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: OEM-Official ADB USB Driver support (rant)
On Sun, Jul 22, 2012 at 11:06:46AM -0700, JP wrote: Well there's two problems: One: the device does not show in $ ADB devices Two: There's of course no log info or anything that could help decipher what's going on, at least that I know of. Just for what it's worth, when I first tried hooking up my Froyo phone via USB, I followed the instructions that said you MUST use a USB driver. It never worked, until I REMOVED said USB driver from the system. Then it worked great. When I got my tablet, I never installed a USB driver. It works great. You should only install a USB driver if it doesn't already work. (Or, put another way, to quote an old saying that probably pre-dates everyone on this list, Don't fix it if it ain't broke.) :-) Later, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4)MiSTie #49997 Running Mac OS X Lion spooky1...@gmail.comICBM/Hurr.: 30.44406N 86.59909W Now what *you* need is a proper pint of porter poured in a proper pewter porter pot.. --Peter Dalgaard in alt.sysadmin.recovery Android Apps Listing at http://www.jstrack.org/barcodes.html -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Is there any logical way to make a notification bigger / Make more then one.
I'm trying to work on an app that runs out of a notification. Right now I am trying to make the notification bigger so it has more prevalence on the screen. And if that is not possible how do I make more then one notification so it runs one next to the other effectively making the app notification bigger.. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Is there any logical way to make a notification bigger / Make more then one.
JB added support for larger notifications. You can not force them to display larger, however, they will change in size for various reasons as appropriate. It sounds to me like what you are trying to do may not be what notifications are intended for. On Sun, Jul 22, 2012 at 1:41 PM, Cythes cytheshic...@gmail.com wrote: I'm trying to work on an app that runs out of a notification. Right now I am trying to make the notification bigger so it has more prevalence on the screen. And if that is not possible how do I make more then one notification so it runs one next to the other effectively making the app notification bigger.. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Documentation for adb shell getevent / sendevent
No, this is fairly device-dependent. getevent prints a summary of all the devices so you know what those are. The data generated for a device are generally the Linux kernel's event protocol, so you can look there for further help, but there is no guarantee that a particular device will be following those conventions. On Sun, Jul 22, 2012 at 1:55 AM, matt matthias.gru...@gmail.com wrote: hello, is there any documentation on the format of the getevent and sendevent shell commands? specifically the ones for touchevents. or is this device-dependent? it is a bit hard to guess what those ids are doing. thanks! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Activity always starting in 2 instances on ZTE Skate
I have two activities: a Preload activity and the main activity. My preload activity basically just spawns the main activity and then exits. My problem appears only on ZTE Skate (all other devices work fine). When I start my application by tapping its icon, the logcat output of my application is duplicated. Each log line appears twice, but at different times. I read some topics on stackoverflow that assume it's only a logcat issue (and adb should be reset to solve it), but later, my main activity dies with a bitmap size exceeds VM_BUDGET error. This is probably because both activities are runnning at the same time, so memory gets low when it loads bitmaps. The VM_BUDGET error does not appear on any other devices, including HTC Desire, Samsung Galaxy Mini etc. As a trial error, I tried the FLAG_ACTIVITY_CLEAR_TOP flag for the Intent, but no success. I haven't tried the singleTask launch mode yet, but actually I don't think the behavior is correct anyway on ZTE Skate. Therefore, I would like to understand why double spawning happens. (The other possibility is that I've two independent errors: double logcat output anomaly, plus VM_BUDGET error. The problem is, I get no VM_BUDGET errors on other devices at all, and e.g. HTC Desire is not a better device than ZTE Skate so I doubt it's a memory leak or similar issue.) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] onLayout is getting called multiple times during orientation
Hi all, I am getting onLayout called twice during orientation with different dimension values, is this an expected behavior ? -Agus. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] HtcLinkifyDispatcher.apk messing default app association
You can't modify it: and if you could HTC would be upset and change the firmware again to not let you... The patent thing sucks, no doubt, but there's nothing you can do but live with it or tell your users to blame Apple ... On Jul 22, 2012 10:48 AM, b0b pujos.mich...@gmail.com wrote: Thanks to the geniuses of this world, on some HTC phones (in the US only it seems), HTC has modified the default Intent Chooser to comply with some Apple absurd patents: http://www.theverge.com/2012/5/16/3024889/htc-one-x-evo-4g-lte-custom-android-build-apple-patent-linkify The consequence is that the user is presented with a custom Intent Chooser without the Use by default for this action check box. It also has some side effect: I'm using this code to get the default video player app if any: Intent intent = new Intent(Intent.ACTION_VIEW); intent.setDataAndType(Uri.parse(http://1.2.3.4/video.avi;), video/*); ResolveInfo resolveInfo = context.getPackageManager().resolveActivity(intent, PackageManager.MATCH_DEFAULT_ONLY); It works fine on all device but when that HtcLinkifyDispatcher.apk is installed, above resolveInfo will point to HtcLinkifyDispatcher itself which when launched, display the custom HTC intent chooser. This makes knowing the default app for video impossible to know as this damn thing hooked the system. As anyone dealt with this and found a workaround, or should I say to my users to live with it (always seeing the HTC app chooser when clicking a video in that case), or to root their phone to uninstall the damn APK ? I would test this myself but the APK seems to be only installable on HTC devices as it uses android:sharedUserId=android.uid.system Many thanks to Apple and HTC for this mess :p. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] onLayout is getting called multiple times during orientation
It can be, for example a layout manager may do this on its children. On Sun, Jul 22, 2012 at 5:47 PM, Agus agus.sant...@gmail.com wrote: Hi all, I am getting onLayout called twice during orientation with different dimension values, is this an expected behavior ? -Agus. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] (WTA)android 3.0 emulator built in gallery won't work.
i want to ask about built in gallery android 3.0. i make an intent to access it. this is my code : Intent intent = new Intent(Intent.ACTION_PICK,android.provider.MediaStore.Images.Media.EXTERNAL_CONTENT_URI); intent.setType(image/*); intent.setAction(Intent.ACTION_GET_CONTENT); startActivityForResult(intent, GET_IMAGE_SD_REQUEST); when i try on android 2.2 and 2.3 it working well, but when i try on android 3.0. it shows an error. and when i try to open android gallery manualy, it shows an error and forcing to close. is it a bug or something? someone help me please. thanks. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Kostya, is there any chance of sending me your small test? I'm hoping I can
try compare that with my code and make some progress, or at least help me
get together a small example for Dianne. If you do, could you send it to
andrew at rageconsulting dot com
Andrew
On Sunday, July 22, 2012 1:05:48 PM UTC+1, Kostya Vasilyev wrote:
2012/7/22 Andy dev andrewpmo...@gmail.com
Kostya, after tracking mine down more, it seems to be exactly the same.
It doesn't actually get killed until I get a broadcast. I'm not sending
them I'm receiving them from things like the SMS service, the battery level
the screen state etc, but any of those I've registered for cause the issue.
Well, my code sends broadcasts between the app's components, which is very
nearly synchronous, so I could not tell the difference.
I actually created and ran a small test, and can confirm this
behavior with 100% certainty.
-- K
I'm not exactly sure which transaction is even going on at this point.
Dianne, thanks for your reply I really appriciate it, especially given
your position in the android team. I'll try and work on cutting down my
code into a manageable example as it's several hundred classes at the
moment (it's the app Light Flow in the market). I do hold quite a bit in
static variables, does any of that make a difference in this situation?
On Sunday, July 22, 2012 11:14:16 AM UTC+1, Kostya Vasilyev wrote:
I'm also seeing my application get killed even while it has a foreground
service.
It appears to happen on the next sendBroadcast() - which is an
implementation detail of how some of my components interact, and has
nothing to do with the service's startForeground() state. The service
remains in foreground state at this point (and is supposed to last about a
dozen seconds more).
Instead, the process gets killed, and I'm also seeing an
android.os.**TransactionTooLargeException
in the logcat.
The exception looks to me like an unfortunate and unexpected side effect
of the process getting killed.
The broadcast in question is sent farly often, its data payload is only
a few dozen bytes, and so it never triggers this exception under normal
circumstances.
-- K
2012/7/22 Dianne Hackborn hack...@android.com
TransactionTooLarge means that the data being sent through the IPC call
is too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be
killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that
is if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.comwrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the
broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in
the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION
!!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to ComponentInfo{com.example.**android.app/com.example.**
android.app.receiver.**SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309): android.os.**
TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
[android-developers] Re: Serial BluetoothSTREAM without packaging
Hey, thank you for your reply,
cause i have to send only a few bytes beach packed... for simplification
like a ping or a deathmans switch. But for this data ists absolutly
nessesary to put them in an special given frame.
Am Freitag, 20. Juli 2012 19:52:06 UTC+2 schrieb bob:
Why not append your data into one big buffer and do one send of the big
buffer?
On Friday, July 20, 2012 6:51:01 AM UTC-5, superpsycho wrote:
Hey devs,
i would like to know if it´s possible to sent data over bluetooth without
interruption.
With the source below i got fragmented packages on the reciverside.
CODE:
OutputStream outStream = serialSocket.getOutputStream();
Log.d(TAG,outStream created success!);
byte[] buffer ={0x33, 0x34, 0x42, 0x33, 0x34, 0x42, 0x34, 0x42, 0x33,
0x34, 0x42};
outStream.write(buffer);
byte[] buffer ={0x33, 0x34, 0x42, 0x33, 0x34, 0x42, 0x34, 0x42, 0x33,
0x34, 0x42};
outStream.write(buffer);
byte[] buffer ={0x33, 0x34, 0x42, 0x33, 0x34, 0x42, 0x34, 0x42, 0x33,
0x34, 0x42};
outStream.write(buffer);
RESULT:
Connectionindicator: 0x33, 0x34, 0x42, 0x33, 0x34, 0x42, 0x34, 0x42,
0x33, 0x34, 0x42
Connectionindicator: 0x33, 0x34, 0x42, 0x33, 0x34, 0x42, 0x34, 0x42,
0x33, 0x34, 0x42
Connectionindicator: 0x33, 0x34, 0x42, 0x33, 0x34, 0x42, 0x34, 0x42,
0x33, 0x34, 0x42
WANTED RESULT:
NO_Connetionindicator: 0x33, 0x34, 0x42, 0x33, 0x34, 0x42, 0x34, 0x42,
0x33, 0x34, 0x42, 0x33, 0x34, 0x42, 0x33, 0x34, 0x42, 0x34, 0x42, 0x33,
0x34, 0x42, 0x33, 0x34, 0x42, 0x33, 0x34, 0x42, 0x34, 0x42, 0x33, 0x34,
0x42 and so on and so on...
My BT-chip on the reciverside supports a streammode where all the
redudant AT-Commands become supressed but only if booth sides support the
type of sending. The application for this provided service is a connection
via bluetooth nobody is able to
differentiatehttp://www.dict.cc/englisch-deutsch/differentiate.htmlfrom an
real cable.
My usecase is an selfmade protocoll i need to speak with the ARM
connected to the reciverchip.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Failed to find an AVD compatible with target 'Android 2.2'
Hi all, When i run my application using eclipse in Sony Experia(android version 4.0.3),it shows 'Failed to find an AVD compatible with target android 2.2' in the log.This application is running in Galaxy S3. Thanks, vijay.k -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: HTTP Post works only on port 80 when on mobile network (Galaxy Nexus)
Can someone please confirm me, that is a problem posting data on a server on non-80 port, using mobile data, on Galaxy Nexus or probably some other ICS device? If it works for you, how do you do it? Thanks. On Sunday, July 15, 2012 12:10:02 PM UTC+2, Zoran Smilevski wrote: Hello! I have a problem with posting data when using mobile data network on a port different than 80. This happens only on Galaxy Nexus. I have also reported a bug with detailed description ( http://code.google.com/p/android/issues/detail?id=34769). There is also a demo app so anyone can test this. I was also trying to send a post using a socket, like it's described on http://www.exampledepot.com/egs/java.net/PostSocket.html. In this case everything works fine. I hope that someone will see this and tell me what the hell am I doing wrong or confirm that bug :) -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] search +button in expandible list
CompaniesActivity extends ExpandableListActivity {
/** Called when the activity is first created. */
EditText edit;
Button search;
String[] text = { GSK, sanfoi, Elilly, Abbott, Novartios };
int textlength = 0;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
setListAdapter(new ExampleAdapter(this));
edit=(EditText)findViewById(R.id.edtxt);
// Search functionality
final ArrayListString text_sort = new ArrayListString();
search = (Button) findViewById(R.id.btn);
edit = (EditText) findViewById(R.id.edtxt);
ExpandableListView listview = (ExpandableListView) findViewById(R.id.list);
listview.setAdapter(new MyCustomAdapter(text));
search.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
textlength = edit.getText().length();
text_sort.clear();
for (int i = 0; i text.length; i++) {
if (textlength = text[i].length()) {
if (edit.getText().toString().equalsIgnoreCase(
(String) text[i].subSequence(0, textlength))) {
text_sort.add(text[i]);
}
}
}
setListAdapter((ExpandableListAdapter) new MyCustomAdapter(text_sort,
null));
}
});
}
class MyCustomAdapter extends BaseAdapter {
String[] data_text;
MyCustomAdapter() {
}
MyCustomAdapter(String[] text) {
data_text = text;
}
MyCustomAdapter(ArrayListString text, ArrayListInteger image) {
data_text = new String[text.size()];
for (int i = 0; i text.size(); i++) {
data_text[i] = text.get(i);
}
}
public int getCount() {
return data_text.length;
}
public String getItem(int position) {
return null;
}
public long getItemId(int position) {
return position;
}
}
this my layout :
?xml version=1.0 encoding=utf-8?
LinearLayout xmlns:android=http://schemas.android.com/apk/res/android;
android:orientation=vertical
android:layout_width=fill_parent
android:layout_height=fill_parent
android:background=@drawable/background
LinearLayout
android:id=@+id/linearLayout1
android:layout_width=fill_parent
android:layout_height=wrap_content
EditText
android:id=@+id/edtxt
android:layout_width=250dp
android:layout_height=45dp
android:inputType=none /
Button
android:id=@+id/btn
android:layout_width=65dp
android:layout_height=50dp
android:layout_marginBottom=1dp
android:layout_marginRight=1dp
android:layout_marginTop=1dp
android:text=Search
android:textSize=13sp /
/LinearLayout
ExpandableListView android:id=@android:id/list
android:layout_width=fill_parent
android:layout_height=fill_parent
android:paddingRight=20px
android:textSize=40px
/
/LinearLayout
can you please help any one this .,
i used edittext and search button in layout file and i search is not
happening how to reslove this issues
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
