OVMS Developers, Tim, Chris, Cam, Sonny, [ Tim, Chris, Cam, Sonny - I've included you here because you've offered to help out with this in the past ] I went we option [2] (start again with the code as it was a few months ago, and try to take it forward from there), and finally I'm glad to report some real progress. The OVMS Android project on github is here: https://github.com/markwj/Open-Vehicle-Android All the work that I, and others, have done to date is up-to-date there. For reference, you can also find the OVMS iOS project on github here: https://github.com/markwj/Open-Vehicle-iOS In the main directory of the Android project, you'll see two sub-folders: OpenVehicleApp is the new Android App - the project can be compiled directly there, or imported into Eclipse. DecompileWork - various decompiles of the old v1 and v3 code. /apk-v1: A decompile (to smali) using apktool of the old v1 code (for reference) /apk-v3: A decompile (to smali) using apktool of the lost v3 code - the resources here are 100% perfect /decompile-v1: A decompile to java of the old v1 code (for reference) /decompile-v3: A decompile to java of the lost v3 code - resources are useless, and the code here is pretty messed up but useful for reference /source-apk: The two APKs the decompile worked from /tmp: A working bit-bucket /OpenVehicleApp: A failed attempt to take the v3 code (from decompile-v3) and resources (from apk-v3) and get it working - the code is just too messy, but perhaps useful for reference The root OpenVehicleApp folder is where we should be working from, going forward. The DecompileWork is just for bringing features over from the old lost code, and for reference. After some late nights and weekends on this, I've managed to rebuild the OpenVehicleApp project taking the old v1 code (for which we have source code), bringing in the newer v3 resources (from DecompileWork/apk-v3), and then bringing in the latest artwork and design from the iOS project. I've got the car data model re-built to be more logical (although I know Tim has been working on something similar and long-term it would be good to switch to Tim's version). The project now builds and runs (at least on the emulator). Changes and enhancements are now much easier to make, and I'm blazing my way through the list of things to do (literally). The goal of what I'm trying to do is to get the Android App working to approximate equivalence with the iOS App (same design, same artwork, but with an Android look-and-feel). So far, that has meant 4 steps backward and 3 steps forward (literally). For the moment, I've taken out (a) the nice Android car settings work, (b) Groups (which was seriously broken in v3 anyway), (c) home screen widget, (d) and tablet support. These features are still in DecompileWork and can be put back later - for the moment I'm just trying to get something working on Android that we can use going forward. With the lost source code, that had not previously been possible. A list of things still to be done to achieve approximate parity with iOS are: The charge start/stop interface on the main tabInfo screen. The charger settings dialog on the main tabInfo screen (set charge mode and current limit). The lock/unlock function on the tabCar screen (to lock/unlock the car via pin entry). The valet mode on/off function on the tabCar screen (to enabled/disable valet mode via pin entry). The HomeLink function on the tabCar screen. Vehicle WakeUp on the tabCar screen. Support for graying out of stale data on the tabCar screen. Vehicle direction and speed on the tabMap screen. Completion of the car data model. Support for server commands and responses in the comms protocol. Checking (and probable tidy-up) of interface layouts to look nice across a range of devices (resolutions and pixel densities). Vehicle control menu. Vehicle Features display and setting. Vehicle Parameters display and setting. Ad-Hoc Tester Device Release. Andoid Marketplace (Play?) Release. Now that the basic framework is done, most of these are relatively quick and simple to do. The longer-term nice-to-haves that can come later include: Vehicle group membership on the tabMap screen. Vehicle group display on the tabMap screen. Vehicle movement animation on the tabMap screen. Tidy-up of vehicle info display (to be nice and neat like the iOS version). The Weather icon display on the tabCar screen. Advanced settings dialog (like the old v3). Vehicle MMI/USSD Code. Cellular Usage Display. Reset OVMS Module function. Temperature and Distance units selection and display support. At this point, the Android project is back in a place where others can come in and help out. There was little point before when it was in such of a mess. I'm willing to do this all myself, if necessary, but things would go so much quicker (and the result better) if others would help out. So, the question is - who can step forward to help with the coding? Literally grabbing features that interest you and implementing them. This will be very short term (at least for the first list) - I expect to have this done and back in the Android Marketplace within a few weeks. But, longer term, it would be good to have people working on this and extending it into the nice-to-have features. Regards, Mark. Begin forwarded message:
From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: [Ovmsdev] Android code for OVMS Date: 29 July, 2012 5:51:38 AM GMT+08:00 To: OVMS Developers <OvmsDev@lists.teslaclub.hk> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk>
It appears that we're in a mess with the Android code base. The Android project Sonny had worked on containing updates to the OVMS Android App has been accidentally deleted, and the latest updates to the code lost. The NAS backup arrangement that Sonny had in place has also failed, and there is no backup.
Sonny apologizes, and has tried hard to recover the files, but cannot. He is also still tied up with work commitments, and can't help much for the next month or two.
We still have the code base in github, but that is quite old as it has not been updated with the improvements made in recent months. Primarily the settings screen, partial support for groups, and support for tablets. It is the tablet support that is causing problems with new high-res phones (as it is incorrectly identifying these as tablets) - I suspect that the settings code is the main thing we want to retain.
I have tried to reverse-compile the Android code from the APK in the marketplace, and while the resulting code looks pretty good, the resources are not reverse-compilable, and look like they would take a significant amount of work to repair.
My approach has been to take the github version, compile it, decompile it, and compare that with the decompiled version of the latest android market APK - applying patch duffs where necessary. The code looks good, and seems to only need minor tidy-ups. But, the resources are a mess. It seems the decompile process retains code symbols, but not resource symbols. The resource IDs and tags end up as numbers.
I'm really not familiar with Android development, so am not sure how feasible that approach would be. It looked very easy and successful to start with.
So, we are faced with a decision:
1. Someone more experienced with Android development comes up with a brilliant solution to finish off the reverse compilation of the APK to get back the latest version. I don't mind stepping in with the 'donkey work', but I really don't know where to start. What are those "R" class files - they look like they may be the key?
2. We start again with the code as it was a few months ago, and try to take it forward from there.
3. We investigate cross-platform development environments that could perhaps give us a more unified appearance across the the different platforms, as well as support for Windows Phone and others.
What do people think?
Mark _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev