Tag Archives: android

Old Android Emulator Location UI

Switching Android Emulator to the Old Location UI on GNU/Linux

It appears that the combination of Debian 13, Wayland, KDE 6.3, and NVIDIA drivers causes the new Android Emulator Location UI to break. When you select the Location tab, the map remains blank and the entire interface hangs.

After fiddling with it for a while without success, I found an alternative solution: disabling the new Location UI.

Digging through the Android Emulator source, I found the advancedFeatures.ini configuration file, which allows you to disable the new Location UI and control several other emulator features.

nano ~/.android/advancedFeatures.ini

Add the following line:

LocationUiV2 = off

Then completely close and restart the Android Emulator.

ADB

Launch Android app via ADB using a deep link 

adb shell am start -W \
  -n <package_name>/<fully_qualified_activity_name> \
  -a android.intent.action.VIEW \
  -c android.intent.category.BROWSABLE \
  -d "<deep_link>"

-W – Blocks activity manager (am) until the launch is finished (or times out) and then prints timing/status info.
-n – Sets the explicit component to launch. Ex: com.mypackage/com.mypackage.MainActivity.
-a – Sets the intent action.
-c – Sets the intent category.
-d – Sets the intent data. Can be anything that the app is configured to handle. Ex: https://mysite.com?action=1

Moving Files from one Git Repository to Another, Preserving History

Once upon a time all my Android apps and VMSoft related stuff were part of one big BitBucket git repository along with an issue tracker. This was a good idea when being an Android dev was just a hobby for the weekends and not my primary job.

Enough rambling 🙂 , this blog post is about moving files from one git repository to another and preserving your history.

Our goal is to move a single directory from one big Git repository to it’s own repository, we would like to preserve the commits history for that specific directory also.

In this example our big repo will  be called A and our new repo that will host it’s own subset of files will be called B

First filter the files from the big repo (A) by leaving only the ones you need:

git clone < repo A url >
cd < repo A directory >

Remove the “origin”

git remote rm origin

and filter A by < directory_to_move >. This action will go trough all the history and files and remove anything that’s not in < directory_to_move >.
More info on the inner workings of git filter-branch here.

git filter-branch --subdirectory-filter <directory_to_move> -- --all

filter-branch will leave you with the contents of < directory_to_move > in the root of repository A. Commit the changes and we can continue with the next step.

git add .
git commit

Moving to the new repository

Link repo A with repo B. The command below will make repository A branch of repository B.

git remote add repo-A-branch <git repository A directory>

Pull from the branch allowing unrelated histories

git pull repo-A-branch master --allow-unrelated-histories

and finally remove repo-A-branch

git remote rm repo-A-branch

That’s it, you now have your files in a new repository while preserving commits history.

Every opacity value hex code

I often work with HEX colors and want to apply some alpha to them.

Calculating the exact alpha HEX value is tedious job so here it is: the complete list of every possible opacity value in HEX

100% — FF
99% — FC
98% — FA
97% — F7
96% — F5
95% — F2
94% — F0
93% — ED
92% — EB
91% — E8
90% — E6
89% — E3
88% — E0
87% — DE
86% — DB
85% — D9
84% — D6
83% — D4
82% — D1
81% — CF
80% — CC
79% — C9
78% — C7
77% — C4
76% — C2
75% — BF
74% — BD
73% — BA
72% — B8
71% — B5
70% — B3
69% — B0
68% — AD
67% — AB
66% — A8
65% — A6
64% — A3
63% — A1
62% — 9E
61% — 9C
60% — 99
59% — 96
58% — 94
57% — 91
56% — 8F
55% — 8C
54% — 8A
53% — 87
52% — 85
51% — 82
50% — 80
49% — 7D
48% — 7A
47% — 78
46% — 75
45% — 73
44% — 70
43% — 6E
42% — 6B
41% — 69
40% — 66
39% — 63
38% — 61
37% — 5E
36% — 5C
35% — 59
34% — 57
33% — 54
32% — 52
31% — 4F
30% — 4D
29% — 4A
28% — 47
27% — 45
26% — 42
25% — 40
24% — 3D
23% — 3B
22% — 38
21% — 36
20% — 33
19% — 30
18% — 2E
17% — 2B
16% — 29
15% — 26
14% — 24
13% — 21
12% — 1F
11% — 1C
10% — 1A
9% — 17
8% — 14
7% — 12
6% — 0F
5% — 0D
4% — 0A
3% — 08
2% — 05
1% — 03
0% — 00

How to use it:
#000000 – Black with ought opacity
#17000000 – Black with 9% opacity

Recompile with -Xlint in Android studio

Staying out of deprecated methods is useful, so your app won’t run in some compatibility mode on the device. Plus having clean build output is also nice 🙂

While building an app, Gradle may produces some warnings telling you that some input files are using unchecked or unsafe operations or they are overriding a deprecated API.

Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

As the message suggest, we should recompile with -Xlint to get more details about the warnings.

In the app level build.gradle file

app level build.gradle file

we should add a section labelled  allprojects{}(if not already present).

In the allprojects{} section we will instruct Gradle to apply custom compiler arguments for each task involving  Java code compilation.

allprojects {
    tasks.withType(JavaCompile) {
        options.compilerArgs &lt;&lt; "-Xlint:unchecked" &lt;&lt; "-Xlint:deprecation"
    }
}

Now each time we build our app we will get detailed output of the unchecked or unsafe operations and the deprecated API we are using.

Tip: if for some reason we want to continue using a deprecated API and just suppress the warnings, we could annotate the deprecated method with the

@SuppressWarnings("deprecation")

annotation.