[android-developers] SurfaceView crash in 4.3 - SurfaceHolder.unlockCanvasAndPost(canvas) IllegalArgumentException
Hi Group, There is currently an open issue tracker that reports an apparent bug in Android 4.3 which results in application crashes when SurfaceView is used. The tracker is here: http://code.google.com/p/android/issues/detail?id=58385 I've found that this situation causes my own application to crash (with Logcat showing the traces as documented in that tracker) on both devices I have access to that have been upgraded to Android 4.3 (a Nexus 7 and Nexus 4). It's clear that this is causing a headache to other developers as well, and surely it's going to be a larger problem as 4.3 is rolled out to all current Nexus devices, potentially affecting hundreds of applications that use SurfaceView. In my experience it seems random as to whether this exception occurs, and the probability seems to differ between applications. With one obviously SurfaceView-based app I tried (not my own), I had to rotate the device several dozen times to make the crash happen; with my own application it occurs 50% of the time on start-up of the SurfaceView. I'd hope that Google somehow provide a fix for this, but until that happens has anyone got any further insight or knowledge on how it might be mitigated? In the meantime I'm considering implementing a splash warning for 4.3 users along with perhaps a low-FPS View-based renderer as a fall-back from SurfaceView, so at least 4.3 users can use the application, albeit with poor user experience. Trev -- 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 unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[android-developers] Re: How can I get notified when the server has closed the TCP connection
What I have learned from my experience with TCP/IP is that connection / session control should always be achieved over the application protocol. To put it another way, as others have said already, graceful disconnection should be signalled using some specific means over your application protocol, at which point both sides know the exchange is finished and can close their ends of the socket simultaneously. A graceful disconnection should not be done by closing the socket at one end and then having the opposite end try to detect the closure. Some APIs like Java sockets don't seem to reliably inform you that the other end has closed until you try to write to the stream and get an exception. It's worth looking at how popular existing protocols over TCP/IP do this. HTTP is a great example. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[android-developers] Re: ViewFlipper class does not support SurfaceView like it should
Hi all, I've followed this thread with interest because I had intended to do something very similar; that is, have multiple pages that the user can swipe between (using a ViewFlipper) where some screens may be composed of a mixture of SurfaceViews and normal Views. To be clear, I don't wish to have SurfaceViews at or greater than screen size; rather, just some of my smaller screen components are made using SurfaceViews. Now, after working with SurfaceViews quite a bit, I'm quite happy in my understanding of why a SurfaceView is special, and how it is effectively removed from the normal View hierarchy. (In simplistic terms, I think of the SurfaceView as a means of handing control of a specified screen video memory area directly to the application, with the benefit of separately-threaded update performance, but obvious cost of interaction with normal View hierarchy). Having read this discussion, what I'm not quite clear about in my head at the moment is exactly which combinations of ViewGroup container and SurfaceView are either just 'bad' (and why) or simply won't work. For example, for my application where the user can swipe between multiple pages of a dashboard in order to view various dashboard components (where some are made using SurfaceViews) I considered using a HorizontalScrollView. However, doing some Googling I did come across Dianne advising "you shouldn't put a SurfaceView inside of a ScrollView or other such container" (however, I note that was in response to someone wanting to scroll a SurfaceView that occupied more than the screen area). I did, however, find that a test Activity using a HorizontalScrollView with several SurfaceViews contained within did seem to work fine; I was able to scroll left and right to be able to view all SurfaceViews and they continued to redraw okay. So, to round up the question (and apologies for hijacking the OP's original thread slightly): in order to implement a layout that's larger than the screen size where the user scrolls back and forth to see all content, and where some of the screen components to be scrolled are implemented using SurfaceViews, what View mechanisms and / or ViewGroup derivatives should one *not* be using? Apologies in advance if I've misquoted or got the wrong end of the stick at all. Many thanks, Trev On Sep 21, 7:13 pm, MobileVisuals wrote: > I got this to work no without the ViewFlipper. I think that there > should be information in the ViewFlipper class > that it doesn't support SurfaceView. I lost many hours of work because > of this. The reason I used the ViewFlipper class for SurfaceView was > that other threads on this forum recommended it, like this one: > > https://groups.google.com/group/android-developers/browse_thread/thre... > > So there are other developers who have made the same mistake. > > On Sep 20, 3:51 pm, MobileVisuals wrote: > > > How can I then switch between a view with 2d rendering and a view with > > 3d rendering? > > > I suppose I have to use GLSurfaceView for 3d rendering with OpenGL? > > > On Sep 20, 3:00 pm, Jens wrote: > > > > That would be the gist of what both Dianne & Romain Guy said yes. > > > > On Sep 20, 2:13 pm, MobileVisuals wrote: > > > > > GLSurfaceView extends SurfaceView. Does that mean that it is not > > > > possible to animate GLSurfaceView with a viewflipper? > > > > > On Sep 20, 9:54 am, Romain Guy wrote: > > > > > > You can animate another view on top of a SurfaceView, you just cannot > > > > > animate the SurfaceView itself. > > > > > > On Tue, Sep 20, 2011 at 12:51 AM, MobileVisuals > > > > > wrote: > > > > > > > Thanks for the info, I have spent many hours investigating this > > > > > > issue > > > > > > and now I finally know what the problem is. My app has a standard 2d > > > > > > menu. It is possible to view different 3d visual effects from the > > > > > > menu. The 3d visual effects are rendered in a GLSurfaceView. That > > > > > > class extends SurfaceView. > > > > > > > You say that SurfaceView should not be used in a ViewFlipper. How > > > > > > can > > > > > > I implement my app if I can't use SurfaceView or GLSurfaceView? > > > > > > Which > > > > > > type of view should I use for the ViewFlipper? Can I render the 3d > > > > > > visual effects with other views than GLSurfaceView? > > > > > > > Or shouldn't I use a ViewFlipper at all? If not, how can I then > > > > > > switch > > > > > > between the 2d and the 3d rendering? > > > > > > > On Sep 19, 7:37 pm, Dianne Hackborn wrote: > > > > > > > Don't use a SurfaceView in a ViewFlipper. > > > > > > > > Nor a ListView. > > > > > > > > SurfaceView is a *very* *special* view. As it says, what it does > > > > > > > is > > > > > > create > > > > > > > a completely separate surface (a.k.a. window) that is associated > > > > > > > with > > > > > > your > > > > > > > main window. This window is positioned behind the main window, > > > > > > > and a > > > > > > hole > > > > > > > punched through your main window to see
[android-developers] Re: Exists a svg library that works fine for android?
Do you have an example of a complex SVG file that you need to render that you can email to me please? I have written my own SVG library and I am curious to see if it will render your file. Trev On Sep 14, 12:07 pm, saex wrote: > That library works only with very simple svg files, it fails with > complex svg files (text, paths, etc..) > > And my app should be used with lower versions of Android, not 3.0. > > Doesn't exists a powerfull library for SVG for android? :S > > On 14 sep, 12:51, Mark Murphy wrote: > > > > > AFAIK, this is the best there is: > > >http://code.google.com/p/svg-android/ > > > Also, reportedly WebView supports SVG on Android 3.0 and higher. > > > On Wed, Sep 14, 2011 at 5:40 AM, saex wrote: > > > i need to open svg files and show them on Android phones. > > > > I tryed a lot of librarys from stackoverflow and google, and none of > > > them works fine, all of them fails with complex svg files (using > > > paths, text, etc...) > > > > There is not a working svg library for 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 > > > -- > > Mark Murphy (a Commons > > Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > Android App Developer Books:http://commonsware.com/books -- 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: Cheap Bluetooth devices sought
Hello, I have recently bought a number of those cheap modules (which cost about 5GBP each) from China that are all over eBay at the moment. They're usually advertised as a 'Bluetooth to serial TTL module' or similar. It's a small PCB that contains a CSR Bluecore device and memory, integrated PCB foil antenna, and a four-pin header for 0V, 5V, Rx and Tx connections. Here's one example: http://www.ebay.co.uk/itm/Serial-Bluetooth-RF-Transceiver-Module-rs232-TTL-/280696760008?pt=UK_Computing_Networking_SM&hash=item415ad4a6c8 I'm quite fond of them having the CSR device because I've worked with and modified CSR firmware in the past for a previous project. These modules all come with SPP (Serial Port Profile) firmware, but one thing to keep in mind is that despite many, many Chinese suppliers on eBay selling the same PCB, many come with different firmware. I've successfully used my Android app with modules I have with one particular firmware, but another firmware that came on the same PCB from an alternative supplier can't be connected to. However, CSR's Blueflash utility and a simple homebuilt parallel port / SPI interface means you could swap firmware between modules. Trev On Aug 8, 6:55 pm, cellurl wrote: > Anyone know of a $10 bluetooth device that I can buy in low > quantities? For example something a phone could turn on/off? > > I need 2 remote switches. Just on and off. > > There are hacking options, but that seems last resort. > A: Butchering a BT-headset and sending/decoding DTMF. > > B: Butchering RemoteControlBluetooth cars... > > But I am hoping someone can point me to a super cheap BT slave device > or point me to a more appropriate group. > > Thanks for any leads! > cellurl -- 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: Extending RelativeLayout, overriding dispatchDraw() to create a zoomable ViewGroup - problem with child view clipping
Thanks Romain. I'm certainly well aware that the problem is my code
and not in ViewGroup, and that one of the individual child Views will
certainly not receive a scaled Canvas if it is invalidated. I think
the reason for my confusion here -- and this will be down to my lack
of knowledge about what goes on behind the scenes between invalidate()
being called and the View's onDraw() subsequently being invoked -- is
that I thought that the invalidation of a child View was somehow
always cascaded down from the ViewGroup. My reason for thinking this
is that, when a child view has invalidate() called, I can see that the
ViewGroups's dispatchDraw() gets invoked first, prior to the child
View's onDraw().
Furthermore, when I zoom in, I can see that the parts of the child
Views that are being redrawn on the screen are always being drawn to
the correct scale; it's just as though the clipping isn't being
scaled. This was a further reason why I've perhaps mistakenly thought
that the child View was aways being provided a scaled Canvas from my
ViewGroup to draw on each time it was called to onDraw() following
invalidate() being called on that child.
Perhaps I'll just have to have my child Views all reference the parent
View's zoom scale factor variable and individually scale themselves,
perhaps having the ViewGroup and child Views all implementing an
Interface that provides methods to delegate down the scale factor. No
big deal in doing that; I was perhaps just trying to be too clever in
my first approach, certainly too ambitious considering my Java /
Android inexperience.
Thanks,
Trev
On Jun 17, 2:22 am, Romain Guy wrote:
> You are scaling the Canvas and not the View itself, the children have
> absolutely no knowledge that you are doing so. When invalidate() is
> invoked on the children, how could they know that you intend to scale
> them? They can't (unless you use Android 3.0+ and the new scale()
> method.) The problem is not in ViewGroup, it's in your code: you need
> to take the scale factor into account when you invalidate the children
> (call invalidate(left, top, right, bottom) on the parent instead.)
>
>
>
> On Thu, Jun 16, 2011 at 6:08 PM, Trev16v wrote:
> > Hello,
>
> > In my application I need to have a floor plan diagram which can be
> > panned and zoomed. On this diagram are to be a series of small
> > markers. Those little marker Views need to have invalidate() called
> > frequently on them because the graphics drawn to their Canvas is being
> > animated. I have been trying to implement an extended RelativeLayout,
> > which I call ZoomableRelativeLayout, which would enable me to perform
> > simultaneous zooming on all child Views of the ViewGroup. That is, the
> > large floor plan graphic and its markers, all of which are child
> > Views, will simultaneously zoom and pan together.
>
> > In my ZoomableRelativeLayout, I have attempted to perform scaling
> > (zooming) to the Canvas within the overridden dispatchDraw() method,
> > like this:
>
> > protected void dispatchDraw(Canvas canvas){
> > canvas.save(Canvas.MATRIX_SAVE_FLAG);
> > canvas.scale(mScaleFactor, mScaleFactor);
> > super.dispatchDraw(canvas);
> > canvas.restore();
> > }
>
> > The mScaleFactor is manipulated by a ScaleListener in the same class.
>
> > It does actually work. I can pinch to zoom the ZoomableRelativeLayout,
> > and all of the views held within properly rescale together.
>
> > Except there's a problem. When the scale is 1, the animated child
> > views are seen to redraw periodically perfectly fine. However, when
> > the scale is other than 1, (e.g. when zooming in), those animated
> > child views are only seen to update in a small clipped portion of
> > their area - or not at all - depending on the zoom scale.
>
> > The problem appears to be that the 'invalid area', or clipping area,
> > for each view seems to remain as if no scaling had been applied to the
> > Canvas in dispatchDraw(). If for example my ZoomableRelativeLayout
> > were to contain a single, simple View that draws a filled rectangle,
> > and it animated by flipping its colour every second via invalidate()
> > and onDraw(), then at a zoom of 1 it'll appear as it should do.
> > However, begin to gradually zoom in, the size of the square expands
> > and moves away from its original position. The only part of the square
> > that animates is whatever part of it still sits underneath that
> > square's original 'area'.
>
> > I have tried looking over the source for ViewGroup to see if I could
> > spot any solution to this problem, and the best thing I could spot was
> > to
[android-developers] Extending RelativeLayout, overriding dispatchDraw() to create a zoomable ViewGroup - problem with child view clipping
Hello,
In my application I need to have a floor plan diagram which can be
panned and zoomed. On this diagram are to be a series of small
markers. Those little marker Views need to have invalidate() called
frequently on them because the graphics drawn to their Canvas is being
animated. I have been trying to implement an extended RelativeLayout,
which I call ZoomableRelativeLayout, which would enable me to perform
simultaneous zooming on all child Views of the ViewGroup. That is, the
large floor plan graphic and its markers, all of which are child
Views, will simultaneously zoom and pan together.
In my ZoomableRelativeLayout, I have attempted to perform scaling
(zooming) to the Canvas within the overridden dispatchDraw() method,
like this:
protected void dispatchDraw(Canvas canvas){
canvas.save(Canvas.MATRIX_SAVE_FLAG);
canvas.scale(mScaleFactor, mScaleFactor);
super.dispatchDraw(canvas);
canvas.restore();
}
The mScaleFactor is manipulated by a ScaleListener in the same class.
It does actually work. I can pinch to zoom the ZoomableRelativeLayout,
and all of the views held within properly rescale together.
Except there's a problem. When the scale is 1, the animated child
views are seen to redraw periodically perfectly fine. However, when
the scale is other than 1, (e.g. when zooming in), those animated
child views are only seen to update in a small clipped portion of
their area - or not at all - depending on the zoom scale.
The problem appears to be that the 'invalid area', or clipping area,
for each view seems to remain as if no scaling had been applied to the
Canvas in dispatchDraw(). If for example my ZoomableRelativeLayout
were to contain a single, simple View that draws a filled rectangle,
and it animated by flipping its colour every second via invalidate()
and onDraw(), then at a zoom of 1 it'll appear as it should do.
However, begin to gradually zoom in, the size of the square expands
and moves away from its original position. The only part of the square
that animates is whatever part of it still sits underneath that
square's original 'area'.
I have tried looking over the source for ViewGroup to see if I could
spot any solution to this problem, and the best thing I could spot was
to clear the FLAG_CLIP_CHILDREN via setClipChildren(false). Inspection
of the source of ViewGroup seemed to suggest that clipping would no
longer be applied, but unfortunately this change has had no visible
effect and the problem persists.
Probably worth mentioning is the fact that whenever I am actually
zooming in and out, or when I'm panning the ViewGroup, all of the
marker child View graphics *do* periodically redraw properly. So, for
example, when I'm panning the floor plan around or zooming, my markers
are seen to properly animate. Now when I'm zooming, invalidate() is
being called on the ViewGroup itself, obviously; and presumably calls
to scrollBy() to perform my panning lead to an invalidate() on the
ViewGroup too. It seems that invalidation of the ViewGroup leads to an
entire redraw which draws the child views with the clipping bounds
scaled as well, so that the child Views' graphics are properly updated
on the display. Calling invalidate() on the individual child Views
still causes a call to the ViewGroup's dispatchDraw(), but for some
reason the clipping area is then 'unscaled'.
Am I on a bit of a loser with my zoomable ViewGroup strategy?
Thanks,
Trev
--
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: SPP bluetooth
Hello,
I've possibly just experienced success with SPP on the HTC Desire
here, and I wondered if it's worth reporting.
Bear with me here, but I am very new to phone application and Android
development (I only just started this weekend) and even Java is new to
me (though I am used to using other languages). This is my very first
post to this mailing list.
I have got a HTC Desire and I wish to create an application that
communicates with a piece of hardware that I have constructed myself,
which incorporates a CSR Bluecore-based Bluetooth module. The
objective is to create an app that can control the hardware over
Bluetooth SPP. I am doing my testing with a Bluetooth module that sits
on a development PCB, and I'm communicating with its UART lines via
HyperTerminal (the module can be controlled using modem-like AT
commands, so I can tell it to make a connection using ATD,
and that kind of thing). So the little goal for this weekend was to
exchange characters from Hyperterminal, via the RS232 connection and
the Bluetooth module, to my Desire.
I set up and ran BluetoothChat (API 7, Android 2.1-update1) from
Eclipse using my Desire as the target. I found I could pair
BluetoothChat with my module, but attempting to connect would fail
whether I tried to initiate the connection from the Desire or from the
module itself. I did a quick bit of Googling and my heart plummeted
when I read these posts that I found about SPP not working.
Anyway, I changed the UUID to the value that DonFrench recommended, so
that I now have the line:
private static final UUID MY_UUID =
UUID.fromString("1101--1000-8000-00805F9B34FB");
Now, I'm able to connect, and I'm happily exchanging characters
between the Chat application and Hyperterminal. The only issue I have
seen so far is that sometimes the connection dies when I go away from
it for a few minutes - perhaps this is due to a timeout event;
hopefully I'll understand why as I learn more.
I only have a limited understanding of UUIDs. I know that SPP is 1101.
I also did a project a few years ago that involved making a device
that communicated with a vast array of mobile phones; I found that
99.9% of phones wouldn't accept connections to 1101 and I had to make
my Bluetooth module specify a UUID of 1103 (DUN, if I remember right).
Most phones would accept this, allow me to connect, and let me
communicate with the phone (and access its SMS, contacts, etc.) using
serial AT commands as normal. Anyway, I digress. The point is that I
understand why the "1101" is there in DonFrench's UUID string; I
recognise that as SPP. What I don't understand is why the original
example code contained a UUID that's nothing like 1101. Perhaps I need
to have a good read of RFC4122...
Anyway, if there's any comments anyone has about what I've reported
here, or if there's any more information I can let you guys know (e.g.
any firmware numbers from my phone, etc.) please shout.
Last but not least, massive thanks to DonFrench.
Trev
On May 29, 1:03 am, DonFrench wrote:
> I notice that the UUID you are using differs slightly from the one in
> the final line of the log, where it says onUuidChanged. Could you be
> using the wrong UUID?
>
> On May 28, 2:10 pm, Robert Armstrong
> wrote:
>
> > I managed to transfer a file from the host PC to theHTCDesireusing
> > Bluetooth - see Word document supplied
> > here:-http://forum.vodafone.co.uk/topic/58936-htc-desire-unable-to-send-fil...
>
> > I have also tried the SDK supplied BluetoothChat example App.
>
> > But with UUI changed to:-
> > private static final UUID MY_UUID =
> > UUID.fromString("1124--1000-8000-00805F9B34FB"); // HID class
>
> > And get a similar failure to last posting. When I click on "Menu->Connect a
> > Device", after a short delay, I hit a breakpoint at:-
>
> > ...
> > mmSocket.connect();
> > } catch (IOException e) {
> > connectionFailed(); ***
> > breakpoint hit on this line
> > ...
>
> > The logCat trace shows:-
> > 05-28 21:59:00.750: ERROR/BluetoothEventLoop.cpp(75): pollData[0] is
> > revented, check next one
> > 05-28 21:59:00.760: ERROR/BluetoothService.cpp(75):
> > stopDiscoveryNative: D-Bus error in StopDiscovery:
> > org.bluez.Error.Failed (Invalid discovery session)
> > 05-28 21:59:00.770: DEBUG/BluetoothChat(1385): onActivityResult -1
> > 05-28 21:59:00.780: DEBUG/BluetoothChatService(1385): connect to:
> > 00:1B:FB:CE:61:EF
> > 05-28 21:59:00.780: INFO/BLZ20_WRAPPER(1385): blz20_wrp_socket: fam
> > 31, type 1, prot BTPROTO_RFCOMM
> > 05-28 21:59:00.780: DEBUG/BTL_IFC_WRP(1385): wrp_wsock_create: BTS
> > 05-28 21:59:00.780: DEBUG/BTL_IFC_WRP(1385): wrp_alloc_new_sock:
> > wrp_alloc_new_sock sub 15
> > 05-28 21:59:00.780: DEBUG/BTL_IFC_WRP(1385): wrp_wsock_create: 49
> > 05-28 21:59:00.780: DEBUG/BLZ20_WRAPPER(1385): btsk_alloc_add: success
> > 05-28 21:59:00.780: DEBUG/BLZ20_WRAPPER(1385): btsk_dump_list: fd
> > (35:35), bta 0, rc 1, wf
