Stability of /data/ partiton on android devices

[Christian Kuester]

Hi Guys,

I'm a developer on the Qt Port for Android. At the moment we
Qt-Enable Android devices by some kind of smart installer/android
service which downloads and stores the Qt-native libraries into
the /data/local directory. When an application wants to load
the Qt libaries it can query the android service for the path
to the native libraries.

I was very much wondering if the
local directory is meant for those kind of use cases and if
it's stable in the sense of can developers trust that an
application has read (and write) access to that directory in
the /data partition on Android devices out there.

If not, has anyone a recommendation of an official way to
support such a use case: Installing Blobs which all applications
can access? (I assume that because the API enables you
to create WORLD_READABLE and WORLD_WRITABLE files, it's not
against the security model)

Thanks in Advance,
Chris
--
Dipl.-Inform. Christian K�ster

tarent solutions GmbH
Heilsbachstra�e 24, D-53123 Bonn * http://www.tarent.de/
Tel: +49 228 52675-0 * Fax: +49 228 52675-25
Mobil: +49 171 7673249
HRB AG Bonn 5168 * USt-ID (VAT): DE122264941
Gesch�ftsf�hrer: Boris Esser, Elmar Geese

[Dianne Hackborn]

The correct way to find a path to an app's data is through Context.  If you want to find the path to another app, use Context.createPackageContext() to get a Context for the other app and query it for the path.

Applications should only be putting things under the files directory; the top-level directories in the app's data directory is reserved for the system's namespace.

On Sat, Jun 18, 2011 at 5:14 AM, Christian Kuester <c.ku...@tarent.de> wrote:

Hi Guys,

I'm a developer on the Qt Port for Android. At the moment we
Qt-Enable Android devices by some kind of smart installer/android
service which downloads and stores the Qt-native libraries into
the /data/local directory. When an application wants to load
the Qt libaries it can query the android service for the path
to the native libraries.

I was very much wondering if the
local directory is meant for those kind of use cases and if
it's stable in the sense of can developers trust that an
application has read (and write) access to that directory in
the /data partition on Android devices out there.

If not, has anyone a recommendation of an official way to
support such a use case: Installing Blobs which all applications
can access? (I assume that because the API enables you
to create WORLD_READABLE and WORLD_WRITABLE files, it's not
against the security model)

Thanks in Advance,
Chris
--

Dipl.-Inform. Christian Küster

tarent solutions GmbH
Heilsbachstraße 24, D-53123 Bonn * http://www.tarent.de/

Tel: +49 228 52675-0 * Fax: +49 228 52675-25
Mobil: +49 171 7673249
HRB AG Bonn 5168 * USt-ID (VAT): DE122264941

Geschäftsführer: Boris Esser, Elmar Geese

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@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.

[David Turner]

Hello,

On Sat, Jun 18, 2011 at 2:14 PM, Christian Kuester <c.ku...@tarent.de> wrote:

Hi Guys,

I'm a developer on the Qt Port for Android. At the moment we
Qt-Enable Android devices by some kind of smart installer/android
service which downloads and stores the Qt-native libraries into
the /data/local directory. When an application wants to load
the Qt libaries it can query the android service for the path
to the native libraries.

This is unfortunately wrong:

• /data/local is not accounted for and cannot be cleaned up when uninstalling an application. You are stuffing the /data partition with large binary files that cannot be easily removed by the user. And I hope you don't install these files with write-permissions, or you're subject to exploit injection into any process that loads these libraries (some break-dead frameworks / applications copy shared libraries to the SD Card and use a custom dynamic linker to load them, please don't do that, it has the exact same problem!).
  
  
• Generally speaking, the Android application is of a all-inclusive package that contains all required code and resources. There are a few exceptions, like apps that depend on other ones through the mechanism of intents (which is a quite explicit and formalized interface / separation of concerns), but the general idea is that we don't want users having to deal with dependency resolution, or need to implement a complicated package/dll management solution in the platform (which will invariably lead to more complexity / development + support issues / user confusion, even if it is completely perfect and bug-free).

Frankly, I would recommend you to ditch your current model, and just make any required Qt libraries part of the Android application your users want to create. Use static linking to avoid embedding too much code in the final result.

I was very much wondering if the
local directory is meant for those kind of use cases and if
it's stable in the sense of can developers trust that an
application has read (and write) access to that directory in
the /data partition on Android devices out there.

No, it is not stable, and certainly not really meant to be used for this kind of use.

In a nutshell, the /data/local partition is meant to be a useful location where people can temporarily install useful stuff.

We originally designed it as a place where power users could install a local copy of BusyBox or other useful Unix utilities without requiring root.

We also use it in various test suites to install temporary data through ADB.

Please do not abuse this facility. Otherwise we will be forced to modify the system to get rid of it, or clean it on a daily basis like a vulgar /tmp (which doesn't exist on Android, as you probably noticed).

Also, it's not really documented, and there is no guarantee that this directory is/will be available on all Android devices/builds or in the future.

 

If not, has anyone a recommendation of an official way to
support such a use case: Installing Blobs which all applications
can access? (I assume that because the API enables you
to create WORLD_READABLE and WORLD_WRITABLE files, it's not
against the security model)

Just install it under your "installer application's" files directory, and have the other applications that depend on it access them (see Dianne's post for details).

Of course, it means that if you uninstall the "installer", then all your installed Qt-based applications are now dead.
And updating the installer's libraries has the potential to break some apps if you slightly change the ABI.

Which is why I'd really recommend you to embed the Qt libs into the final application packages instead.

Regards

Thanks in Advance,
Chris
--

Dipl.-Inform. Christian Küster

tarent solutions GmbH

Heilsbachstraße 24, D-53123 Bonn * http://www.tarent.de/

Tel: +49 228 52675-0 * Fax: +49 228 52675-25
Mobil: +49 171 7673249
HRB AG Bonn 5168 * USt-ID (VAT): DE122264941

[Christian Kuester]

On Mon, Jun 20, 2011 at 01:12:03PM +0200, David Turner wrote:
> Please do not abuse this facility. Otherwise we will be forced to modify the
> system to get rid of it, or clean it on a daily basis like a vulgar /tmp
> (which doesn't exist on Android, as you probably noticed).

I got a slap on the back of my our lead developer for not being correct about the smart
installer. data/local is only used during development. The smart installer
uses it's very own private home under is /data/data/app.name.. directory.

So: We don't abuse this and never will.

> Also, it's not really documented, and there is no guarantee that this
> directory is/will be available on all Android devices/builds or in the
> future.

Thanks for Dianne and your reply. At least I'm sure we can't use this
directory for any stuff.

> Of course, it means that if you uninstall the "installer", then all your

> installed Qt-based applications are now *dead*.

> And updating the installer's libraries has the potential to break some apps
> if you slightly change the ABI.

That's been taken care of, because it supports (or will) different versions.

> Which is why I'd really recommend you to embed the Qt libs into the final
> application packages instead.

We want to support this, too.

tarent solutions GmbH
Heilsbachstra�e 24, D-53123 Bonn * http://www.tarent.de/

Tel: +49 228 52675-0 * Fax: +49 228 52675-25
Mobil: +49 171 7673249
HRB AG Bonn 5168 * USt-ID (VAT): DE122264941

[BogDan]

Hello,

I think Christian misunderstood me, so I want to make some
clarifications (I'm the guy how design and implement the whole thing):

- Minsitro (the qt smart installer for android) stores QtLibs into its
own files folder, and uses a small native lib to change their
attributes to 0644, so those libs can be accessed/loaded by *ANY*
android application.

/data/local is used *ONLY* by Necessitas (qt for android suite)
hackers to test their modification made to Qt libs, because is the
only path where adb has R/W access. To use this libs you need to pass
some special params to your Qt Application otherwise it will connect
to Ministro service and it will uses *ONLY* Ministro's QtLibs.

BogDan.

On Jun 20, 2:12 pm, David Turner <di...@android.com> wrote:
> Hello,
>

> On Sat, Jun 18, 2011 at 2:14 PM, Christian Kuester <c.kues...@tarent.de>wrote:
>
> > Hi Guys,
>
> > I'm a developer on the Qt Port for Android. At the moment we
> > Qt-Enable Android devices by some kind of smart installer/android
> > service which downloads and stores the Qt-native libraries into
> > the /data/local directory. When an application wants to load
> > the Qt libaries it can query the android service for the path
> > to the native libraries.
>
> > This is unfortunately wrong:
>

>    - /data/local is not accounted for and cannot be cleaned up when

>    uninstalling an application. You are stuffing the /data partition with large
>    binary files that cannot be easily removed by the user. And I hope you don't
>    install these files with write-permissions, or you're subject to exploit
>    injection into any process that loads these libraries (some break-dead
>    frameworks / applications copy shared libraries to the SD Card and use a
>    custom dynamic linker to load them, please don't do that, it has the exact
>    same problem!).
>

>    - Generally speaking, the Android application is of a all-inclusive

> installed Qt-based applications are now *dead*.

> And updating the installer's libraries has the potential to break some apps
> if you slightly change the ABI.
>
> Which is why I'd really recommend you to embed the Qt libs into the final
> application packages instead.
>
> Regards
>
> Thanks in Advance,
>
> > Chris
> > --
> > Dipl.-Inform. Christian Küster
>
> > tarent solutions GmbH

> > Heilsbachstraße 24, D-53123 Bonn *http://www.tarent.de/

[David Turner]

I've just read BogDan's and Christian's messages.

So apparently everything is done adequately and there is nothing to worry about.

Everything went better than expected :-)

- David

On Mon, Jun 20, 2011 at 4:57 PM, Christian Kuester <c.ku...@tarent.de> wrote:

On Mon, Jun 20, 2011 at 01:12:03PM +0200, David Turner wrote:
> Please do not abuse this facility. Otherwise we will be forced to modify the
> system to get rid of it, or clean it on a daily basis like a vulgar /tmp
> (which doesn't exist on Android, as you probably noticed).

I got a slap on the back of my our lead developer for not being correct about the smart
installer. data/local is only used during development. The smart installer
uses it's very own private home under is /data/data/app.name.. directory.

So: We don't abuse this and never will.

> Also, it's not really documented, and there is no guarantee that this
> directory is/will be available on all Android devices/builds or in the
> future.

Thanks for Dianne and your reply. At least I'm sure we can't use this
directory for any stuff.

> Of course, it means that if you uninstall the "installer", then all your
> installed Qt-based applications are now *dead*.
> And updating the installer's libraries has the potential to break some apps
> if you slightly change the ABI.

That's been taken care of, because it supports (or will) different versions.

> Which is why I'd really recommend you to embed the Qt libs into the final
> application packages instead.

We want to support this, too.

tarent solutions GmbH
Heilsbachstraße 24, D-53123 Bonn * http://www.tarent.de/

Tel: +49 228 52675-0 * Fax: +49 228 52675-25
Mobil: +49 171 7673249
HRB AG Bonn 5168 * USt-ID (VAT): DE122264941

[BogDan]

We are professionals ;-)

Cheers,
BogDan.

On Jun 20, 6:28 pm, David Turner <di...@android.com> wrote:
> I've just read BogDan's and Christian's messages.
>
> So apparently everything is done adequately and there is nothing to worry
> about.
>
> Everything went better than expected :-)
>
> - David
>

> > Heilsbachstraße 24, D-53123 Bonn *http://www.tarent.de/