preventing app installs

[Kenneth Rahn Jr]

Hello all,

Sorry for asking this question on the mailing list, but I couldn't find a solution after lots of
Googling, IRC'ing, and either I'm blind or the group FAQ link is hiding.

My company recently purchased phones that run Android 2.2 (DroidX from Motorola), and they've tasked
me with configuring them with a core set of apps, and making sure users can't install anything else.
The goal is to keep the phones as a lean, mean work tool -- and not let the users install personal
apps and data that will bog the device down.

I've rooted the phones and deleted the carrier's preloaded junk. I've explored commercial parental
controls apps, but they seem focused on blocking malware and other objectionable content. I've
looked at the device-admin API, but that seem more targeted to password strength, device lock, and
wiping the device. The carrier (Verizon) directed me to talk to Motorola, but I think this could be
better handled in the OS level.

I was thinking about renaming the Marketplace app so it isn't recognized as an app -- then
re-enabling it briefly for app updates (cron job?), but that feels like an inelegant brute-force
approach.

Can someone please point me in a better direction ? Thank you all very much !

And, yes, I realize that locking down Android is against the spirit of Android -- but for corporate
settings, it is a priority.

--

Sincerely,

Ken

[Christopher Tate]

On Mon, Oct 25, 2010 at 9:52 AM, Kenneth Rahn Jr <k...@computergeek.co> wrote:
> Hello all,
>
> Sorry for asking this question on the mailing list, but I couldn't find a solution after lots of
> Googling, IRC'ing, and either I'm blind or the group FAQ link is hiding.
>
> My company recently purchased phones that run Android 2.2 (DroidX from Motorola), and they've tasked
> me with configuring them with a core set of apps, and making sure users can't install anything else.
>  The goal is to keep the phones as a lean, mean work tool -- and not let the users install personal
> apps and data that will bog the device down.

Outright prevention of the installation of 3rd party apps would mean
that the device will not pass the CDD / CTS compliance requirements.

--
christopher tate
android framework engineer

[Shachar Shemesh]

Out of curiosity,

On 25/10/10 22:31, Christopher Tate wrote:
> CDD / CTS compliance requirements

For CDD I get Conserved Domains Database, Center for Digital Democracy
and Capability Development Document.

For CTS I got a Christian Television something, Carpal Tunnel Syndrome
and Certified Technology Specialist.

CTS with "compliance", I get a document that has to do with HDMI. CDD
doesn't bring anything that seems interesting.

Care to enlighten the ignorant (that's me) what this compliance is, as
well as why Kenneth should care?

Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

[Kenneth Rahn Jr]

http://source.android.com/compatibility/index.html

I found it in the Android docs under requirements to build an Android compatible device.

2) Comply with Android Compatibility Definition Document (CDD)
The CDD enumerates the software and hardware requirements of a compatible Android device.
3) Pass the Compatibility Test Suite (CTS)
You can use the CTS (included in the Android source code) as an ongoing aid to compatibility
during the development process.

Sincerely,

Kenneth Rahn, Jr
Software Engineering Consultant

Tel: (401) 338-2429
Email: k...@computergeek.co
Email: k...@softwareengineers.co
Email: k...@softwareconsulting.co

[Christopher Tate]

Actually, I think I misread your request originally. You aren't
actually working on your own custom Android platform, right? You're
essentially trying to brute-force a locked-down configuration of some
limited collection of retail phones?

Assuming you've gotten root-level access to the devices, the best way
to do that is to simply blow away Market and adbd, and accept that
you'll never get app updates. Note that you have to remove adbd, not
just Market, because that's the route whereby e.g. the SDK toolchain
installs apps.

Removing adbd also means you won't be able to do any more work on the
phones afterwards. No 'undo' possible outside of reflashing.

My earlier point about not being Android compliant is relevant for
people producing their own devices, not for people hacking on
retail-purchased ones.

--
christopher tate
android framework engineer

On Mon, Oct 25, 2010 at 9:52 AM, Kenneth Rahn Jr <k...@computergeek.co> wrote:

> --
> 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.
>
>

[Kenneth Rahn Jr]

Thank you for your post, Christopher.

Yes, I'm basically hacking retail phones, not working on my custom platform.
Sorry for the confusion.

I do have root-level access on the devices, but I hesitate to perform any "no undo" operations on
the phones.
However, this thread has gotten me thinking about scripting unattended app updates, and
hiding/unhiding Market and adbd.
Let me go research / test that approach.

Thank you again for your insight.

Sincerely,

Kenneth Rahn, Jr
Software Engineering Consultant

Email: k...@computergeek.co
Email: k...@softwareengineers.co
Email: k...@softwareconsulting.co

[Alex Jurgensen]

Hi,

Have you ever considered that third-party apps used for accessibility purposes will also not be installable if you make your preposed modifications.

As someone who has first-hand experiance with assistive technology, I stongly urge you to consider how you can allow these kinds of applications to be installed, either by your administrators or by your end users.

Even if you don't have users who need the support of these applications, the time has come where a few minutes designing this into your policies and proceedures may save you much headache down the road and allow your company to be more widely acccomodating of those with different needs in the future.

Apps that are affected are things such as ocr apps for those unable to read conventional print and those who need video conferencing with sign language interpreters, to name a few.

I hope you consider my suggestions.

Regards,

Alex,

Alex Jurgensen,

VoiceOver Trainer,

ASqua...@visionmail.uni.cc

Visit us on the web at: www.vipbc.org