[1:] http://developer.android.com/guide/topics/security/security.html#userid
On Tue, Aug 18, 2009 at 3:06 PM, lookman sanni <[email protected]> wrote: > > > On Sat, Aug 15, 2009 at 3:03 AM, Luciano Resende > <[email protected]>wrote: > >> On Tue, Aug 11, 2009 at 3:08 PM, lookman sanni<[email protected]> >> wrote: >> > Blocking issues due to android platform >> > >> > Thread.currentThread().getClassLoader() always return null on android. >> To >> > fix this, i had to pass dalvik classLoader from the client side to all >> > places in Tuscany's modules where classLoader is recquired. >> > ClassLoader.getResources() doesn't work neither under android. Dalvik's >> > pathClassLoader may be a solution. But as we're working on a lightweight >> > system, it'll surely be heavy to open stream on about 43 services files >> > (needed to run calculator). Instead, i just set up system properties so >> that >> > each service name will represent a system property and it's >> implementation >> > class would be the property's value. This will involve no code >> refactoring >> > on tuscany's modules as for resolving services, system properties are >> > firstly checked. >> > org.w3c.Node implementation under android doesn't contain getTextContent >> > method. I replaced all calls to it by getNodeValue(). >> > >> > Current state >> > Calculator-android can run till ContributionProcessor resolution. In >> other >> > words, definitions.xml loading's step is already performed. What I'm >> trying >> > to do now is to implement a an APKContributionProcessor for the new >> > PackageType.APK somehow like those existing for JAR and Folder >> > ContributionProcessors. >> > >> > APK structure: An archive uncompressable with any archiver, which >> contain >> > all resources attached to the sources, and a classes.dex file resulting >> from >> > the dexification of all java sources. I guess artifacts i'll need to >> > retrieve in the APKContributionProcessor will be the classes inside the >> > classes.dex file. >> > >> > Long term: perspectives >> > Instead of continuing with the current host-android or host-embedded ( i >> > don't know yet what's exactly inside), i suggest we rewrite it like an >> > android application that'll setup needed system properties on a world >> > readable way ( to make it available to any other android application), >> and >> > bootstrap at build time resources files into a given directory on the >> > android system. These resources files will be needed in addition to >> system >> > properties as we need to provide a description of all services >> (classname, >> > servicename, url). >> >> If you make the runtime as an app, how you are going to make other >> apps run on this app, in other words, how calculator app will run on >> top of tuscany app ? >> The idea of host-android (which started as a copy of host-embedded) >> was to remove the extensibility we were currently using based on >> Service Discover and getResources and hard code the initialization of >> these extensions to avoid most of the issues you described above. >> > > I'm not aiming in fact to make the runtime as an app. There'll still be > runtime module(s). But the installer i'm talking about will just to send > meta-inf files on the device, and set some system properties or preferences > any other app like calculator can access. In fact, only ways i think we can > use to send files on android's device are adb shell and android java > project. Please have a look to he user ids and file access section of the > page in [1] > > > > The Calculator-android project > > The one existing is targeting an older version of android sdk. I've just > > recreated a new project, by importing services sources from the sample > > calculator. > > > >> This should be a good candidate for a patch. > > I think i'll sent an archive of the project instead of a patch. I went in > fact through some quite gloomy build problems with android sdk, due to sdk > version problems and may be others. > >> >> >> ... >> >> > Coming soon >> > >> > Zip of the new calculator-android >> > Patch of all modifications on tuscany's modules >> >> What's kind of modifications do you have for the tuscany modules ? I >> guess we don't want to make the existent Tuscany modules more rigid >> just to run Android. >> > > I assume we will need to rewrite about 2 to 5 tuscany modules, in order to > get classLoader passed everywhere, and some fixes on uses of org.w3c.Node > due to non existence of some methods on android. > > >> >> > >> > -- >> > Best Regards >> > >> > Lookman SANNI >> > http://blog.lookouster.org >> > MSBI Intern at Umanis Tours Services; >> > >> >> >> >> -- >> Luciano Resende >> http://people.apache.org/~lresende >> http://lresende.blogspot.com/ >> > > > > -- > Best Regards > > Lookman SANNI > http://blog.lookouster.org > MSBI Intern at Umanis Tours Services; > -- Best Regards Lookman SANNI http://blog.lookouster.org MSBI Intern at Umanis Tours Services;
