Develop Reference

Android: Modifying Car UX Restrictions by overlaying car_ux_restrictions_map.xml

I am trying to disable all car UX restrictions by overlaying <android_source>/packages/services/Car/service/res/xml/car_ux_restrictions_map.xml.
I created <vendor-path>/overlay/packages/services/Car/service/res/xml/car_ux_restrictions_map.xml and added baseline restrictions for all drive modes in this file.
I also created <vendor_path>/overlay/packages/services/Car/service/res/values/attrs.xml, basically copied it over from <android_source>/packages/services/Car/service/res/values/attrs.xml.
However when I run my Android emulator and try to change drive modes, CarUxRestrictionsConfigurationXmlParser.java can't seem to read R.styleable.UxRestrictions_Restrictions_uxr and ends up setting restrictions on all drive modes to fully restricted, which further ends up locking my emulator UI for all drive modes.
Anybody know what might be the issue here? Do I need to make an AndroidManifest.xml, create and install an APK, etc.?

Android: How to make device run only one app?

I have an customer project where I have to make single task android device. Customer isn't able to escape the application which my company have developed. Also customer isn't able to start any other application and our application is started when the device is booted. Overall all the customer is able to do with the device is run our application.
Is there any other way to make this work than rooting the device, disabling all system buttons and making our application the launcher. I have something like 400 devices for this purpose so rooting all those would cost lot of time.
I also read Google's tutorial about COSU devices but found it very confucing https://developer.android.com/work/cosu.html#testing-plan
Androids own screen pinning is not good enough because customer can escape the app. Some may suggest to use some kiosk application like SureLock but my company's goal is to find clear solution for this without using any third party apps. Also running our app via some kiosk application is not our goal.
I found some posts on the Stack Overflow with similar question, but not the answer I'm looking for.
If someone has some tips for this question I would be very grateful.

Single purpose devices built on top of Android can get difficult to implement. There are a few different options, but each have trade-offs.
As you mentioned, rooting devices will functionally get you what you want - however it will be time consuming with hundreds of devices to root, difficult to maintain, and you will (potentially) introduce security issues to your devices and app.
Another option is using Google's Lock Task Mode for COSU devices[1]. The link there has a nice graphic showing the features of lock task mode:
1 app pinned to the home screen
only apps white-listed by the DPC (device policy controller) can be locked
Home and Recent buttons hidden
exit by calling stopLockTask()
There are some downsides to using Google's solution for this. First Google recommends creating (and therefor maintaining) an entirely separate DPC app to run as a device owner and set policies[2]. You'll also be dependent on Google Play to manage application updates and be required to have Play accounts associated with each device which "are used to identify a single device that is not tied to a single user for simplified, per-device app distribution rules in COSU-style scenarios"[3]. To automatically get your DPC app on devices your "DPC must be publicly availble on Google Play, and the end user can install the DPC from the device setup wizard by entering the DPC-specific identifier."[3] You'll also need to upload the user application to Google Play[4], which may be an issue for some who don't want their apps on Play. Going this route gives you features you need, but can be complicated and also ties you and your customer pretty tightly with Google/Play services and their workflow.
You can also look at enterprise mobile deployment platforms like Mason[5]. In your case, you can create a custom Android OS in a few minutes with your app locked in kiosk mode (+ other features like disable camera/sms, remove apps and hide settings, etc.) and then deploy it to all of your devices remotely. Mason also supports OS and app updates controlled by you if your requirements change.
DISCLAIMER: I work for Mason
[1] https://developer.android.com/work/cosu.html
[2] https://developer.android.com/work/cosu.html#create-dpc
[3] https://developers.google.com/android/work/requirements/cosu
[4] https://developers.google.com/android/work/play/emm-api/samples#push_install_an_app_on_a_device
[5] https://bymason.com/

I went to the same problem before. I spent at least 3 days doing research. I tried to find many solutions but I found zero.
How I solve is
1. Up To JellyBean
- Use System Alert Dialog (And make it transparent and small size like 2 * 2 And display in some corner(User can't see it)). User can't press home button If there is system Alert dialog
2. After JellyBean, This method doesn't work. The user can press the home button even though there is System Alert Dialog.
so what I did is, start the service on stop and start the same activity again and again(within sec). So user can't see any difference.Don't forget to make activity as single task so that even though you start same activity from service, again and again, new activity will not create (So Ugly way )
- You can simple make screen full screen. make sure in kiosk mode try to check if the screen is in full-screen mode. if not make it full-screen mode(its not hard to do)
- other way is to make launcher app but when ever you pressed home button it always asked to choose launcher app. if user mistakenly choose default/ other launcher app, this solution doesnt work
Good luck

Make your application as a launcher application by defining in manifest file.
After that go to setting of your mobile device and change default launcher application to your application.

How to unclock Android screen when install from Eclipse

I'm new in Android developing (I'm a developer iOS from 3 years) and the very first thing that I notice in Android is that when I install my app from Android I need to unlock the screen manually.
This might seem like an unimportant thing but very often I'm wait in front of the screen for a few seconds and then I realize that I have to unlock the device manually.
Thanks

Well, I don't know about auto unlock but you could set "Stay Awake" in developer settings on your phone. This means the screen will not lock when you are connected to your computer. Not compatible with all phones due to some screen types.
Also, you could have a scout around the Play Store. There are numerous attempts at this but with varying results I suspect.
--Conor

Android: launching flash app as a screensaver

i am new to android development and had question regarding custom screen saver.
The requirement is for a tablet which will always be plugged in so battery life wouldn't be
an issue. The required app should behave as a screensaver in that during inactivity, the tablet should launch this app which contains a flash file that displays a series of images and video. When activity is resumed then the tablet takes the user back to the program they were using.
Can this be done via an app without requiring any hacks?
cheers,
abhi

There is no concept of a "screensaver" in Android.
There is the lock screen, which can be modified via custom firmware, though AFAIK it is implemented in Java as part of the OS and therefore could not be replaced via a Flash APK.

Is disabling landscape mode unforgivable?

Our application could support landscape mode without any problem, but it is such a pain that we are thinking about forcing portrait mode.
Question: Is it BAD?
The main problem is that changing orientation generates random crashes on many screens. Avoiding those crashes would potentially allow us to spend more time on the core aspects of the app. Will the same crashes happen when users switch apps anyway?
Also, are there landscape-oriented devices where our app will become useless?

There is one area that might be unforgivable.
If a user interacts a lot with your app using a virtual keyboard, you should be vary of one thing:
There are emerging Android phones with a sliding physical keyboard that's meant to be used only in landscape mode. An example of such a device is a HTC G1.
Since such Androids are usually a premium, their users are very proud of having a physical keyboards. And if your app doesn't allow them to use their keyboard when they can use it, they will hate your guts for it and they might even give you negative ratings on Android app. market. Yes, it sounds cruel, but that's life.
Otherwise, having a portrait mode only application that runs well and isn't buggy is more than acceptable.
Moral of the story: try to make as many of your customers happy as possible. You won't always succeed, but you might fail if you piss even a minority of them off.

An unstable app or an app with a poorly thought out, landscape-unfriendly UI is much worse than an app with is limited to portrait.
There are probably some devices where a portrait-only application would be unwieldy, but the majority would handle it ok. Your best bet is to limit the orientation until the Android landscape or your business priorities make it more important to support those devices.

The crashes are probably caused by the activity restarting when changing orientation. With a configuration change you can prevent that without forcing the app to be in portrait mode all the time. Add the config changes line and it will prevent the activity from restarting.
<activity
android:name=".active.help.HelpMenu"
android:label="#string/help_string"
android:configChanges="keyboardHidden|orientation">