Indeed a bit of misapplied coding, but there are remedies.
If you run a memory profiler you'll likely see tons of garbage created via the ArrayList copy; I assume you are using "clone()". That constant churning of not just new object creation, but GC reclaiming the orphaned copies after each render / frame cycle will bring Android to its knees. Not that this would be an OK thing to do on the desktop / J2SE either, but performance on Android will suffer greatly. Run ddms and you'll see a ton of GC messages quite likely. For a Java profiler I really like YourKit. It's a commercial product, but by far has been my profiler of choice for the last 6 years or so and has helped me greatly where other profilers before it failed. You can dump hprof files from the 2nd button from the left in ddms. You need to run hprof converter on the file before the standard Java profilers can open it. http://developer.android.com/guide/deve ... -conv.html
If you are using Eclipse or want to use a free profiler I've read good things, but haven't used MAT:http://www.eclipse.org/mat/
In addition another little somewhat innocous, but a major problem with the stock Java collections is that the process of using an Iterator whether in a foreach loop or obtained by creating one through "iterator()" or the like is creating a new object. Everytime an iterator is created in a tight loop "Duke" devours a kitten (and your performance).
With TyphonRT I created a extended set of collection implementations that are backward compatible with the standard collections, but feature resetable and recyclable iterators. There are caveats of course such that you need to specify the number of recycled iterators cached if the algorithm the collection is applied to traverses it more than once otherwise you steal actively used iterators; err and I removed concurrent modification exceptions. However it's real easy to switch back and forth between "legacy" Java collections and my versions. These extensions though make it possible to use collections without object creation overhead.
Since you are doing copies and mention this is in relation to a main loop with a separate thread than the rendering I recommend you stick with a single threaded game loop. IE move your objects, render, repeat sequentially from one thread. I have yet to even fully crack for game development a proper way to handle multiple threads for time based callbacks / clocking. Sure one can use a ThreadPoolExecutor and such for non-deterministic tasks. However, a game rendering loop is often deterministic. Even if a proper sharing of data is possible between a rendering thread and say game logic thread the high FPS from the rendering thread is fake because you'll be rendering duplicate frames if the data isn't updated between frames. So definitely do yourself a favor and switch to a single threaded game loop until the need arises for more (it won't for a while). If it's fine for id tech / Carmack for all these years it'll do nicely for you.. Check the first paragraph here I suppose to confirm... http://en.wikipedia.org/wiki/Id_Tech_5
Now multi-core / parallelism is the way to the future, but that doesn't mean it's good to start there. Again not a 2 day problem or easy to solve. Copying data is not feasible nor is message passing per se. The latter works great for non-deterministic open ended tasks - a game loop is not that though.
Switching to a single threaded game loop will eliminate your Arraylist copy and synchronization code which BTW you only want to synchronize something that is absolutely necessary to do so. In TyphonRT This is done in only 2 areas. To get by the iterator issue use .get(<index>) method of Arraylist or simply allocate a straight up array.
I don't exactly recommend storing position state for all objects in an array list, but it'll work for a quick hack to get stuff rendered. Having gone down the OOP hell hole for entity systems (main anti-pattern to watch for is the blob anti-pattern) I've fully converted to a component oriented architecture and entity system and it's fantastic. That is what Adam Martin's article is about that I linked to previously and the closest written description though I've implemented and extended things differently.
Heh heh.. Again I recommend the Beginning Android Games book. It'll be the best $25 you can spend to get ahead from where you are at now:http://www.amazon.com/Beginning-Android ... 1430230428